Fail2ban sollte eigentlich jedem Admin der Linux/Unix Server ein begriff sein, vor allem wenn er Server administriert die am www hängen.
Mit Fail2ban kann man automatisiert mit diversen Filterregeln es einem Angreifer schwer machen. Dabei schaut Fail2Ban in die entsprechenden Logfiles und erstellt anhand von Filterregeln dann Firewall-Regeln um den Angreifer auszusperren.
Bei SSH schaut Fail2Ban in die /var/log/auth.log
Versucht jemand nun jemand via SSH das Passwort vom Root User herauszufinden (Brute-Force), kann Fail2ban den Angreifer nach 3 versuchen ihn für die nächsten 24 Stunden via Firewall Regel aussperren. Das erschwert natürlich eine solche Brute-Force-Attacke.
Grundsätzlich sollten SSH Root-Logins nie via Passwort möglich sein!
(Leider gibt es hin und wieder andere Kundenwünsche und Ansichten.)
Unter Debian / Ubuntu erfolgt die Installation mit einem
apt-get install fail2ban
Danach findet man die Konfigurationsdaten unter /etc/fail2ban/… . Wir kopieren uns jetzt das Original und legen uns eine local Konfiguration an mit der wir nun fortan arbeiten.
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
Die Konfigurationsdatei jail.local ist hinreichend Dokumentiert, daher werde ich dies hier nicht im Detail erläutern.
Um fail2ban für z.B. SSH zu aktivieren muss enabled auf den wert true gesetzt werden
[ssh] enabled = true port = ssh filter = sshd logpath = /var/log/auth.log maxretry = 3
Datei speichern und danach fail2ban neustarten.
service fail2ban restart
Danach prüfen ob die Jails angelegt wurden:
iptables -L
Und nach ein paar tagen wird man in seinen Jails schon geblockte IP-Adressen finden.
Wichte Tipps:
bantime so hoch wie möglich stellen z.B. auf 48 Stunden:
bantime = 172800
Was viele vergessen:
Fail2ban reagiert nur auf IP Adressen im authlog. Schreibt OpenSSH anstelle der IP-Adresse den Reverse-DNS in die Logfile wird Fail2ban nicht darauf reagieren, und selbst wenn man sich dafür einen eigenen regex baut, ist dies realativ unsicher.
Daher in OpenSSH folgende Option setzen:
UseDNS no
Somit macht OpenSSH keine Reverse-DNS und Fail2ban kann seine Arbeit machen.
Nie blind fail2ban vertrauen! Selbst ist der Admin.
Viel Erfolg ;) !
5 comments on “SSH Sicherheit mit Fail2ban – Tipps zu Fail2ban”
UseDNS no
ist nicht (mehr) nötig. Siehe:
http://www.fail2ban.org/wiki/index.php/Features
Da beim händischen anschauen der Logs der DNS sehr hilfreich ist, würde ich nicht allgemein empfehlen dessen Anzeige zu deaktivieren.
Danke für den Hinweis.
Dennoch Problematisch wenn:
– OpenSSH via Reverse lookup einen host in authlog protokolliert z.B. v123456.somedomain.com
– Fail2ban den DNS Name versucht wieder aufzulösen und z.B. kein A-Record existiert weil der Angreifer auch zugriff auf den DNS hatte oder schlichtweg für diesen Server keiner existierte.
Dadurch wird fail2ban quasi ausgehebelt
Idealerweise einfach kein root ssh Login erlauben und schon gar nicht via passwort.
Trotzdem ist es wichtig die Logs regelmäßig selber zu prüfen. Es gibt immer wieder Angreifer die es pro Stunde nur 2 mal probieren nachdem Sie einmal ins blocking gelaufen sind. Das dann aber über Tage. Bei diesen Quellen greift Fail2ban nicht wirklich gut.
Kleine Korrektur, oder Ergänzung. Im Fail2ban muß für den Fall ein eigenes „jail“ konfiguriert werden mit einer hohen Werten für maxretry und findtime.
@Sebastian
Richtig, daher auch mein letzter Satz „Nie blind fail2ban vertrauen! Selbst ist der Admin.“ ;)