Bruteforce-Attacke trotz Fail2Ban

Dieses Thema im Forum "Server Administration" wurde erstellt von fraser, 13. Jan. 2011.

  1. fraser

    fraser New Member

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

    Till Administrator

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

    fraser New Member

    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: 14. Jan. 2011
  4. hopkins

    hopkins New Member

    Habe auch ein ähnliches Problem:

    Installiert ist Debian Squeeze mit ISPConfig 3

    Bei mir war allerdings folgende Meldung im Fail2ban:

    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:

    Server war gott sei dank nicht down, wie in der Vergangenheit schon mal.
     
    Zuletzt bearbeitet: 16. Juni 2011
  5. Till

    Till Administrator

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

    hopkins New Member

    Ich denke fail2ban blockt nur per iptables ?!

    Hatte eher vermutet das der regex falsch ist ?!

    Hab jetzt mal den von oben eingesetzt ....
     
  7. Till

    Till Administrator

    Nein, Fail2ban bietet verschiedene Aktionen zum blockieren des Zugriffs.

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

    hopkins New Member

    Ok.

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

    Habe den hier ausm fail2ban.wiki

    Der von oben ist ja der hier:

    *confused*
     
    Zuletzt bearbeitet: 17. Juni 2011
  9. Till

    Till Administrator

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

    hopkins New Member

    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?
     
  11. Till

    Till Administrator

    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.
     

Diese Seite empfehlen