Bruteforce-Attacke trotz Fail2Ban

#1
Leider habe ich heute auf meinem Server unschöne Log-Einträge gefunden.
Diese sehen folgendermaßen aus:
Code:
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:
Code:
[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
 
#3
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:
Code:
[Definition]
failregex = dovecot.*auth-worker\(default\): sql\(.*,<HOST>\): Password mismatch
Der Eintrag in /etc/fail2ban/jail.conf:
Code:
[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:
Code:
log_path = 
auth_verbose = yes
Wobei ich nicht genau weiß, ob Letzteres nötig ist. Aber egal, jetzt funktioniert es jedenfalls.
 
Zuletzt bearbeitet:
#4
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.
 
Zuletzt bearbeitet:
#8
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*
 
Zuletzt bearbeitet:

Till

Administrator
#9
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.
 
#10
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?
 

Till

Administrator
#11
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.
Das mus doch nichts miteinander zu tun haben. Wenn der Server nicht genug memory hat z.B. weil gerade viel traffic auf dem apache läuft dann reicht auch eine einzige zusätzliche Abfrage des dovecot Logins oder eines beliebigen anderen Programmes um eine "Cannot allocate memory" meldung auszulösen.
 

Werbung

Top