Ein Leser wünschte sich einen Artikel, wie Brute Force Angriffe auf Exchange Server verhindert werden können. Da Exchange Server in kleineren Umgebungen häufig direkt im Internet erreichbar sind (beispielsweise per Portforward) und Dank Autodiscover auch sehr schnell ermittelt werden können, eignen sich Exchange Server sehr gut für Brute Force Angriffe. Bei einem Brute Force Angriff versucht der Angreifer das richtige Passwort zu erraten, dabei wird eine große Anzahl fehlgeschlagener Logins erzeugt. Im wesentlichen gibt es zwei Wege, wie sich Brute Force Angriffe verhindern lassen. Zum einen lässt sich der Benutzeraccount nach einer gewissen Anzahl falscher Logins automatisch sperren. Dieses Feature wird direkt durch das Active Directory unterstützt. Das Sperren des Benutzers steht allerdings in der Kritik, denn so lassen sich durch einen Brute Force Angriff unter Umständen viele Benutzer sperren, was dazu führt das die Benutzer nicht mehr arbeiten können. Zwar errät der Angreifer dadurch zwar nicht das Passwort, jedoch werden sich schnell Benutzer beschweren, wenn das Konto alle paar Minuten gesperrt ist.
Ein anderer Weg ist, die IP Adresse des Angreifers nach einer bestimmten Anzahl fehlgeschlagener Logins zu sperren. Das Benutzerkonto wird somit nicht gesperrt, sondern nur der Angreifer daran gehindert das Passwort zu erraten. In diesem Artikel stelle ich zwei Wege vor, wie eine IP mit zu vielen fehlgeschlagenen Logins gesperrt werden kann.
IP mit Windows Firewall und PowerShell sperren
Eine einfache Möglichkeit eine IP Adresse nach zu vielen fehlgeschlagenen Logins zu sperren, ist ein kleines PowerShell Script, welches die IP Adresse an der Windows Firewall sperrt. Die fehlgeschlagenen Logins werden am Exchange Server im Security Eventlog mit der ID 4625 protokolliert. In diesem Event findet sich neben dem Benutzernamen, auch die IP Adresse von dem der fehlgeschlagene Login ausgeführt wurde:
Mit einem kleinen PowerShell Script lässt sich mit Hilfe der Aufgabenplanung alle 5 Minuten das Eventlog auf das Event 4625 prüfen. Tauchen im Log zu viele fehlgeschlagene Logins von der gleichen IP auf, wird eine Windows Firewall Regel erstellt, welche die IP blockiert:
Ich habe dazu ein einfaches PowerShell Script erstellt, welches die IP aus dem Event 4625 nach 5 fehlgeschlagenen Anmeldeversuchen mit einer Firewall Regel sperrt:
#Block IP after X failed Logins
$BlockCount = 5
#Get Date and Time
$Timestamp = get-date
#Get IPs vom Eventlog (last 10 min)
$Events = get-winevent -FilterHashtable @{Logname="Security";ID=4625;StartTime=[datetime]::Today.AddMinutes(-10)} -ea 0
#Exit Script if no Events found
if (!$Events) { exit 0 }
#Get IPs from Events
$IPs = @()
foreach ($Event in $Events) {
[xml]$XMLEvent = $Event.ToXml()
$IPAddress = ($XMLEvent.Event.EventData.Data | where {$_.name -eq "IpAddress"} | select "#text").'#text'
$IPs += $IPAddress
}
#Group Events
if ($IPs.count -gt 1) {
$IPAddressCounts = $IPs | group | select count,name | where {$_.Count -ge $BlockCount}
}
#Block IPs
if ($IPAddressCounts.count -gt 1) {
foreach ($IPAddress in $IPAddressCounts) {
$IP = $IPAddress.Name
$FirewallRuleName = "BlockIP:" + $IP
$CheckFirewallRule = Get-NetFirewallRule -DisplayName $FirewallRuleName -ea 0
if ($CheckFirewallRule) {
#If FW Rule exists, update with current TimeStamp
$FirewallRule = Set-NetFirewallRule -DisplayName $FirewallRuleName -Description $Timestamp
} else {
#Create new FW Rule
$FirewallRule = New-NetFirewallRule -DisplayName "$FirewallRuleName" -Direction Inbound -Protocol TCP -Action Block -RemoteAddress $IP -Description $Timestamp
}
}
}
Das Script kann alle 5 Minuten mit der Windows Aufgabenplanung ausgeführt werden (mit höchsten Privilegien). Wer möchte, kann die IP nach einer gewissen Zeit auch wieder entsperren indem die Firewall Regel beispielsweise nach 30 Minuten wieder gelöscht wird. Dazu kann dieses kleine Script genutzt werden:
#Unblock IP (Delete Firewall Rule) after X Minutes
$BlockTime = 30
#Get Date and Time
$Timestamp = get-date
$UnblockTimeStamp = $Timestamp.AddMinutes(-$BlockTime)
#Get all Firewall Rules
$FirewallRules = Get-NetFirewallRule -DisplayName "BlockIP:*"
#Unblock IPs / Delete Firewall Rules
foreach ($FirewallRule in $FirewallRules) {
$FirewallRuleDescription = $FirewallRule.Description
[datetime]$FirewallRuleCreatedTimeStamp = $FirewallRuleDescription
if ($FirewallRuleCreatedTimeStamp -lt $UnblockTimeStamp) {
$FirewallRuleName = $FirewallRule.DisplayName
Remove-NetFirewallRule -DisplayName $FirewallRuleName
}
}
Das erste Script schreibt den Zeitpunkt des Erstellens der Firewall Regel in den Kommentar der Regel, das zweite Script wertet den Zeitpunkt aus und löscht die Regel nach einer wählbaren Zeit wieder.
Die beiden Scripte lassen sich einfach an die eigenen Bedürfnisse anpassen, beispielsweise könnte man sich eine E-Mail schicken lassen, wenn eine IP gesperrt wurde. Die beiden Scripte haben aber auch ihre Nachteile, wenn das Script nur alle 5 Minuten läuft, wird eine IP möglicherweise auch erst nach 5 Minuten gesperrt. Brute Force Angriffe dauern in der Regel länger als 5 Minuten
RdpGuard (kostenpflichtig)
Eine andere Möglichkeit ist die Software RdpGuard, welche mit knapp 80 USD für eine Lizenz noch im preislichen Rahmen liegt. RdpGuard verfolgt einen ähnlichen Ansatz wie die beiden Scripte oben, reagiert also auch auf das Event 4625, kann aber zusätzlich noch weitere Logs auswerten und die IPs entsprechend blockieren. Somit lassen sich beispielsweise auch fehlgeschlagene Logins für SMTP, POP3 und SQL Server blockieren:
Auf der Website wirbt die Software mit dem Slogan „Intrusion prevention system for your Windows Server“, dass ist bei dem Leistungsumfang vielleicht „etwas“ übertrieben, denn in beiden Fällen handelt es sich nur um eine Art „fail2ban“ welches man unter Linux für besonders für SSH Verbindungen kennt. Eine Demo von RdpGuard gibt es hier:
Fazit
Eine IP nach fehlgeschlagenen Logins zu sperren ist relativ einfach, funktioniert aber nur, wenn kein Reverse Proxy vor dem Exchange Server eingesetzt wird. Wenn ein Reverse Proxy zum Einsatz kommt, steht in den Eventlogs nur die IP des Proxys, nicht aber die originale Quell IP. Für kleine Umgebungen eignen sich diese beiden Möglichkeiten daher meiner Meinung nach gut um Brute Force Versuche zu blockieren. Für Umgebungen mit Reverse Proxy, muss diese Funktion am Proxy umgesetzt werden, dazu muss der Proxy allerdings auch die Authentifizierung durchführen.