fail2ban – Du kommst hier nicht rein
Ich sichere schon seit Jahren meine Linux-Server mit fail2ban ab. Grund genug, den kleinen Wächter hier einmal kurz vorzustellen:
Was ist fail2ban?
fail2ban ist ein kleiner in Python geschriebener Dienst, der im Hintergrund die Serverlogs auf Einbruchsversuche aus dem Netz hin untersucht, und ggf. eine Angreifer-IP eine festgelegte Zeit für den Server-Zugriff blockt.
Dabei nutzt das Programm iptables, um Angreifer über entsprechende Regeln am System-Zugriff zu hindern, versucht also nicht selbständig irgendwelche verdrehten Versuche, sich in den Netzwerk-Traffic einzumischen.
Das Tool ist zwar keine Wunderwaffe, es prüft lediglich die Einträge in Logfiles auf festgelegte Regular Expressions, filtert im Übereinstimmungsfall die Quell-IP aus dem Eintrag heraus und legt ggf. einen iptables-Eintrag an, dabei ist es jedoch höchst effektiv.
Brute-Force-Attacken werden so höchst zuverlässig geblockt, das ist auch das Hauptanwendungsfeld von fail2ban. Man kann aber z.B. auch Filter für seinen Webserver anlegen, die bekannte Muster von Cross-Site-Scripting-Attacken suchen und die aufrufende IP umgehend blocken.
Wie nutzt man fail2ban?
Auf einem Debian-basierten System ist fail2ban schnell mit
# apt-get install fail2ban
installiert.
Danach liegen unter /etc/fail2ban die Konfigurationsdateien. Die wichtigste ist sicherlich die jail.conf, hier werden die Dienste eingetragen, die fail2ban überwachen soll. Der Eintrag für den sshd sieht beispielsweise so aus:
[ssh] enabled = true port = ssh filter = sshd logpath = /var/log/auth.log maxretry = 6
Dieser Eintrag besagt, dass der Dienst „ssh“ überwacht werden soll, bei sechs fehlgeschlagenen Anmeldeversuchen wird der Port 22 („ssh“) geblockt, als Basis für den Filter „sshd“ wird die Log-Datei /var/log/auth.log benutzt.
Die Filter selbst liegen unter /etc/fail2ban/filter.d/*.conf, fail2ban bringt hier schon einige mit. So lassen sich in der Standardkonfiguration direkt der Apache oder einige Mailserver beobachten, auch über xinetd gestartete Dienste oder natürlich der oben beschriebene sshd lassen sich out of the box schon überwachen.
Für paranoide Admins lässt sich in der jail.conf auch ein Eintrag aktivieren, der bei gesperrten IPs eine Mail mit dem WHOIS-Eintrag des Angreifers und ggf. des relevanten Logdatei-Ausschnittes an eine festgelegte Adresse versendet.
Eigene Dienste in fail2ban integrieren
Auf die oben beschriebene Weise lassen sich so auch einfach eigene Dienste zur Überwachung einrichten. Als Beispiel hält hier das WordPress-Plugin „WP fail2ban“ her.
Dieses überwacht, wie der Name vermuten lässt, die WordPress-Installation auf fehlerhafte Anmeldeversuche.
Nach der Installation und Aktivierung des Plugins über die Administrationsoberfläche von WordPress werden die Anmeldeversuche an der WordPress-Administrationsseite in die Datei /var/log/auth.log protokolliert.
Nun muss einfach die mitgelieferte Filterdatei
./wp-content/plugins/wp-fail2ban/wordpress.conf
nach /etc/fail2ban/filter.d/ kopiert werden. Danach bindet man diese noch in die bereits oben beschriebene /etc/fail2ban/jail.conf ein:
[wordpress] enabled = true port = 80 filter = wordpress logpath = /var/log/auth.log maxretry = 5
Schließlich muss nur noch der Daemon neu gestartet werden (etc/init.d/fail2ban restart) und schon ist WordPress gegen einen Angriffsmuster mehr gesichert.
Fazit
Wenig Aufwand für erheblich mehr Sicherheit. Wer das Tool nicht nutzt, sollte sich schnellstmöglich an seine Konsole setzen…