fail2ban – SSH, Apache, Nginx, Postfix

Fail2ban ist eine wunderbare Hilfe für jeden Linux-Administrator, um SSH, Apache, Nginx oder Postfix abzusichern. Egal ob mit Ubuntu, Debian GNU/Linux, RedHat oder SUSE Linux. Das Programm fail2ban wurde in python geschrieben und beobachtet vordefinierte Logs nach unerlaubten Zugriffen oder Angriffen auf Server sowie anderen Diensten auf dem Linux-Server.

Die in den Logtexten gefundenen IP-Adressen der Angreifer werden dann nach einer vorgegeben Zeit und Wiederholungsrate komplett per iptables-CHAIN (firewall) mit einer DROP-Regel für einen definierten Zeitraum ausgesperrt. Und jetzt kommt der wichtige Teil.

Fail2ban nimmt damit die Last vom Server, so dass dieser nicht vor lauter Anfragen in die Knie geht. DOS-Angriffe (Denial of Service) können auch mit dem mod_evasive (libapache2-mod-evasive) beim Apache oder request-limit-Regeln (ngx_http_limit_req_module) beim Nginx Webserver unterbunden werden. Ebenfalls können Dateizugriffe verboten werden. Dazu erhält aber der Webserver direkt immer wieder eine Anfrage, die er dann mit „404 Zugriff verboten“ ablehnt.

Bei Botnetzen ist das keine Lösung und kann den Server zum Stillstand bringen, durch zu viele Anfragen. Fail2ban lässt aber diese unnötigen Zugriffe gar nicht erst durch und entlastet den Server oder Dienst damit. Auch EMail-Server wie Postfix, sendmail oder qmail können geschützt werden. Also jegliche Dienste, die Logtexte schreiben, kann fail2ban absichern.

Installation und Regeln für fail2ban

Die Installation von fail2ban ist relativ simpel. Die bekannten Linux-Distributionen bringen schon fertige Pakete mit.

apt-get update && apt-get install fail2ban

sollte bei einer Debian ausreichen. Danach wird fail2ban in

/etc/fail2ban/

installiert.

/etc/fail2ban/action.d/

Für die Maßnahmen und Regeln und in

/etc/fail2ban/filter.d

sind die vordefinierten Filter, die man anpassen kann oder auch neue hinzufügen kann. Nach der Installation ist es ratsam, zuerst mit dem mitgelieferten fail2ban-regex die Regeln zu überprüfen. In folgendem Beispiel:

fail2ban-regex -v /var/log/apache2/forum_access.log /etc/fail2ban/filter.d/apache-badbots.conf

ob der Filter apache-badbots überhaupt anschlägt. Hier ist es wichtig die Logtextformate genau zu berücksichtigen. Besonders wenn diese manuell abgeändert wurden, kann fail2ban eventuell nicht mehr genau die Filter anwenden und erhält keine Treffer. Auch maxretry und bantime hier wird nicht berücksichtigt.

Die individuelle Konfiguration von fail2ban wird in der Datei

jail.local

vorgenommen. Bei einem zukünftigen Update des Software-Pakets wird ansonsten die jail.conf überschrieben.

Anbei ein Beispiel mit einer Regel für den Webserver Nginx auf dem WordPress läuft und etliche Login-Versuche mit diversen Passwort-Kombinationen gestartet werden:

[nginx-wplogin]

enabled = true
port = http,https
filter = nginx-wplogin
maxretry = 3

Achtung: Fail2ban kann auch Google, Yahoo, Bing oder andere Suchmaschinen komplett aussperren, oder sich selbst über ssh, wenn fail2ban falsch konfiguriert ist.

WordPress XMLRPC sperren

Viele Webmaster sperren die Datei xmlprc.php (XML remote procedure protocol ) aufgrund der vielen XMLRPC Brute Force Angriffen von meist osteuropäischen, ukrainischen, chinesischen oder russischen Botnetzen. Auch um an User-Logins über diese PHP-Datei zukommen (wp.getUsersBlogs), das Botnetz zu erweitern oder einfach nur Massen-Spam abzusetzen.

Um WordPress vor Brute-Force-Angriffe über User-Logins mit der xmlrpc.php zu schützen, kann in der funktions.php des verwendeten Themes folgender Filter helfen:

add_filter('xmlrpc_methods', function($methods) {
unset($methods['wp.getUsersBlogs']);
return $methods;
});

Und in der Apache-Konfiguration:


Order allow,deny
Deny from all

Oder beim Nginx Webserver im Server-Block:

server {
...
location = /xmlrpc.php {
return 403;}
...
}

Wer diese Angreifer beim Anfragen nach der xmlrpc.php aussperren möchte, kann über eine spezielle Regel und Filter mit fail2ban dieses umsetzen. Dazu kopiert man sich den Logtext-Eintrag in den entsprechenden Filter (dokumentiert diesem Beispiellogtexteintrag natürlich aus mit „#“) und testet den Filter, bis fail2ban greift. Beim Testen wird maxretry ignoriert.

Auch beliebt im Moment sind Scans nach:

adform/IFrameManager.html
mnews.htm (SQL-Injektionen über unsichere Plugins)
*.blogspot.com.* (SQL-Injektionen)
phpmyadmin (in etlichen Wortvarianten)
xmlprc.php
wp-login.php

phpmyadmin sollte man bei Verwendung auf ein anderes Verzeichnis mit einem Alias in der /etc/apache2/conf.d/phpmyadmin.conf (Debian) umleiten:

Alias /neuer-name /usr/share/phpmyadmin

Damit wäre dann phpmyadmin unter www.deinewebsite.de/neuer-name erreichbar.

Den root-login in der /etc/phpmyadmin/config.inc.php verbieten:

$cfg['Servers'][$i]['AllowRoot'] = false;

Der SSH-Dämon ist sehr beliebt, um den Server unter Kontrolle zu bekommen und sollte immer auf einen anderen freien Port in der /etc/ssh/sshd_config umgeleitet werden hier z.B der Port 89745:

Port 89745

NGINX

Um den Massenspam schon vor dem CMS oder WordPress mit Plugins wie Antispan Bee oder Akismet abzuwehren, ist bei Nginx das Nginx GeoIP-Modul sehr hilfreich. Konsequent kann damit der IP-Bereich eingegrenzt werden und Zugriffe auf spezielle Webseiten nur aus vorgegebenen Ländern eingekreist oder komplett verboten werden.

Zum Beispiel im Server-Block nur die Zugriffe auf /wp-admin, /wp-login.php und wp-comments.php für die Länderkürzel CN|US|TW|UK|RO|PL|KR|RU|UA|KZ|BR|TR verbieten mit einem eleganten 444:

set $cc "";
 if ($request_uri ~* ^/(wp-admin|wp-login\.php|wp-comments-post\.php)){
        set $cc $geoip_country_code;
 }
 if ($cc ~ (CN|US|TW|UK|RO|PL|KR|RU|UA|KZ|BR|TR)) {
        return 444;
}

In der nginx.conf im http-Block den Pfad zur GeoIP.dat angeben:

geoip_country /etc/nginx/GeoIP.dat;

Diese Datei GeoIP.dat mit den IP-Pools der Länder der Welt, kann sich wie folgt als root geladen werden:

cd /etc/nginx/geoip
wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCountry/GeoIP.dat.gz
gunzip GeoIP.dat.gz

Ob nginx mit dem GeoIP-Modul kompiliert wurde, kann einfach mit:

nginx -V

herausgefunden werden. Nach "... --with-http_geoip_module ... " muss gesucht werden.

Gerade aus den IP-Adressbereichen der Länder China, Ukraine, Russland, USA, Türkei… versuchten tagelang Bots ihren Massenspam über die wp-comments-post.php im Sekundentakt abzuladen oder bombardierten die wp-login.php direkt mit Einbruchsversuchen bzw. Brute-Force-Attacken. Nginx limit-requests half dabei die Angriffe abzuwehren und fail2ban hat die IPs dann vorerst komplett gesperrt.

Somit sind ab sofort diese Länder bei mir komplett auf der Blackliste in den Kommentaren. Seitdem sind auch die Spam-Kommentare auf gerade einmal 1-3 pro Tag von ca. 150 pro Tag gesunken.

Mal ehrlich, welcher Chinese kann Deutsch? Oder welche chinesische Suchmaschine interessiert sich für eine deutsche Webseite oder Blog? Welcher Russe möchte sich an meinem Blog anmelden?

Aber die meisten Botnetzbetreiber sind auch nicht blöde und schießen nur ein paar wenige Anfragen von identischen IP-Adressen ab und wechseln diese sofort, weil sie honeypots oder fail2ban kennen und auch wissen, wie diese funktionieren. Die Botnetze scannen auf CMS- oder Blog-Systemen nach Sicherheitslücken, versteckten Dateien, fehlerhaften Plugins, Datenbank-Backups oder anderen Sicherheitslücken, um einzufallen. Ist die xmlrpc.php gefunden, wird parallel mit Anfragen von echten Kategorien, Tags oder anderen Blog-Seiten Interesse vorgetäuscht und dann immer wieder kurz über GET / POST xmlrpc.php versucht, einzubrechen oder Spam loszuwerden. Überwiegend wird nur versucht ein Kommentar abzusenden, welcher Links enthält.

Natürlich gibt es viele Plugins für WordPress, die Sicherheit vorgaukeln. Aber immer mehr installierte Plugins ziehen die Performance von WordPress herunter, wollen Backlinks verteilen oder sind schlecht von Hobby-Bastlern programmiert. Selbst Woocommerce Plugins sind davon betroffen und werden zur Zeit auf Fehler abgespannt.

Der Klassiker ist natürlich die versteckte .htaccess beim Apache Webserver oder phpmyadmin zur einfachen Verwaltung der MySQL-Datenbanken. Alle zusätzlichen und vor allem unnötigen grafischen Werkzeuge wie plesk bei Hostern, sind nur zusätzliche Sicherheitsprobleme. Angreifer freuen sich darüber, über einen einfachen Login mit username und password vollen Zugriff zu erhalten.

Als Grundsatz gilt schon seit dem Boom von Linux auf dem Webserver:
Jegliche grafischen Werkzeuge gehören auf keinen Server der Welt.
Ein Linux-Server lässt sich meist viel schneller und sogar praktischer unter der Konsole verwalten.
Ebenso spart dieses Ressourcen und bietet weniger Angriffsflächen.
Alles was man nicht benötigt, sollte man deinstallieren, sofern möglich oder deaktivieren.
Das gilt für viele hübsche, bunte Plugins beim Apache und auch des verwendeten CMS / Blog-System wie WordPress.

Die Maßnahmen müssen direkt auf dem Server und erst recht vor der WordPress-Installation ergriffen werden. Dazu ist fail2ban ideal. Wie immer gibt es keine hundertprozentige Sicherheit, aber einen großen Schritt dorthin.

Leider kann bei extremen Angriffen fail2ban gar nicht so schnell sperren (bannen) wie die Logs geschrieben werden. Auch ein Buffer im Log, wie es beim nginx

access_log /spool/logs/nginx-access.log compression buffer=32k;

oft empfohlen wird, muss deaktiviert oder verkleinert werden und kann sonst zu einer entsprechenden Verzögerung führen, da fail2ban nur die geschriebenen Logtexte überwacht.

Alternativen um Spam-Bots oder gekaperte Blogs abzuwehren

Für den Nginx Webserver gibt es noch eine Variante per Spamhaus Droplist bekannte Spam-Bots oder IP-Adressen auszusperren. Sehr praktisch wie ich finde, denn die Liste wird ständig aktualisiert.

Links zum Thema Sicherheit:

Fail2ban Website
Fail2ban einrichten
fail2ban bei heise security
fail2ban und SSH unter Ubuntu
Server-Configs für Nginx
Nginx und WordPress
Server-Configs für Apache
Die ultimative .htaccess für Apache