Wie ich in einem vorherigen Beitrag ja bereits erwähnt hatte, ist eine (Software-) Firewall ein wichtiges Werkzeug, mit dem die Sicherheit eines Linux Servers erhöht werden kann. Problematisch sind aber Dienste, die generell für alle aus dem Internet verfügbar sein müssen, wie beispielsweise Mail- und Web-Dienste. Oft kann ein Angreifer tage- oder gar wochenlang automatisiert und systematisch Passwörter für beispielsweise einen SSH Zugang oder ein E-Mail Konto durchprobieren. Abhilfe schafft hier Fail2Ban, welches nach fehlerhaften Anmeldeversuchen in Log-Dateien sucht und bei einem Fund die entsprechende IP Adresse mit Hilfe der Firewall sperrt.
Installation
Unter Debian 8 Jessie ist die Installation leicht und es sind bereits ebenfalls viele nützliche Filter vorhanden:
|
1 2 3 4 5 6 7 8 9 10 |
# Installation apt-get install fail2ban # In das Konfigurationsverzeichnis wechseln cd /etc/fail2ban # Die Standard-Konfiguration jail.conf studieren vim jail.conf # oder mit more more jail.conf # jail.local für eigene Einstellungen im nächsten Schritt anlegen touch jail.local |
Konfiguration
Die Standard-Konfigurationsdatei jail.conf sollte aufgrund späterer Paketaktualisierungen nicht verändert werden, stattdessen wird eine jail.local angelegt, in der Parameter überschrieben und neue hinzugefügt werden können. Meine jail.local auf dem Mail-Server sieht so aus:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
[DEFAULT] ignoreip = 127.0.0.1/8 bantime = 86400 findtime = 600 maxretry = 3 [ssh-ddos] enabled = true port = ssh filter = sshd-ddos logpath = /var/log/auth.log maxretry = 6 [postfix] enabled = true port = smtp,ssmtp,submission filter = postfix logpath = /var/log/mail.log [dovecot] enabled = true port = smtp,ssmtp,submission,imap2,imap3,imaps,pop3,pop3s filter = dovecot logpath = /var/log/mail.log |
Roundcube und Apache Filter
Wenn in 10 Minuten (findtime) 3 Zeilen mit fehlerhaften Login (maxretry) gefunden wurden, wird die entsprechende IP Adresse für einen Tag (bantime) blockiert. Auf dem Webserver verwende ich andere Regeln, u.a.:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
[roundcube-auth] enabled = true filter = roundcube-auth port = http,https logpath = /var/log/apache2/webmail.pimux.de_access.log [apache] enabled = true port = http,https filter = apache-auth logpath = /var/log/apache*/*error.log maxretry = 6 |
Die Webmail Anwendung Roundcube läuft bei mir nicht auf dem Mail-, sondern auf dem etwas schnelleren Webserver, weshalb ich diese Regel an dieser Stelle verwende.
WordPress Filter
Auch für WordPress lässt sich ein Filter implementieren, allerdings ist die Log-Datei des Webservers nicht aussagekräftig genug. Deswegen muss für die jeweilige WordPress Installation noch das Plugin WP fail2ban installiert werden. Anschließend müssen die Zwei Filter-Dateien noch nach in das Fail2Ban Verzeichnis kopiert werden:
|
1 2 |
# Pfad zur Wordpress Installation muss natürlich entsprechend angepasst werden cp /var/www/wordpress/wp-content/plugins/wp-fail2ban/wordpress-*.conf /etc/fail2ban/filter.d/ |
Nun müssen die Filter noch in der jail.local aktiviert werden:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
[wordpress-hard] enabled = true filter = wordpress-hard logpath = /var/log/auth.log port = http,https maxretry = 1 [wordpress-soft] enabled = true filter = wordpress-soft logpath = /var/log/auth.log port = http,https maxretry = 3 |
Bedienung
Für die Bedienung von Fail2Ban kommt man mit wenigen Kommandos gut zurecht:
|
1 2 3 4 5 6 |
# Jails anzeigen fail2ban-client status # Den Status des Postfix Jails anzeigen (u.a. gesperrte IPs anzeigen) fail2ban-client status postfix # Eine IP des Postfix Jails entsperren fail2ban-client set postfix unbanip 192.168.1.23 |
Wenn die Konfiguration erledigt ist, muss Fail2Ban noch einmal mit systemctl restart fail2ban neugestartet werden. Funde und Sperrungen kann man in der /var/log/fail2ban.log finden.
Als Ergänzung dazu:
Auf meinem virtuellen Server habe ich nicht die Möglichkeit iptables zu konfigurieren. In dem Fall funktioniert auch „denyhosts“ sehr gut.
Warum nicht einfach Passwort Login verbieten? Dann stellt sich das Problem erst gar nicht und an Sicherheit ist auch gewonnen.
Stimmt, natürlich sollte kein SSH Login mit Passwort erlaubt sein. Trotzdem wird manchmal einfach blind eine Brute Force Attacke auch auf solche Server angewendet, was einen kleinen DoS Effekt haben kann. Das ist recht unschön und kann bei kleineren Server die Last spürbar anheben.