Was es tut
fail2ban liest die Logs. Scheitert eine Adresse maxretry-mal innerhalb von findtime bei der Anmeldung, fügt es eine Firewall-Regel hinzu, die diese Adresse für bantime blockiert. Das ist alles. Es untersucht keinen SSH-Verkehr und macht kein schwaches Passwort stark.
Installieren
sudo apt install fail2ban python3-systemdpython3-systemd erlaubt ihm, das systemd-Journal zu lesen. Auf Systemen der Red-Hat-Familie liegt das Paket in EPEL. Unter Debian 13 und Ubuntu 24.04 aktiviert das Paket das sshd-Jail bereits, mit dem Backend systemd und nftables, über /etc/fail2ban/jail.d/defaults-debian.conf.
Konfigurieren: jail.local
Bearbeiten Sie nicht jail.conf, denn Updates können sie ersetzen. Legen Sie Ihre Einstellungen in /etc/fail2ban/jail.local ab:
[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 203.0.113.10
bantime = 1h
findtime = 10m
maxretry = 5
[sshd]
enabled = true
backend = systemd| Einstellung | Bedeutung | Paket-Standard |
|---|---|---|
bantime | Wie lange eine Sperre dauert | 10m |
findtime | Das Zeitfenster, in dem sich Fehlschläge summieren | 10m |
maxretry | Erlaubte Fehlschläge in diesem Fenster | 5 |
ignoreip | Adressen, die nie gesperrt werden | keine |
backend | Woher die Logs kommen | auto |
Tragen Sie Ihre eigene feste Adresse in ignoreip ein, damit ein paar Tippfehler Sie nicht aussperren. Ändert sich Ihre Adresse, sorgen Sie für eine Konsole als Rückfall.
Nutzen Sie backend = systemd, wo SSH-Logs ins Journal gehen, wie unter aktuellem Debian, das womöglich gar keine /var/log/auth.log hat. Auf einem System, das diese Datei schreibt, können Sie stattdessen backend = auto und logpath verwenden.
Lauscht sshd auf einem anderen Port, fügen Sie dem Jail port = 2222 hinzu. Die Regel, die wir gesehen haben, passte nur auf den Port aus der Jail-Einstellung (tcp dport 22), eine Sperre auf dem falschen Port blockiert also nichts.
Testen Sie die Datei und starten Sie dann neu:
sudo fail2ban-client -t
sudo systemctl restart fail2banPrüfen, ob es wirklich funktioniert
sudo fail2ban-client status sshdStatus for the jail: sshd
|- Filter
| |- Currently failed: 0
| |- Total failed: 4
| `- Journal matches: _SYSTEMD_UNIT=ssh.service + _COMM=sshd
`- Actions
|- Currently banned: 1
|- Total banned: 1
`- Banned IP list: 203.0.113.20Machen Sie einen echten Test. Lassen Sie von einer anderen Adresse, nicht vom Server selbst und nicht von einer in ignoreip, eine Passwort-Anmeldung fehlschlagen und führen Sie den Befehl erneut aus. Total failed muss steigen. Bleibt es bei 0, liest das Jail nicht die richtigen Logs, und der Rest bewirkt nichts. Vergleichen Sie den Journal-Match mit dem Namen Ihrer Unit, ssh.service oder sshd.service, und prüfen Sie mit journalctl -u ssh -n 20.
Nach der Sperre sieht der Client Folgendes:
ssh: connect to host 203.0.113.10 port 22: Connection refusedDie Firewall-Regel sehen Sie mit sudo nft list ruleset:
table inet f2b-table {
set addr-set-sshd {
type ipv4_addr
elements = { 203.0.113.20 }
}
chain f2b-chain {
type filter hook input priority filter - 1; policy accept;
tcp dport 22 ip saddr @addr-set-sshd reject with icmp port-unreachable
}
}Alltägliche Befehle
| Ziel | Befehl |
|---|---|
| Jails auflisten | sudo fail2ban-client status |
| Eine Adresse entsperren | sudo fail2ban-client set sshd unbanip 203.0.113.20 |
| Alles entsperren | sudo fail2ban-client unban --all |
| Von Hand sperren | sudo fail2ban-client set sshd banip 203.0.113.20 |
| Sperren und ihr Ende sehen | sudo fail2ban-client get sshd banip --with-time |
| Eine Adresse sofort ignorieren | sudo fail2ban-client set sshd addignoreip 203.0.113.10 |
| Die verwendeten Einstellungen lesen | sudo fail2ban-client get sshd bantime |
| Sein Log lesen | sudo tail /var/log/fail2ban.log |
Die Änderung mit addignoreip gilt nur bis zum nächsten Reload. Tragen Sie sie in jail.local ein, um sie zu behalten.
Was als Fehlschlag zählt
Wir haben den Standardmodus mit OpenSSH 10.0 getestet, mit diesen Ergebnissen:
- Ein falsches Passwort zählte, ebenso ein falsches Passwort für einen nicht existierenden Benutzer.
- Ein Abbruch durch Too many authentication failures zählte als einer.
- Verbindungen, die einen falschen Schlüssel anboten und dann aufgaben, zählten nicht. Sie erscheinen im Log als
Connection closed by authenticating user.
Mit mode = aggressive im [sshd]-Jail wurden auch die Verbindungen mit falschem Schlüssel gezählt. Das erfasst mehr, erleichtert aber auch, jemanden mit schlecht konfiguriertem Client zu sperren, halten Sie ignoreip daher aktuell.
Wovor es nicht schützt
- Ein gestohlener Schlüssel oder ein geleaktes Passwort. Eine korrekte Anmeldung ist kein Fehlschlag, also gibt es keine Sperre.
- Langsames oder verteiltes Raten. Viele Adressen mit je ein oder zwei Versuchen bleiben unter der Grenze.
- Eine Schwachstelle in sshd selbst. Es reagiert auf Logzeilen, im Nachhinein.
- Andere Dienste, sofern sie keine eigenen Jails haben.
Es kann auch Ihnen schaden: Alle hinter einem Büro-NAT teilen eine Adresse, die Fehler einer Person können also das ganze Büro aussperren.
Gerät ein Schlüssel in falsche Hände, müssen Sie wissen, wo er eingetragen ist, und den SSH-Schlüssel von jedem Server entfernen.
Was wichtiger ist
Akzeptiert der Server nur Schlüssel, gibt es beim Passwort-Raten nichts zu raten, egal wie viele Versuche. Tun Sie also zuerst Folgendes:
- Nutzen Sie einen Schlüssel und schalten Sie die Passwort-Anmeldung ab.
- Begrenzen Sie mit einer Firewall oder einem VPN, wer Port 22 erreichen kann, wenn möglich.
- Prüfen Sie die übrigen sshd-Einstellungen.
Danach ist fail2ban eine nützliche Ergänzung, die die Logs ruhiger hält. Außerdem hat OpenSSH 9.8 und neuer ein eigenes PerSourcePenalties, standardmäßig an, das sich schlecht benehmende Adressen kurz abweist. Das ist viel kürzer als eine typische fail2ban-Sperre, die beiden ergänzen sich also gut.
Fragen
Wie entsperre ich eine IP in fail2ban?
Mit sudo fail2ban-client set sshd unbanip und der Adresse. sudo fail2ban-client unban --all hebt alle Sperren in allen Jails auf.
Wie prüfe ich, ob fail2ban funktioniert?
Führen Sie sudo fail2ban-client status sshd aus, lassen Sie eine Anmeldung von einer anderen Adresse scheitern und führen Sie den Befehl erneut aus. Total failed muss steigen. Bleibt der Wert bei 0, liest das Jail die SSH-Logs nicht.
Warum sieht ein gesperrter Client Connection refused?
Mit der Standard-nftables-Aktion unter Debian bekommt eine gesperrte Adresse ein Reject, daher gibt ssh Connection refused aus statt eines Timeouts. Eine Aktion, die Pakete verwirft, sähe stattdessen wie ein Timeout aus.
Zählen falsche SSH-Schlüssel als Fehlschläge?
Im Standardmodus nicht. In unserem Test erhöhten fünf Verbindungen mit einem falschen Schlüssel den Zähler nicht. mode = aggressive im Jail zählte sie dagegen.