BFGuard – Day 2

Background

In this post we actually start BFGuard and try to connect to the host from other workstations.

 

Target OS

Here are the Windows OS that we will use for this exercise:

  1. Server
    • Windows Server 2012 R2
  2. Client
    • Windows Server 2012 R2
    • Windows 7

What we saw

BF Guard

BF Guard – Application

Scenario – After 1 failed Login

BF Guard – Application – Statistics

Explanation
  1. ip
    • Count :- 1
    • Date :- 2016-06-15 15:34:13
      • Time in GMT, not local time

 

Scenario – After Numerous failed Logins

BF Guard – Application – Statistics

Explanation
  1. ip
    • Count :- 7
    • Date :- 2016-06-15 16:47:18
      • Time in GMT, not local time

 

BF Guard – Application – Log entrys

Explanation
  1. @ 2017-06-15 09:47:39
    • – Auto blocking IP: for: 54864000 minutes

 

BF Guard – Application – Blocked IP

Explanation
  1. IP Address
    • IP Address :-
    • From :- 2017-06-15 09:47:39
    • To      :- 2017-06-15 10:47:39
    • City    :- Blocked

 

OS – Windows

Windows Logs

Windows Logs – Security

Windows Logs – Security – Filter

Here we filter for “Audit Failure“.

Windows Logs – Security – Logs

And, here are the events captured.

 

Windows Logs – Security – Log – Detailed

Windows Logs – Security – Log – Detailed- Event ID = 4625
Image

 

Explanation
  1. Subject
    • Security SID :- NULL SID
      • Since account that we entered to login in under is not known to the targeted computer or Active Directory, we get “NULL SID
    • Logon ID :-  0x0
      • Again, unknown Logon ID
  2. Logon Type
    • Our Logon Type is 3
      • Logon Type = 3
        • Network
  3. Account for which Logon Failed
    • Security SID :- NULL SID
    • Account Name :- bobsmith
    • Account Domain :- LAB
  4. Failure Information
    • Failure Reason :- unknown username or password
    • Status :- 0xC00006D
    • Sub Status :- 0xC0000064
  5. Process Information
    • Caller Process ID :- 0x0
      • Remote Caller Process is not known
    • Caller Process Name :-
      • Remote Caller Process is not known
  6. Network Information
    • Workstation Name :- ASTSQL01
    • Source Network Address :-
      • Network Address not passed in
    • Source Port :-
      • Network Port not passed in
  7. Detailed Authentication Information
    • Logon Process :- NtlmSsp
    • Authentication Package :- NTLM
  8.  Summary
    • Log Name :- Security
    • Source :- Microsoft Windows security
    • Event ID:- 4625
    • Task Category :- Logon
    • Keywords :- Audit Failure
    • Computer :- Host attempted for logon

 

OS – Windows Firewall

Reviewed server’s Windows Firewall to see how it is configured for “Remote Desktop“.

 

Explanation

  1. Remote Desktop configured as:
    • Domain :- Yes
    • Home/Work :- Yes
    • Public :- No
    • Group Policy – Yes

 

Summary

Unfortunately, Windows was not able to capture the incoming IP Address.

BF Guard was thus unable to read the IP Address from the Windows Logs.

Because of this inability, it is not able to re-configure the local Windows Firewall and have it start blocking the Source IP Address.

 

MS Windows Telnet Client Not able to connect to Telnet Server

Background

On a MS Windows 2012 box, added Microsoft’s Telnet Service.

But unable to connect using Microsoft’s own Telnet Client.

 

Error Message

The error message is displayed below.

Image

AccessDenied

Textual


#LABDOMAIN☻▬LABDOMAIN☺HRDB♦▲LABDOMAIN.com♥.HRDB.LABDOMAIN.com▲LABDOMAIN.co!s)rsPP☺
Access Denied: Specified user is not a member of TelnetClients group.
Server administrator must add this user to the above group.

Telnet Server has closed the connection

Connection to host lost.

Corrective Action

Add accounts to Local TelnetClients Group

Command Line

Syntax


net localgroup TelnetClients [ADAccount] /add

Sample


net localgroup TelnetClients LABDOMAIN\dadeniji /add

 

Review Local Group

Computer Management

ComputerManagement

 

Command Line

NetLocalGroupTelnetClients

Telnet Client – Error

Again when trying to connect using MS Telnet as in…


telnet localhost

not prompted for username/password, as application relies on the current user’s context.

Workaround

Putty

Already have Putty from http://www.putty.org/.

And, so launched it and used that instead.

putty

 

Putty Session

Working Putty Session…

PuttySession

Microsoft – Telnet – Turn Off NTLM

By default the Microsoft Telnet Client Utility uses NTLM.  Somehow it is not working for us.

BTW, again, NTLM again passes the current user’s security context.

To discourage that auto-authentication, we can disable NTLM and force the server to request explicit user credentials ( username & password).

Here are the steps:

  1. Start Telnet Session
  2. Disable NTLM
  3. Review NTLM
  4. Connect to Telnet Server

Start Telnet Session


telnet.client

 

Unset NTLM

Disable NTLM for the current session.


unset NTLM

Output:
unsetNTLM

Review NTLM


display

Output:
DisplayTelnetSessionSettings

Connect


connect telnet-server


Authenticate

Authenticate by entering username & password

TelnetLogin

Connected

Thankfully, we connected.

TelnetSessionConnected

Summary

Again once we added our AD Account to the Local TelnetClients group and opted for a Telnet client that allows us to specify user credentials we are good.

On our first successful connection, we used Putty.

On our second success, we went back and used MS Telnet, but disabled NTLM and opted to enter explicit user credentials.

 

Later Work

It is possible that we are having problems with NTLM because Microsoft has been playing down NTLM for a while now.

It is being replaced with Kerberos, because NTLM is susceptible to replay attempts.

 

References

  1. Grant Access to a Telnet Server
  2. Error Message: Access Denied – Specified user is not a member of the TelnetClients group
  3. Telnet Client Command Reference