Fail2ban: Lärmschutz, kein Schutzwall

Fail2ban liest Protokolle, erkennt wiederholte Fehlversuche und sperrt die Quelladresse für eine Weile. Das ist nützlich. Es ist nur nicht das, wofür es oft gehalten wird.

Was es leistet und was nicht#

Leistet es: Protokolle bleiben lesbar. Die CPU-Last durch Anmeldeversuche sinkt. Bei Diensten, die zwingend Passwörter brauchen (Mail, manche Anwendungen), bremst es Rateversuche tatsächlich aus.

Leistet es nicht: Schutz vor einem Angreifer mit gültigem Schlüssel. Schutz vor verteilten Versuchen aus vielen Adressen, jede Adresse probiert dreimal und ist damit unter der Schwelle. Und keinerlei Schutz vor Lücken in der Anwendung, die über Port 443 hereinkommen.

Einrichten#

sudo apt install -y fail2ban

Änderungen gehören in eine eigene Datei unter jail.d/, nicht in jail.conf, sonst überschreibt ein Paket-Update sie.

# /etc/fail2ban/jail.d/eigenes.local
[DEFAULT]
# Die eigenen Netze niemals sperren. Diese Zeile zuerst schreiben.
ignoreip = 127.0.0.1/8 ::1 10.99.0.0/24 203.0.113.42

backend = systemd
findtime = 10m
maxretry = 4
bantime = 1h

# Wiederholungstäter länger sperren: 1h, 4h, 16h, ...
bantime.increment = true
bantime.factor = 4
bantime.maxtime = 7d

[sshd]
enabled = true
mode = aggressive

[nginx-http-auth]
enabled = true

[recidive]
# Wer mehrfach gesperrt wurde, fliegt für eine Woche.
enabled = true
bantime = 1w
findtime = 1d
maxretry = 3

sudo systemctl restart fail2ban
sudo fail2ban-client status
sudo fail2ban-client status sshd

Sich selbst entsperren#

# Wer ist gerade gesperrt?
sudo fail2ban-client status sshd

# Eine Adresse freigeben
sudo fail2ban-client set sshd unbanip 203.0.113.42

# Alle Sperren einer Jail aufheben
sudo fail2ban-client unban --all

Diese drei Befehle lohnt es sich zu kennen, bevor man sie braucht, sie funktionieren nur, wenn man noch auf die Maschine kommt.

Prüfen, dass es tatsächlich greift#

# Greifen die Filter auf die echten Protokolle?
sudo fail2ban-regex systemd-journal /etc/fail2ban/filter.d/sshd.conf --print-all-matched | tail -20

# Was wurde in den letzten 24 Stunden gesperrt?
sudo journalctl -u fail2ban --since "24 hours ago" | grep -i ban | tail -20

Der erste Befehl ist der nützliche: Er zeigt, ob der Filter auf dem aktuellen Protokollformat überhaupt Treffer erzeugt. Nach einem Distributionssprung ist das gelegentlich nicht mehr der Fall und eine Jail ohne Treffer sieht aus wie eine ruhige Maschine.

Die Alternative ohne Zusatzdienst#

Wer nur den Lärm loswerden will, kommt auch ohne Fail2ban aus. nftables kann Verbindungsraten selbst begrenzen:

tcp dport 22 ct state new limit rate 10/minute burst 5 packets accept
tcp dport 22 ct state new drop

Das ist weniger fein steuerbar, hat aber keinen zusätzlichen Dienst, keine Filterregeln, die nach einem Update nicht mehr passen, und keine Möglichkeit, sich selbst auszusperren. Für eine Maschine mit ausschließlich schlüsselbasiertem Zugang ist es oft die passendere Antwort.

Einordnung#

Die Reihenfolge ist die Reihenfolge. Fail2ban steht bewusst unten, nicht weil es nutzlos wäre, sondern weil es die schwächste der vier Zeilen ist und trotzdem am häufigsten als erstes eingerichtet wird.