SSH Sicherheit mit Fail2ban – Tipps zu Fail2ban

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

  • 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.

  • Sebastian says:

    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.

  • Sebastian says:

    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.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.