fail2ban HOWTO (automatisch blocken anhand von log-files)

Achtung!
Dieser Artikel ist uralt und die Informationen darinnen ziemlich sicher nicht mehr zutreffend!

Es gibt viele kleine Helferlein, mit denen man einzelne Dienste recht effektiv absichern kann. Einige dieser Tools habe ich hier bereits beschrieben - ein weiteres folgt nun: fail2ban.
Ein grosser und wichtiger Unterschied von fail2ban zu anderen, spezialisierten Tools ist, dass es einfach nur log-files analysiert und dann nach bestimmten, definierbaren Regeln, ebenfalls definierbare Filter-Aktionen ausloest.
Klingt kompliziert? Ist es aber nicht..

Vorteile

Neben dem Mehr an Sicherheit, welches fail2ban bringt, hat es gegenueber aehnlichen Anwendungen noch einige entscheidende Vorteile:

Der erste und offensichtlichste Vorteil von fail2ban ist auf jeden Fall seine Flexibilitaet.. Es gibt quasi nichts, was ein log produziert, was mit fail2ban nicht noch ein Bischen sicherer gemacht werden kann..

Ein weiterer Vorteil, der mir vor einiger Zeit auffiel ist, dass man hiermit auch iptables-Regeln fuer Ereignisse innerhalb von Vservern erstellen kann: Innerhalb eines Vservers ist die Benutzung von iptables nicht moeglich, aber man kann fail2ban einfach auf dem host-Rechner installieren und die Pfade zu den Logfiles entsprechend anpassen..

Installation

Wie immer gehe ich in diesem Howto von einem aktuellen Debian-System (im Moment etch) aus. Gerade die Installation wird auf anderen Systemen anders funktionieren. Lest hierzu bitte die Anleitung Eurer Distribution, checkt Euer Repository, ob es vielleicht schon ein vorcompiliertes Paket gibt oder schaut mal hier vorbei: Fail2Ban Downloads.
Unter Debian ist die Installation erfreulich einfach:

~#> aptitude install fail2ban

fertig..

Konfiguration

Die Debian-Installation kommt gleich mit einer ganzen Menge Beispiel-Konfigurationen, die jedoch mindestens noch aktiviert, evtl auch noch angepasst werden muessen.
Zum besseren Verstaendniss werde ich hier aber die Erstellung eines ganz neuen Filters erklaeren. Da hiernach in einem anderen Howto bereits gefragt wurde, nehme ich Apaches mod_evasive als Beispiel:

Zunaechst muss eine neue Filter-Regel erstellt werden. Diese gehoeren in jeweils eigene Dateien in dem Verzeichniss "/etc/fail2ban/filter.d/":

[Definition] failregex = [[]client <HOST>[]] client denied by server configuration ignoreregex =

failregex: Regulaerer Ausdruck, mit dem nach zu filternden IPs gesucht werden soll.
<HOST>: Platzhalter fuer die IP bzw. den Hostname im Logfile.
ignoreregex: Falls ganz bestimmte Faelle wiederum doch nicht gefiltert werden sollen, kann hier eine entsprechende regex eingetragen werden..

Der korrespondierende Log-Eintrag koennte zum Beispiel so aussehen:

[Tue Aug 12 11:53:58 2008] [error] [client 123.123.123.123] client denied by server configuration: /somewhere

(Anm: Meinem Verstaendniss nach muesste die RegEx besser so aussehen: \[client <HOST>\] client denied by server configuration - warum sie das nicht tut, kann ich leider nicht wirklich erklaeren.. Ich habe sie auf der Grundlage der apache-auth-config erstellt und habe die ganzen eckigen Klammern einfach mal uebernommen - funktioniert..)

Nun muss die Regel eingebunden werden. Dies tun wir in der Datei "/etc/fail2ban/jail.local".
Einfach folgende Zeilen ganz unten an die Datei anhaengen:

[apache-evasive]  enabled = true  port    = http  filter  = apache-evasive  logpath = /var/log/apache*/hosts/*error.log  maxretry = 2  #action=

enabled: true/false - ob die Regel aktiviert werden soll, oder nicht..
port: Der zu filternde port (oder service-name.. http = port 80)
filter: Welcher Filter angewendet werden soll. Einfach den Namen der config-datei aus "/etc/fail2ban/filter.d/" ohne das angehaengte ".conf" uebernehmen.
logpath: Kompletter Pfad zu der zu checkenden log-datei (wildcards erlaubt)
maxretry: Wie oft der Filter zuschlagen darf, bevor eine Aktion (siehe unten..) eingeleitet werden soll.
action: Hier kann eine individuelle Aktion eingestellt werden. Wenn nicht, wird die default-aktion uebernommen, die wir gleich konfigurieren werden..

Wollen wir nun noch einige der (sehr praktischen) Beispiel-Filter aktivieren, finden wir Beispiel-Konfigurationen in der Datei "/etc/fail2ban/jail.conf". Damit unsere Aenderungen beim naechsten groessen update des Paketes nicht gleich wieder ueberschrieben werden, aendern wir hier jedoch nicht, sondern kopieren den entsprechenden Block und fuegen ihn wieder unten an die Datei "/etc/fail2ban/jail.local" an:

[vsftpd]  enabled  = true  port     = ftp  filter   = vsftpd  logpath  = /var/log/auth.log  maxretry = 6

aus dem "false" bei "enabled" machen wir natuerlich ein "true", da wir sie ja aktivieren wollen...

Zuletzt muessen noch ein paar grundlegende Einstellungen vorgenommen werden. Die Voreinstellungen koennen wir wieder der Datei "/etc/fail2ban/jail.conf" entnehmen. Unsere Aenderungen kommen aber auch wieder in die Datei "/etc/fail2ban/jail.local". Diesmal nach ganz oben, ueber unsere bisherigen Eintragungen (in wie fern das wichtig ist, weiss ich nicht - uebersichtlicher ist es allemal..)

[DEFAULT] ignoreip = 127.0.0.1 bantime  = 600  maxretry = 3  backend = polling  destemail = you@ home.org action = iptables[name=%(__name__)s, port=%(port)s]

ignoreip: Vom Filtern ausgeschlossene IP. (damit z.B. localhost nicht ausversehen geblockt wird..)
bantime: Wie lange Blocks aufrecht erhalten werden sollen (in Sekunden)
maxretry: Wie oft ein Filter zuschlagen muss, bevor eine Aktion eingeleitet wird.
backend: Wie fail2ban an seine Daten kommen soll. Laut Kommentaren in der default-config funktioniert zur Zeit nur "polling".
destemail: Wer soll bei eingeleiteten Aktionen benachrichtigt werden.
action[]: Die einzuleitende Aktion, wenn ein Filter $maxretry mal zutraf. Siehe unten...
%(__name__)s: Wird durch den Namen des gerade zutreffenden Filters ersetzt
%(port)s: Wird durch den zu blockierenden Port ersetzt

Was bis jetzt noch nicht wirklich geklaert wurde, sind die Aktionen:
Man kann bei fail2ban nicht nur eigene filter erstellen, sondern auch eigene Aktionen, die eingeleitet werden sollen. Oder man nimmt, wie ich, eine der mitgelieferten Beispiel-Aktionen, die man in "/etc/fail2ban/action.d" findet.
Hier gibt es jede Menge moeglicher Aktionen, so dass ich bisher noch nie in die Verlegenheit kam, eine eigene zu erstellen.
In unserem Beispiel benutzen wir die Aktion / Konfiguration "iptables.conf":

[Definition]  action-start = iptables -N fail2ban-<name>  iptables -A fail2ban-<name> -j RETURN  iptables -I INPUT -p <protocol> --dport <port> -j fail2ban-<name> action-stop = iptables -D INPUT -p <protocol> --dport <port> -j fail2ban-<name>  iptables -F fail2ban-<name> iptables -X fail2ban-<name> actioncheck = iptables -n -L INPUT | grep -q fail2ban-<name> actionban = iptables -I fail2ban-<name> 1 -s <ip> -j DROP  actionunban = iptables -D fail2ban-<name> -s <ip> -j DROP   [Init] name = default  port = ssh  protocol = tcp

actionstart: Was beim Start von fail2ban ausgefuehrt werden soll - in diesem Beispiel wird eine eigene iptables-chain erstellt.
actionstop: Was beim Beenden von fail2ban ausgefuehrt werden soll - in diesem Beispiel wird die in actionstart erstellte iptables-chain wieder geloescht..
actioncheck: Was ausgefuehrt werden soll, um zu zu checken, ob "alles okay" ist - in diesem Beispiel wird nach der in actionstart erstellten iptables-chain gesucht.
actionban: Die tatsaechliche Aktion - was soll passieren, um eine gefilterte IP zu blocken - in diesem Beispiel wird eben eine iptables-regel abgesetzt, die die IP blockt.
actionunban: Die Aktion, die ausgefuehrt werden soll, wenn eine IP fuer eine Zeit von $bantime (siehe oben..) nicht mehr gefiltert wurde - in diesem Beispiel wird die in actionban erstellte iptables-regel wieder geloescht.
[Init]: Hier koennen ein paar defaults angegeben werden, die durch entsprechende Eintragungen in der jail.local wieder ueberschrieben werden koennen..
name: Der Name der Filter-Regel (und somit der iptables-chain..)
port: Welcher Port soll geblockt werden?
protocol: Welches Protokoll soll geblockt werden? Moeglich sind: tcp / udp / icmp / all

Andere moegliche Aktionen waeren: hostsdeny ipfw iptables iptables-new mail mail-whois  mail-whois-lines und shorewall
Die Namen beschreiben die jeweilige Funktion ja schon recht gut - fuer weitere Informationen lohnt ein Blick in die Datei..

Test

Wenn wir nun fail2ban scharf schalten, ist hoechste Vorsicht und vollste Aufmerksamkeit gefragt. So, wie wir es nun konfiguriert haben, sperrt fail2ban ganz rigoros per iptables. Im schlimmsten Fall koennten es zum Beispiel passieren, dass wir nicht mehr per ssh auf unseren eigenen Server kommen, um eventuelle Fehler wieder auszubuegeln.
Es empfiehlt sich als, nur mit dynamischer IP zu testen, da man so bei einem versehentlichen Block schnell die IP wechseln kann..
Also los: Wir beobachten in einer Session (oder screen) das fail2ban-logfile:

tail -f /var/log/fail2ban.log

Und in einem anderen starten wir fail2ban neu:

/etc/init.d/fail2ban restart

Nun erscheinen zunaechst einige INFO-Meldungen im fail2ban-log, was wie gefiltert wird und wie darauf reagiert werden soll. (Eben unsere ganzen Einstellungen von oben..)
Nun koennen wir ersteinmal testen, ob denn die eingestellten Filter auch wie gewuenscht greifen. Schoen einfach geht das mit dem FTP-Filter. Loggt Euch einfach 7 mal mit falschem Passwort per FTP ein und guckt im Logfile von fail2ban, was passiert...
Programm-Bedingt kann ein Moment vergehen, bevor fail2ban anspringt. Wartet gegebenenfalls ein paar Sekunden / eine Minute..
Erscheint ein Eintrag aehnlich diesem hier im log, funktioniert der Filter:

2008-08-12 12:23:56,945 fail2ban.actions: WARNING [vsftpd] Ban 123.123.123.123

...und koennen wir dann tatsaechlich nicht mehr per FTP verbinden, funktioniert auch die Aktion...

Wesentlich wichtiger als das ist es jedoch zu testen, dass niemand versehentlich geblockt wird, der eigentlich gar nicht geblockt werden sollte...
Je nach aktivierten Filtern und Verkehr auf den entsprechenden Diensten, kann man entweder einfach mal alles durchprobieren, was man halt so macht, mit seinem System, oder aber (der warscheinlichere Fall..) es hilft nur Geduld und ein wachsames Auge..  Auf gar keinen Fall jedoch sollte man fail2ban scharf schalten und dann vergessen - das kann boes in's Auge gehen..

Wenn einmal eine IP faelschlicherweise geblockt wurde und man nicht 10 Minuten warten kann, bis sie automatisch wieder unblocked wird, kann man sie mittels iptables natuerlich auch manuell wieder entsperren. Hierzu sehen wir uns erst einmal alle iptables-regeln an, die aktuell so aktiv sind:

~#> iptables -L -n

...und suchen uns die zu der gewuenschten IP passende raus...
Die einzelnen Regeln sind sichtbar in Bloecke unterteilt und jeder dieser Bloecke hat eine Titelzeile. Dieser Titelzeile entnehmen wir den chain-namen. Im obigen Beispiel hiesse die Chain "fail2ban-vsftpd". Als zweite Option benoetigen wir noch die "Rule-Number" - die Nummer der zu loeschenden Regel.
Hierzu zaehlen wir alle Regeln unserer Chain, bis zu der zu loeschenden ab. Beginnend bei 1.
Beispiel:

Chain fail2ban-vsftpd (1 references) target     prot opt source               destination  DROP      0    --  123.123.123.123  0.0.0.0/0  DROP      0    --  4.8.15.16   0.0.0.0/0 RETURN   0    --  0.0.0.0/0            0.0.0.0/0

Wollen wir nun die IP 4.8.15.16 unblocken, waere das Regel Nummer 2. Die 123.123.123.123 waere Nummer 1. Die Chain heisst in diesem Beispiel: "fail2ban-vsftpd".
Daraus resultiert folgender Befehl, um die IP "4.8.15.16" wieder freizugeben:

~#> iptables -D fail2ban-vsftpd 2

Solcherart ausgeruestet und wachsam, kann eigentlich nichts wirklich schlimmes mehr passieren..

Nachwort

Wie immer in meinen HOWTOS nehme ich nicht fuer mich in Anspruch die perfekte Loesung zu kennen - wenn jemand etwas besser weiss, bitte einfach die Kommentar-Funktion benutzen und uns daran teilhaben lassen.. :)
Ausserdem uebernehme ich natuerlich keinerlei Haftung fuer eventuell entstehende Schaeden an Server, Leib, Seele oder sonst irgendwas..