# Bruteforce-Attacke trotz Fail2Ban



## fraser (13. Jan. 2011)

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 (13. Jan. 2011)

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


----------



## fraser (14. Jan. 2011)

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 (16. Juni 2011)

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
> ...


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 (16. Juni 2011)

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


----------



## hopkins (16. Juni 2011)

Ich denke fail2ban blockt nur per iptables ?!

Hatte eher vermutet das der regex falsch ist ?! 

Hab jetzt mal den von oben eingesetzt ....


----------



## Till (17. Juni 2011)

> 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 (17. Juni 2011)

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 (17. Juni 2011)

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 (17. Juni 2011)

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 (17. Juni 2011)

> 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.


----------

