Using OpsMgr for intrusion detection and security hardening

Here is an interesting little concept of how to use OpsMgr.

Because I have a lab, that is exposed to the internet over port 3389, I get a LOT of hacking attempts on this lab. Mostly the source is from bots running on other compromised systems. These bots just do brute force attacks against the typical Admin accounts and passwords via RDP. In this article, I am going to show how OpsMgr can not only alert on this condition, but also respond by configuring the Windows Firewall to block these attacks.

I will start by analyzing the Server 2008 event that occurs when someone tries to attack using my “Administrator” account:

Log Name:          Security
Source:              Microsoft-Windows-Security-Auditing
Date:                  7/14/2009 12:44:05 PM
Event ID:            4625
Task Category:   Account Lockout
Level:                  Information
Keywords:          Audit Failure
User:                   N/A
Computer:           terminalserver.domain.com

Description:   An account failed to log on.

Subject:
    Security ID:             SYSTEM
    Account Name:        TERMINALSERVER$
    Account Domain:     DOMAIN
    Logon ID:                 0x3e7

Logon Type:            10

Account For Which Logon Failed:
    Security ID:             NULL SID
    Account Name:        administrator
    Account Domain:     TERMINALSERVER

Failure Information:
    Failure Reason:        Account locked out.
    Status:                      0xc0000234
    Sub Status:               0x0

Process Information:
    Caller Process ID:          0x14f0
    Caller Process Name:    C:\Windows\System32\winlogon.exe

Network Information:
    Workstation Name:    TERMINALSERVER
    Source Network Address:    10.10.10.1
    Source Port:        1261

Detailed Authentication Information:
    Logon Process:           User32
    Authentication Package:    Negotiate
    Transited Services:    –
    Package Name (NTLM only):    –
    Key Length:        0

So… for starters, I want to alert on this condition… when ANYONE is trying multiple times… to RDP into the server, with a disabled account, non-existent account, or valid account, but bad password. Therefore – I will create a monitor: Windows Events > Repeated Event Detection > Timer Reset.

The idea here is to only respond when multiple bad passwords are entered in a short time period…. representing an attack. (I don’t want to lock out or block access from my normal users who sometimes mis-type their password on a couple attempts.)

So I create the monitor, target “Windows Server Operating System”, set it to “Security” for the Parent Monitor, and UNCHECK the box enabling it. (I will later override this monitor and ONLY enable it for my entry terminal server.)

I create my event expression for the security event log, event 4625, and I only want the Logon Type of 10, which is from RDP:

Next – I will set up my monitor, to Trigger on Count (of events), Sliding. Compare count will be set to 5 (events) within a 3 minute interval. Therefore, as soon as 5 events are captured, in ANY sliding 3 minute “window”, the monitor will change state.

Next… since my goal is really to execute a script/command/response…. (not really a state change is desired) I will set the timer reset to reset the state back to healthy after 2 minutes. This will free the workflow up to block any other source IP’s which might attack soon after.

I don’t want to impact availability data, which assumes critical state = unavailable…. so I will use a Warning State:

Now – I will enable a unique alert for this condition. I want a critical, high priority alert in this case, and I will set this NOT to close the alert when we auto-resolve the state on the timer. I also will customize the alert description, to give me a richer alert based on the even details and my custom response. I talk more about these event parameters HERE. I will be adding:

$Data/Context/Context/DataItem/Params/Param[6]$ typed a bad password accessing directly from computer: $Data/Context/Context/DataItem/Params/Param[14]$ from IP: $Data/Context/Context/DataItem/Params/Param[20]$
The Windows Firewall will be modified to block this IP address in response to this monitor state.

Next – I will go back and find my monitor, and add a Recovery for the Warning State:

I will choose to Run Command. Give it a name “Modify Windows Firewall”

Next – for the command – I am going to run Netsh.exe which can configure the Windows Firewall running on the terminal server. Here is the command:

C:\Windows\System32\netsh.exe

advfirewall firewall set rule name=”Block RDP” new remoteip=$Data/StateChange/DataItem/Context/DataItem/Context/DataItem/Params/Param[20]$

$Data/StateChange/DataItem/Context/DataItem/Context/DataItem/Params/Param[20]$ is based on an Event Parameter of the Server 2008 event, which I will pass to the command, so it will gather the IP address of the attacker, and pass that to the command which configures the firewall rule. Getting this variable was the most complicated for me….. Marius talked about how to derive this variable HERE Just understand that the variables you use in an alert description are not the same was used in a diagnostic or recovery.

Cool:

My Netsh.exe command modifies an existing custom rule in the Windows Firewall, so I need to make sure I create that and name it “Block RDP”.

Now – I will override this rule and enabled it for my published terminal server, and then test this monitor… by attempting to log into my terminal server via RDP 5 times in a short period, using a disabled account. This will cause the event in the security event log for each event, and eventually trip the repeated event detection monitor.

Alert generates: