Geschrieben am von & gespeichert unter Sicherheit.

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

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.

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

Datei speichern und danach fail2ban neustarten.

Danach prüfen ob die Jails angelegt wurden:

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:

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:

Somit macht OpenSSH keine Reverse-DNS und Fail2ban kann seine Arbeit machen.

Nie blind fail2ban vertrauen! Selbst ist der Admin.

Viel Erfolg ;) !

 

 

5 Antworten auf “SSH Sicherheit mit Fail2ban – Tipps zu Fail2ban”

  1. Jann Heider

    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.

  2. Sebastian

    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.

  3. Sebastian

    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.

  4. Jann Heider

    @Sebastian
    Richtig, daher auch mein letzter Satz „Nie blind fail2ban vertrauen! Selbst ist der Admin.“ ;)

Schreiben Sie eine Antwort

  • (wird nicht veröffentlicht)