Bruteforce-Attacke trotz Fail2Ban

[fraser]

Leider habe ich heute auf meinem Server unschöne Log-Einträge gefunden.
Diese sehen folgendermaßen aus:

Jan 12 15:32:16 MYSERVER dovecot: pop3-login: Aborted login (1 authentication attempts): user=<admin>, method=PLAIN, rip=83.235.19.12, lip=MYIP
Jan 12 15:32:16 MYSERVER dovecot: pop3-login: Aborted login (1 authentication attempts): user=<root>, method=PLAIN, rip=83.235.19.12, lip=MYIP
Jan 12 15:32:20 MYSERVER last message repeated 2 times
Jan 12 15:32:20 MYSERVER dovecot: pop3-login: Aborted login (1 authentication attempts): user=<admin>, method=PLAIN, rip=83.235.19.12, lip=MYIP
Jan 12 15:32:22 MYSERVER dovecot: pop3-login: Aborted login (1 authentication attempts): user=<root>, method=PLAIN, rip=83.235.19.12, lip=MYIP
Jan 12 15:32:26 MYSERVER last message repeated 2 times
Jan 12 15:32:26 MYSERVER dovecot: pop3-login: Aborted login (1 authentication attempts): user=<webmaster>, method=PLAIN, rip=83.235.19.12, lip=MYIP
Jan 12 15:32:28 MYSERVER dovecot: pop3-login: Aborted login (1 authentication attempts): user=<admin>, method=PLAIN, rip=83.235.19.12, lip=MYIP

Das setzt sich dann noch 6700 mal so fort.
In Fail2Ban ist folgende Regel erstellt:

[dovecot-pop3imap]
enabled = true
filter = dovecot-pop3imap
action = iptables-multiport[name=dovecot-pop3imap, port="pop3,imap", protocol=tcp]
logpath = /var/log/mail.log
maxretry = 2
findtime = 1200
bantime = 7200

So wie ich es verstehe, sollte doch jemand, der innerhalb von 20 Minuten (findtime) 3 mal das falsche Passwort eingibt (maxretry) , für 2 Stunden (bantime) geblockt werden.
Nun hat der gute Mann ja die Benutzernamen ständig gewechselt, aber, wie man auch im Log-Auszug sieht, innerhalb von ca. 20 Sekunden dreimal versucht, sich mit dem user "admin" anzumelden.
Warum wurde er denn nicht geblockt? Stimmt was an meiner Regel nicht?
Fail2Ban läuft, hat aber für den gesamten Zeitraum des Angriffs nichts protokolliert.

Danke für Eure Antworten.
Gruß
fraser

[Till]

Dann stimmt vermutlich etwas mit dem regulären ausdruck des Filters nicht.

[fraser]

Du hattest Recht. Ich hatte Fail2Ban falsch konfiguriert, da ich vergessen hatte, dass die Logins ja über die MySQL-Datenbank von ISPConfig erfolgen und auch dort geloggt werden. Jetzt klappt es jedenfalls.
In die /etc/fail2ban/filter.d/dovecot-pop3imap.conf gehört nämlich folgendes:

[Definition]
failregex = dovecot.*auth-worker\(default\): sql\(.*,<HOST>\): Password mismatch

Der Eintrag in /etc/fail2ban/jail.conf:

[dovecot-pop3imap]
enabled = true
filter = dovecot-pop3imap
action = iptables-multiport[name=dovecot-pop3imap, port="pop3,pop3s,imap,imaps", protocol=tcp]
logpath = /var/log/mail.log
maxretry = 2
findtime = 1200
bantime = 7200

Die Datei /etc/dovecot/dovecot.conf habe ich um folgende Zeilen ergänzt:

log_path = 
auth_verbose = yes

Wobei ich nicht genau weiß, ob Letzteres nötig ist. Aber egal, jetzt funktioniert es jedenfalls.

[hopkins]

Habe auch ein ähnliches Problem:

Installiert ist Debian Squeeze mit ISPConfig 3

Bei mir war allerdings folgende Meldung im Fail2ban:

2011-06-15 16:37:17,222 fail2ban.actions: WARNING [dovecot-pop3imap] Ban 74.63.243.159
2011-06-15 16:37:17,413 fail2ban.actions: WARNING [dovecot-pop3imap] 74.63.243.159 already banned
2011-06-15 16:37:18,412 fail2ban.actions: WARNING [dovecot-pop3imap] 74.63.243.159 already banned
2011-06-15 16:37:19,412 fail2ban.actions: WARNING [dovecot-pop3imap] 74.63.243.159 already banned
2011-06-15 16:37:20,412 fail2ban.actions: WARNING [dovecot-pop3imap] 74.63.243.159 already banned
2011-06-15 16:37:21,412 fail2ban.actions: WARNING [dovecot-pop3imap] 74.63.243.159 already banned
2011-06-15 20:04:08,246 fail2ban.actions: WARNING [ssh] Unban 85.214.45.44

Beim auslesen von iptables mittels IPTABLES -L war auch diese IP nicht zu finden.

Wodran kann das liegen?

Darauf aufmerksam geworden bin ich erst wegen solchen Meldungen:

Jun 15 16:41:03 euve21814 dovecot: pop3-login: socket(default) failed: Cannot allocate memory
Jun 15 16:41:03 euve21814 dovecot: pop3-login: Can't connect to auth server at default: Cannot allocate memory

Server war gott sei dank nicht down, wie in der Vergangenheit schon mal.

[Till]

Möglicherweise wurde über route bzw. hosts.deny gebannt und nicht iptables.

[hopkins]

Ich denke fail2ban blockt nur per iptables ?!

Hatte eher vermutet das der regex falsch ist ?!

Hab jetzt mal den von oben eingesetzt ....

[Till]

Ich denke fail2ban blockt nur per iptables ?!

Nein, Fail2ban bietet verschiedene Aktionen zum blockieren des Zugriffs.

Hatte eher vermutet das der regex falsch ist ?!

Dann hätte aber Fail2ban die Ban/Unban Aktionen nicht im Log vermerkt.

[hopkins]

Ok.

Welcher dieser Regex - Einträge ist denn jetzt der richtige?

Habe den hier ausm fail2ban.wiki

[Definition] failregex = (?: pop3-login|imap-login): .*(?:Authentication failure|Aborted login \(auth failed|Aborted login \(tried to use disabled|Disconnected \(auth failed).*rip=(?P<host>\S*),.* ignoreregex =

Der von oben ist ja der hier:

failregex = dovecot.*auth-worker\(default\): sql\(.*,<HOST>\): Password mismatch

*confused*

[Till]

Den den Du erst hattest, hat funktioniert laut Logfile. Du solltest ihn also nicht ändern. Es kann auch sein dass beide funktionieren, denn ein Regex kann uaf viele Arten definiert werden. Kannst es ja testen bzw. den Regex mit den Zeilen im Log vergleichen.

[hopkins]

Jo kk thx

Noch ne Frage:

Wie kann es denn sein, dass obwohl "derjenige" gebanned war, trotzdem den server "flooden" konnte? scheint zumindest so.
Denn "cannot allocate memory" sagt ja alles.

War da fail2ban einfach zu langsam? Denn die Einträge aus der Log sind ja im 100'stel-Bereich ..

Oder war die Anfrage direkt so krass, dass er den Ram gesprengt hat?

Und wie kann ich sowas verhindern?