Fail2ban für Windows: die echten Alternativen

Warum die Frage immer wiederkommt

Unter Linux ist fail2ban die Reflexantwort auf Passwortraten: Es liest ein Log, gleicht Fehlerzeilen gegen einen regulären Ausdruck ab und fügt eine Firewall-Regel für jede Adresse ein, die einen Schwellwert überschreitet. Es ist klein, es ist Standard, und es steht in jedem Härtungsleitfaden der letzten fünfzehn Jahre.

Administratoren, die zu Windows wechseln, suchen dasselbe Werkzeug und finden nichts. Fail2ban ist Python plus iptables und läuft unter Windows in keinem sinnvollen Sinne — es gibt kein syslog zum Lesen und kein iptables zum Schreiben. Windows hat stattdessen das Sicherheitsereignisprotokoll und die Windows-Firewall: dieselben zwei Zutaten, nur unverbunden.

Die Frage lautet also gar nicht „wie installiere ich fail2ban unter Windows". Sie lautet: „was verbindet Ereignis 4625 mit einer Firewall-Regel, und wie viel davon muss ich selbst bauen".

Die Eigenbau-Variante und was sie kostet

Die Selbstbau-Antwort ist eine geplante PowerShell-Aufgabe. Das Grundgerüst ist tatsächlich kurz — dies liest die Fehlschläge der letzten zehn Minuten, gruppiert nach Quelle und blockiert alles über dem Schwellwert:

$Threshold = 10
$RuleName  = 'Block-BruteForce'

$offenders = Get-WinEvent -FilterHashtable @{
    LogName='Security'; Id=4625; StartTime=(Get-Date).AddMinutes(-10)
  } -ErrorAction SilentlyContinue |
  ForEach-Object { ([xml]$_.ToXml()).Event.EventData.Data |
    Where-Object Name -eq 'IpAddress' | Select-Object -ExpandProperty '#text' } |
  Where-Object { $_ -and $_ -ne '-' } |
  Group-Object | Where-Object Count -ge $Threshold | Select-Object -ExpandProperty Name

$rule = Get-NetFirewallRule -DisplayName $RuleName -ErrorAction SilentlyContinue
if (-not $rule) {
  New-NetFirewallRule -DisplayName $RuleName -Direction Inbound -Action Block `
    -RemoteAddress $offenders | Out-Null
} else {
  $existing = ($rule | Get-NetFirewallAddressFilter).RemoteAddress
  $rule | Set-NetFirewallRule -RemoteAddress @($existing + $offenders | Select-Object -Unique)
}

Wo das Skript zu lecken beginnt

Diese dreißig Zeilen blockieren heute Abend echte Angreifer. Die Lücke zwischen ihnen und etwas, das Sie ein Jahr laufen lassen können, besteht aus unglamourösen Problemen, und jedes wird erst im Betrieb entdeckt:

• Sie sperren sich selbst aus. Im obigen Code gibt es keine Whitelist. Beim ersten Mal, wenn Ihre eigene Büroadresse einen schlechten Nachmittag hat — der Klassiker ist ein veraltetes gespeichertes Kennwort in einer Wiederholungsschleife —, stehen Sie vor einem Server, den Sie nur über RDP erreichen.
• Einzelne Adressen genügen nicht. Botnetze rotieren durch einen Bereich. 203.0.113.47 zu sperren kauft Ihnen eine Stunde, bis .48 startet. Das /24 zu sperren beendet die Serie, aber CIDR-Bereiche korrekt zu berechnen und zusammenzuführen ist deutlich anspruchsvoller als der Ausschnitt oben.
• Das Abfragefenster verliert Ereignisse. Alle zehn Minuten laufen heißt, einen Ausbruch zu verpassen, der in ein Fenster passt, oder ihn über zwei doppelt zu zählen. Unter Last rotiert das Sicherheitsprotokoll schneller als Ihr Intervall und Ereignisse verschwinden, bevor Sie sie lesen.
• Niemand sagt Ihnen, dass es steht. Geplante Aufgaben fallen still aus — nach einem Neustart, nach einer Passwortänderung des ausführenden Kontos, nach einem PowerShell-Richtlinienupdate. Sie merken Monate später, dass der Schutz seit März nicht mehr lief.
• Der RDP-Port ist vielleicht nicht 3389. Wurde er verlegt, blockiert das Skript zwar weiter die Quelle, aber nichts prüft, welche Ports die Regel abdecken müsste, und FTP und MS SQL sind gar nicht erfasst.
• Sperren überleben keinen Neuaufbau. Der Zustand liegt in der Firewall einer Maschine. Stellen Sie aus einem Image wieder her, und jeder Angreifer, den Sie kennengelernt haben, ist vergessen.

Was Windows von Haus aus mitbringt

Zwei native Funktionen werden in diesem Zusammenhang empfohlen, und es lohnt sich, präzise zu sein, was jede tut.

Die Kontosperrungsrichtlinie deaktiviert ein Konto nach N Fehlversuchen. Gegen RDP im Internet ist das eher eine Schwachstelle als eine Abwehr: Angreifer wählen den Kontonamen, also kann jeder Ihr Administrator-Konto auf Zuruf von überall sperren. Eine vernünftige Kontrolle für interne Konten und eine schlechte am Perimeter.

Network Level Authentication verlangt die Authentifizierung des Clients, bevor eine Sitzung entsteht. Sie senkt die Kosten jedes Versuchs wirklich und entfernt eine Klasse von Pre-Auth-Exploits, und sie sollte aktiv sein. Die Anzahl der Versuche senkt sie nicht, weil die Bots sich ohnehin authentifizieren — schlecht, für immer.

Keine der beiden verbindet das Ereignisprotokoll mit der Firewall. Genau diese Verbindung liefert fail2ban, und Windows bringt sie nicht mit.

Die Optionen nebeneinander

Nach Aufwand und Ertrag geordnet:

• PowerShell-Skript — kostenlos, volle Kontrolle, etwa ein Tag Arbeit und eine dauerhafte Wartungspflicht. Passend für einen Server, den Sie oft ansehen. Der Fehlerfall ist Stille.
• VPN oder RDP-Gateway davor — die stärkste Antwort und die betrieblich teuerste. Wenn jeder Nutzer ein VPN erreichen kann, nutzen Sie es und hören Sie hier auf. In den meisten Beständen gibt es Auftragnehmer und Telefone, für die das nie ganz klappt.
• IP-Whitelisting an der Firewall — ausgezeichnet, wenn die Menge legitimer Adressen klein und stabil ist, unbrauchbar in dem Moment, in dem jemand aus einem Hotel arbeitet.
• Ein verwalteter Agent — ein Installer, eine Whitelist, die gefüllt wird, bevor etwas blockiert wird, Subnetzsperren, automatisch erkannte Ports und eine Konsole, die zeigt, ob es noch läuft. In dieser Kategorie liegt RDP Protector.

Was ein verwalteter Agent über das Skript hinaus bietet

Zwei Dinge, die das Skript nicht haben kann, wie gut Sie es auch schreiben.

Das erste ist die betriebliche Grundlage: Ihre Adresse bei der Installation auf der Whitelist, eine zusammengefasste Firewall-Regel statt tausender, aus Registry und lauschenden Sockets erkannte Ports, Sperren, die Neustarts überleben, und ein Dashboard, das sagt, ob das Ding lebt — und genau dieser Fehlerfall beißt tatsächlich.

Das zweite lässt sich allein gar nicht bauen. Jeder geschützte Server speist eine gemeinsame Reputationsdatenbank, sodass eine Adresse, die gestern jemand anderen angegriffen hat, bereits gesperrt ist, wenn sie bei Ihnen ankommt. Ein Skript auf einem Server kann nur aus Angriffen auf diesen Server lernen.

Die Entscheidung fällt weiterhin lokal auf dem Agenten, der Schutz hängt also nicht an der Erreichbarkeit der Cloud — bricht die Verbindung ab, läuft die lokale Richtlinie weiter.