Fail2ban Fehlermeldung

T

tsk

Member
Hallo zusammen,

ich habe gestern Fail2ban in Betrieb genommen und nach und nach die zu überwachenden Logs per entsprechendem Jail hinzu gefügt. Aufgefallen ist mir dabei, dass (fast) keines der vordefinierten Failregex für meine Ubuntu 8.04 Logformate geeignet war. Also passende Failregex pro Log erstellt und getestet mittels fail2ban-regex. Alle funktionieren mit (älteren) Logfiles, die entsprechende Ereignisse aufweisen.
Nach Neustart von Fail2ban werden folgende Logeinträge geschrieben:
Code: 
2011-02-22 17:22:51,139 fail2ban.jail   : INFO   Using poller
2011-02-22 17:22:51,165 fail2ban.filter : INFO   Created Filter
2011-02-22 17:22:51,165 fail2ban.filter : INFO   Created FilterPoll
2011-02-22 17:22:51,166 fail2ban.filter : INFO   Added logfile = /var/log/apache2/error.log
2011-02-22 17:22:51,169 fail2ban.filter : INFO   Set maxRetry = 3
2011-02-22 17:22:51,170 fail2ban.filter : INFO   Set findtime = 600
2011-02-22 17:22:51,171 fail2ban.actions: INFO   Set banTime = 3600
2011-02-22 17:22:51,173 fail2ban.actions.action: INFO   Set actionBan = iptables -I fail2ban-<name> 1 -s <ip> -j DROP
2011-02-22 17:22:51,173 fail2ban.actions.action: INFO   Set actionStop = iptables -D INPUT -p <protocol> -m multiport --dports <port> -j fail2ban-<name>
iptables -F fail2ban-<name>
iptables -X fail2ban-<name>
2011-02-22 17:22:51,174 fail2ban.actions.action: INFO   Set actionStart = iptables -N fail2ban-<name>
iptables -A fail2ban-<name> -j RETURN
iptables -I INPUT -p <protocol> -m multiport --dports <port> -j fail2ban-<name>
2011-02-22 17:22:51,174 fail2ban.actions.action: INFO   Set actionUnban = iptables -D fail2ban-<name> -s <ip> -j DROP
2011-02-22 17:22:51,175 fail2ban.actions.action: INFO   Set actionCheck = iptables -n -L INPUT | grep -q fail2ban-<name>
2011-02-22 17:22:51,177 fail2ban.jail   : INFO   Using poller
2011-02-22 17:22:51,177 fail2ban.filter : INFO   Created Filter
2011-02-22 17:22:51,177 fail2ban.filter : INFO   Created FilterPoll
2011-02-22 17:22:51,178 fail2ban.filter : INFO   Added logfile = /var/log/auth.log
2011-02-22 17:22:51,178 fail2ban.filter : INFO   Set maxRetry = 2
2011-02-22 17:22:51,180 fail2ban.filter : INFO   Set findtime = 600
2011-02-22 17:22:51,180 fail2ban.actions: INFO   Set banTime = 3600
2011-02-22 17:22:51,184 fail2ban.actions.action: INFO   Set actionBan = iptables -I fail2ban-<name> 1 -s <ip> -j DROP
2011-02-22 17:22:51,184 fail2ban.actions.action: INFO   Set actionStop = iptables -D INPUT -p <protocol> -m multiport --dports <port> -j fail2ban-<name>
iptables -F fail2ban-<name>
iptables -X fail2ban-<name>
2011-02-22 17:22:51,185 fail2ban.actions.action: INFO   Set actionStart = iptables -N fail2ban-<name>
iptables -A fail2ban-<name> -j RETURN
iptables -I INPUT -p <protocol> -m multiport --dports <port> -j fail2ban-<name>
2011-02-22 17:22:51,186 fail2ban.actions.action: INFO   Set actionUnban = iptables -D fail2ban-<name> -s <ip> -j DROP
2011-02-22 17:22:51,186 fail2ban.actions.action: INFO   Set actionCheck = iptables -n -L INPUT | grep -q fail2ban-<name>
2011-02-22 17:22:51,187 fail2ban.jail   : INFO   Using poller
2011-02-22 17:22:51,188 fail2ban.filter : INFO   Created Filter
2011-02-22 17:22:51,188 fail2ban.filter : INFO   Created FilterPoll
2011-02-22 17:22:51,188 fail2ban.filter : INFO   Added logfile = /var/log/mail.info
2011-02-22 17:22:51,189 fail2ban.filter : INFO   Set maxRetry = 3
2011-02-22 17:22:51,190 fail2ban.filter : INFO   Set findtime = 600
2011-02-22 17:22:51,191 fail2ban.actions: INFO   Set banTime = 3600
2011-02-22 17:22:51,193 fail2ban.actions.action: INFO   Set actionBan = iptables -I fail2ban-<name> 1 -s <ip> -j DROP
2011-02-22 17:22:51,193 fail2ban.actions.action: INFO   Set actionStop = iptables -D INPUT -p <protocol> -m multiport --dports <port> -j fail2ban-<name>
iptables -F fail2ban-<name>
iptables -X fail2ban-<name>
2011-02-22 17:22:51,194 fail2ban.actions.action: INFO   Set actionStart = iptables -N fail2ban-<name>
iptables -A fail2ban-<name> -j RETURN
iptables -I INPUT -p <protocol> -m multiport --dports <port> -j fail2ban-<name>
2011-02-22 17:22:51,194 fail2ban.actions.action: INFO   Set actionUnban = iptables -D fail2ban-<name> -s <ip> -j DROP
2011-02-22 17:22:51,195 fail2ban.actions.action: INFO   Set actionCheck = iptables -n -L INPUT | grep -q fail2ban-<name>
2011-02-22 17:22:51,350 fail2ban.actions.action: ERROR  iptables -N fail2ban-apache-noscript
iptables -A fail2ban-apache-noscript -j RETURN
iptables -I INPUT -p tcp -m multiport --dports http,https -j fail2ban-apache-noscript returned 400
Ich habe momentan 3 Jails definiert (ssh, mail, apache-noscript) und offensichtlich werden alle 3 Filter problemlos angesprochen und dann knallt es in der letzten Zeile. Es scheint beim Eintragen der Regel nach Auslösen eines apache-noscript Ereignisses zu passieren. Ich hatte vorher aber noch keine Auslöser für den mail bzw. ssh Filter, so dass ich nicht bestätigen kann, dass bei denen korrekt Regeln eingetragen wurden (aktuell habe ich nur Angriffsversuche über den Apache).
Ist das ein Problem der Rechte? Kann jemand mit der Meldung etwas anfangen? Ich hab mir schon nen Wolf gegoogelt, aber langsam gehen mir die Ideen aus.

Danke für jede Unterstützung,

Thomas
 
Hmm...hat sich möglicherweise erledigt. Ich hatte die Apache Überwachung als letzte hinzugefügt und danach ein "fail2ban stop", gefolgt von einem "fail2ban start" ausgeführt. Daraus resultierten obige Logeinträge. Eben ist mir aufgefallen, das (nach einem iptables -nvL) "oben", also vor meinen eigenen iptables Regeln, lediglich die Filter für ssh und mail eingetragen waren. Da meine eigenen Regeln mit einem Drop enden, wurde die Chain für apache-noscript gar nicht mehr erreicht.
Darauf habe ich ein "fail2ban restart" (statt start/stop) ausgeführt - und siehe da. Diesmal stimmte die Reihenfolge und die fail2ban Logeinträge sind (bislang) unauffällig.
Jetzt brauche ich nur noch irgend eine Kanalratte aus China, die meinen Apache mal wieder angreift. Aber jetzt, wo alles weitgehend abgesichert ist, hat das Rauschen in den Logs auch auf normale Weise abgenommen. Warum auch immer, vielleicht nur, weil ich nicht mehr die Plesk Default Page als Startseite habe, die ja irgendwie impliziert: "Hier ist alles neu und vielleicht noch nicht vermint".

Jetzt bleiben dennoch ein paar Fragen:

1) Ich mußte, wie oben ausgeführt, alle Failregex überarbeiten (bzw. eigentlich neu erstellen, denn sie passten gar nicht). Ist das normal, oder habe ich vielleicht ein falsches Paket runtergeladen? Gibt es fertige Ubuntu Failregexe? Ich frage deshalb, weil ich meine anhand realer Logeinträge mühsam erstellt habe - und jetzt natürlich nicht weiß, ob ich jeden theoretisch vorkommenden Eintrag einmal hatte (wohl eher nö, denn im auth.log hatte ich nur 3 Varianten).

2) Falls es wirklich nur einen Standard an Failregex gibt (die, die dann wahrscheinlich nie passen). Wäre es nicht für alle eine enorme Hilfe, wenn es in einem Forum wie dem diesen einen per Sticky oben angenagelten Thread gäbe, mit gängige Regexen für die verschiedensten Distributionen?
Damit würden nicht nur Menschenjahre eingespart, es hat auch einen wesentlicheren Grund. Wenn mein Wissen (Regex php/perl) in etwa auf Python Regex übertragbar ist, dann gibt es "schnelle" und "langsame" Ausdrücke (die, welche ganze Zeilen matchen sind dramatisch schneller als die, welche Teilstrings matchen). Man könnte auf diese Weise - mit geballtem Wissen - optimale Failregex entwickeln, zum Nutzen aller. Nur als Vorschlag - mag ja auch sein, daß das sonst niemanden interessiert.

Glückauf,

Thomas
 
Hi Thomas,

die Filter sind eigentlich so angelegt, das Sie überall matchen.
Es kann allerdings passieren, das wenn die Zeit falsch geht oder du eine andere Sprache eingestellt hast, das die Filter dann nicht greifen.

Für Ubuntu gibts hier die Packete:
http://packages.ubuntu.com/search?keywords=fail2ban

Meine angepassten Filter, kannst du dir unter folgendem Link laden und mal testen:
http://www.blocklist.de/downloads/fail2ban.config.tar.gz

Mit den Filter vom Wiki bist du nicht weiterkommen?
http://www.fail2ban.org/wiki/index.php/MANUAL_0_8#Filters

mfg Martin
 
Hallo Martin,

Locale- und Zeiteinstellungen stimmten, und auch meine selbst erstellten Filterregeln haben funktioniert. Ich hatte sie ja vorher „manuell“ getestet. Es gibt momentan auch keine Auffälligkeiten mehr im fail2ban.log – allerdings auch keine Einträge, die auf einen Ban hinweisen. Es hat heute Nacht um 5:31 Uhr auch nur einen lustlosen Versuch gegeben, webdav auf meinem default Host zu finden. Entgegen lieb gewonnener Gewohnheit auch tatsächlich nur 1x, und meine Regel springt erst bei Wiederholung an. Ich kann es selbst leider nicht testen, da ich eine statische IP habe (die ich vom Blocking ausgeschlossen habe, um mich nicht selbst auszusperren). Also einfach ein bisschen warten, irgend ein Depp wird schon noch kommen.

Ich habe gestern Abend nochmals die start/stop vs. restart Problematik untersucht. Ändere ich die Konfiguration und nutze danach stop/start, so tauchen die neuen Regeln nicht immer VOR meinen eigenen auf. Mit restart hingegen immer. Mag aber gerade nicht extra Python lernen, um den Grund dafür herauszufinden :-)
In allen besuchten Tutorials zu fail2ban wird iptables grundsätzlich nur unparametriert genutzt (3 Chains, alle auf Allow-all), was mir überhaupt nicht gefällt, da dann auch Pakete mit falschem SYN
und INVALID Pakets das gesamte Regelwerk durchlaufen müssen und meinen Server unnötig ausbremsen. Dafür hatte ich etwas weiter unten einen eigenen Thread eröffnet (Schlanke iptables Basis), der leider unbeantwortet blieb.

1000 Dank für Deine Filtersammlung. Werde ich mir heute Vormittag mal angucken. Im Wiki hatte ich sicherlich brauchbare Ansätze gefunden – ich habe aber neben dem Wiki zig andere Tutorials besucht, so dass ich heute nicht mehr sicher sagen kann, mit welchem externen Input ich meine eigenen Filterregeln ertüchtigt habe.

Ich hatte folgendes Paket installiert: „fail2ban_0.8.2-2ubuntu0.1_all.deb“, und die darin enthaltenen Filter passten wirklich überhaupt nicht zu meinen Logs.

Aktuell fehlt mir, abgesehen von einer Bestätigung der Funktion, nur noch eine Lösung für das (für mein System) falsche Datums-/Zeitformat des fail2ban.log an sich.

Fail2ban Log:
Code: 
2011-02-22 19:59:07,357 fail2ban.actions.action: INFO.....

Alle anderen Logs:
Code: 
Feb 23 09:20:01 www CRON[10190]: .....

Kann man das Logformat in fail2ban irgendwo einstellen, um es mit den anderen zu harmonisieren? Könnte z.B. erforderlich werden, wenn man auch das fail2ban Log selbst überwachen möchte, um hartnäckige und zyklisch wiederkehrende Störer länger zu bannen.

Beste Grüße,

Thomas
 
Cool, es klappt. Eine Freundin hat einen Scheinangriff gestartet – und wurde gebannt. Sie spricht jetzt kein Wort mehr mit mir :-)

Im Log entdeckte ich dann noch folgendes:
Code: 
[Wed Feb 23 10:41:16 2011] [error] [client 62.141.45.70] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:
Ein typischer Vulnarability Scan. Das Dumme an diesen Ereignissen ist, dass die immer nur einmalig auftreten (danach weiß man i.d.R. mehr über offene Tore). Wie geht Ihr damit um? Beim ersten mal blocken auf allen Ports und dies langfristig? Oder darauf warten, dass diese Leute als nächstes über Apache, ssh oder mail anklopfen, um dann erst gebannt zu werden? Der Failregex ist kein Problem, die Frage ist nur, ob sich ein Blocken lohnt.
 
Den Kram kannst ignorieren. Was meinst du wieviele solcher Scans laufen, die nicht so einfach zu identifizieren sind. ;)
Sowas zu blocken lohnt sich nicht. Am Ende hast nur massenweise IPTables Regeln drin, welche das System bei Angriffen erstrecht lahm legen, weil die Ressourcen für die Verarbeitung der Regelsätze drauf geht, anstatt den eigentlichen Service damit zu versorgen.
 
You must log in or register to reply here.
Back
Top