Eine banaction, zwei Transporte: eine fail2ban-VPN-Jail reparieren

Nichts in fail2ban verwirft von sich aus ein Paket: Es ruft eine Aktion auf, und diese Aktion benennt ein Protokoll und einen Port. Wenn die Jail einen Ban meldet, während der Daemon weiterhin Anmeldungen annimmt, ist der Ban meist echt und enger, als das Log vermuten lässt. Ein Client, der über den anderen Transport neu verbindet, trifft nie auf die installierte Regel. Vergleichen Sie, was die Aktion installiert hat, mit dem, worauf der Daemon lauscht, bevor Sie etwas ändern, denn der Beweis liegt in der Firewall-Kette, die die Aktion geschrieben hat, nicht in der Jail-Liste.

Lesen Sie die Kette, nicht die Jail-Zusammenfassung

fail2ban fügt seine eigene Kette vor die Dienstkette ein, sodass eine Zählerauflistung genau zeigt, was existiert. Eine nach der Jail benannte Kette mit einer einzigen Regel, deren Protokollspalte udp lautet, ist eine vollständige Erklärung für weiterhin eintreffende TCP-Anmeldungen. Nur UDP-Pakete der gesperrten Quelle werden abgewiesen. Der Dienst hat einen TCP-Listener, und nichts in dieser Kette berührt ihn.

Achten Sie auch auf den Nachbar-Jail-Effekt. Ein Host kann perfekt konfiguriert aussehen, nur weil eine andere Jail die fehlende Hälfte liefert, und derselbe Build bewirkt nichts, wo diese Jail nicht installiert ist.

Die Aktion benennt ein Protokoll, und dort bricht es

Jede banaction ist eine Firewall-Befehlsschablone, und das Protokoll steht in einem ihrer Platzhalter. Die Enge ist beabsichtigt, denn eine Web-Jail und eine DNS-Jail haben nichts damit zu tun, identische Ports zu blockieren. Zur Falle wird es, wenn der Dienst auf mehr als einem Transport lauscht, was VPN-Daemons regelmäßig tun. Der Filter kann fehlgeschlagene Anmeldungen beider Transporte beobachten, während die Aktion nur einen abdeckt.

SoftEther- und OpenVPN-Deployments lauschen meist gleichzeitig auf UDP und TCP, und weil die Logzeile in beiden Fällen gleich aussieht, beobachtet der Filter beide. Die Asymmetrie zeigt sich nie im eigenen Bericht der Jail. fail2ban zählte die Fehlschläge korrekt und installierte dann eine Regel, die für die Hälfte des Verkehrs gilt, auf dem diese Fehlschläge ankamen.

Lassen Sie den Ban beide Transporte abdecken

Korrigieren Sie das stattdessen in der Jail-Definition; handgeschriebene Regeln werden beim nächsten Reload durcheinandergebracht. Schreiben Sie zwei Aktionen aus, eine für jedes Protokoll:

action = %(banaction)s[name=%(__name__)s-tcp, actionname=%(__name__)s-tcp, protocol="tcp", port="%(port)s", chain="%(chain)s"]
         %(banaction)s[name=%(__name__)s-udp, actionname=%(__name__)s-udp, protocol="udp", port="%(port)s", chain="%(chain)s"]

Versuchen Sie nicht, das mit protocol = all abzukürzen. Die Standard-banaction ist eine Multiport-Aktion, und sie expandiert zu -p <protocol> -m multiport --dports <port>; ohne L4-Protokoll gibt es nichts, was der Portabgleich prüfen könnte, also weist iptables die Regel ab, während die Jail weiterhin einen erfolgreichen Ban meldet. Eine All-Ports-Aktion wie iptables-allports oder nftables-allports akzeptiert zwar einen einzigen Eintrag, sperrt aber jeden Port dieser Quelle, was eine andere Entscheidung ist und eine eigene Begründung braucht. Lassen Sie protocol auf tcp oder udp und akzeptieren Sie die zwei Einträge.

Beweisen Sie, dass die Regel existiert, statt der Einstellung zu vertrauen, denn eine Einstellung beschreibt eine Absicht, bis eine Kette sie hält:

iptables -S f2b-vpn-tcp
iptables -S f2b-vpn-udp

Jede Kette sollte eine Regel auflisten, mit -p tcp in der ersten und -p udp in der zweiten, beide mit der gesperrten Adresse. Bestätigen Sie dann, dass dieselbe Adresse auf beiden Transporten abgelehnt wird. Ein Ban, den Sie nicht in der Kette gesehen haben, ist eine Hoffnung, und der nächste Bericht über dasselbe Symptom kostet wieder dieselbe Stunde.

Was ein Ban weiterhin verfehlt, und der nächste Fall

Die Aktion weist eine einzelne Quelle ab, und nur auf den darin aufgeführten Ports. Sie tut nichts gegen einen Angreifer, der Adressen rotiert, und sie kann eine feindliche Maschine nicht von einem Carrier-Grade-NAT-Ausgang trennen, der von Hunderten Nutzern geteilt wird, wo ein Ban Leute aussperrt, die nichts getan haben. Stellen Sie sicher, dass der Filter die Adresse liest, die der Client tatsächlich hat, nicht einen weitergeleiteten Header oder eine Proxy-Adresse. Halten Sie das Fenster kurz genug, dass ein Fehler von selbst abläuft.

Nichts davon spricht dafür, die Protokollkorrektur zu überspringen; es spricht dafür, zwei Ideen gleichzeitig zu halten. Der Ban ist enger, als die Jail-Zusammenfassung vermuten lässt, und selbst ein vollständiger Ban ist enger als die Bedrohung. Stellen Sie die Firewall-Kette neben die Listener-Liste des Daemons und vergleichen Sie Protokoll für Protokoll, denn diese beiden Listen entscheiden, ob ein Ban den Dienst überhaupt erreichen kann.

Halten Sie den Reload-Befehl und die Kettenauflistung im Runbook neben der Jail fest. Die nächste Person braucht beides, und die Jail-Zusammenfassung wird ihr keines von beiden sagen.