fail2ban Angriff auf Mailport nicht erkannt

[serecords]

Hallo

Mein System: Debian Squeeze

Ich habe von logcheck eine E-Mail bekommen, dass meine Mail Log verdächtige Einträge enthält.
Gut, habe ich nachgesehen, dachte mir aber, naja fail2ban wird schon eingegriffen haben wenn wirklich was war, aber genau das hat es nicht gemacht...

Hier mal ein Auszug aus der mail.log

Code: Alles auswählen

May 19 20:57:30 debian pop3d: LOGIN FAILED, user=ivory, ip=[::ffff:87.101.***.***]
May 19 20:57:31 debian pop3d: LOGOUT, ip=[::ffff:87.101.***.***]
May 19 20:57:31 debian pop3d: Disconnected, ip=[::ffff:87.101.***.***]
May 19 20:57:31 debian pop3d: Connection, ip=[::ffff:87.101.***.***]
May 19 20:57:31 debian pop3d: LOGIN FAILED, user=jack, ip=[::ffff:87.101.***.***]
May 19 20:57:35 debian pop3d: LOGOUT, ip=[::ffff:87.101.***.***]
May 19 20:57:35 debian pop3d: Disconnected, ip=[::ffff:87.101.***.***]
May 19 20:57:36 debian pop3d: LOGOUT, ip=[::ffff:87.101.***.***]
May 19 20:57:36 debian pop3d: Disconnected, ip=[::ffff:87.101.***.***]
May 19 20:57:37 debian pop3d: Connection, ip=[::ffff:87.101.***.***]
May 19 20:57:37 debian pop3d: LOGIN FAILED, user=jack, ip=[::ffff:87.101.***.***]
May 19 20:57:39 debian pop3d: Connection, ip=[::ffff:87.101.***.***]
May 19 20:57:39 debian pop3d: LOGIN FAILED, user=ivory, ip=[::ffff:87.101.***.***]
May 19 20:57:42 debian pop3d: LOGOUT, ip=[::ffff:87.101.***.***]
May 19 20:57:42 debian pop3d: Disconnected, ip=[::ffff:87.101.***.***]
May 19 20:57:43 debian pop3d: Connection, ip=[::ffff:87.101.***.***]
May 19 20:57:43 debian pop3d: LOGIN FAILED, user=jack, ip=[::ffff:87.101.***.***]
May 19 20:57:44 debian pop3d: LOGOUT, ip=[::ffff:87.101.***.***]
May 19 20:57:44 debian pop3d: Disconnected, ip=[::ffff:87.101.***.***]
May 19 20:57:44 debian pop3d: Connection, ip=[::ffff:87.101.***.***]
May 19 20:57:45 debian pop3d: LOGIN FAILED, user=ivory, ip=[::ffff:87.101.***.***]
May 19 20:57:48 debian pop3d: LOGOUT, ip=[::ffff:87.101.***.***]
May 19 20:57:48 debian pop3d: Disconnected, ip=[::ffff:87.101.***.***]
May 19 20:57:49 debian pop3d: Connection, ip=[::ffff:87.101.***.***]
May 19 20:57:49 debian pop3d: LOGIN FAILED, user=jack, ip=[::ffff:87.101.***.***]
May 19 20:57:50 debian pop3d: LOGOUT, ip=[::ffff:87.101.***.***]
May 19 20:57:50 debian pop3d: Disconnected, ip=[::ffff:87.101.***.***]
May 19 20:57:50 debian pop3d: Connection, ip=[::ffff:87.101.***.***]
May 19 20:57:51 debian pop3d: LOGIN FAILED, user=ivory, ip=[::ffff:87.101.***.***]
May 19 20:57:54 debian pop3d: LOGOUT, ip=[::ffff:87.101.***.***]
May 19 20:57:54 debian pop3d: Disconnected, ip=[::ffff:87.101.***.***]

usw...

Das hätte ja eigentlich reichen sollen, das fail2ban eingreift, hat es aber nicht.
Das fail2ban.log ist leer.
Warum?
Hier mal meine jail.local
37166

Es steht ja alles auf true, könnt ihr mir bitte helfen?
Denn das wird nicht das letzte mal gewesen sein.

[unitra]

Den Filter für mail kann man mit fail2ban-regex prüfen. Für SSH wäre es z.B.

Code: Alles auswählen

fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf

Das funktioniert genauso für Mailfilter und andere Filter die man benutzt.

Die auth.log und sshd.conf gegen die eigenen Dateien ersetzten, dann sieht ma was der Filter erkennt und was er nicht erkennt.
Hier kann man noch ein Wenig mehr Beispiele zum Troubleshooting durchlesen.
http://wiki.gentoo.org/wiki/Fail2ban.

mfg
unitra

[serecords]

Oke, ja also die courierlogin.conf erkennt auf jeden Fall die Angriffe in der mail.log.

Hier mal ein kleiner Auszug aus der Rückgabe von

Code: Alles auswählen

fail2ban-regex /var/log/mail.log /etc/fail2ban/filter.d/courierlogin.conf

Code: Alles auswählen

/usr/share/fail2ban/server/filter.py:442: DeprecationWarning: the md5 module is deprecated; use hashlib instead
  import md5

Running tests
=============

Use regex file : /etc/fail2ban/filter.d/courierlogin.conf
Use log file   : /var/log/mail.log

    87.101.***.*** (Sun May 19 21:02:46 2013)
    87.101.***.*** (Sun May 19 21:02:51 2013)
    87.101.***.*** (Sun May 19 21:02:55 2013)
    87.101.***.*** (Sun May 19 21:02:55 2013)

Date template hits:
101562 hit(s): MONTH Day Hour:Minute:Second
0 hit(s): WEEKDAY MONTH Day Hour:Minute:Second Year
0 hit(s): WEEKDAY MONTH Day Hour:Minute:Second
0 hit(s): Year/Month/Day Hour:Minute:Second
0 hit(s): Day/Month/Year Hour:Minute:Second
0 hit(s): Day/Month/Year Hour:Minute:Second
0 hit(s): Day/MONTH/Year:Hour:Minute:Second
0 hit(s): Month/Day/Year:Hour:Minute:Second
0 hit(s): Year-Month-Day Hour:Minute:Second
0 hit(s): Day-MONTH-Year Hour:Minute:Second[.Millisecond]
0 hit(s): Day-Month-Year Hour:Minute:Second
0 hit(s): TAI64N
0 hit(s): Epoch
0 hit(s): ISO 8601
0 hit(s): Hour:Minute:Second
0 hit(s): <Month/Day/Year@Hour:Minute:Second>

Success, the total number of match is 18678

However, look at the above section 'Running tests' which could contain important
information.

Nun, da es ja erkannt wird, ist die Frage, warum bannt er nicht?

[unitra]

Naja, es wird erkannt das stimmt. Aber in deiner fail2ban-regex fehlt die Ausgabe der "Results" wo failregex ausgeführt wird und "Summary", die aufzeigt wann/welche Hosts gebannt wurden.
Schaue das Beispiel noch einmal an http://wiki.gentoo.org/wiki/Fail2ban#Troubleshooting, und zwar Results und Summary, die in deiner Ausgabe nicht vorhanden sind.
Für mich sieht es so aus als ob der mailfilter (courierlogin.conf) auf der Machine keine Regeln hätte.

[serecords]

Naja die sind bestimmt da, aber wie du sieht sind es dort tausende Ergebnisse und da kann ich die nicht raus kopieren, soweit reicht der Speicher der Konsole nicht

Wird das auch in irgendeinem Log gespeichert?

[unitra]

Code: Alles auswählen

fail2ban-regex /var/log/mail.log /etc/fail2ban/filter.d/courierlogin.conf > /tmp/output

Um eine Riesendatei in den Puffer zu kopieren nimmt man dann xclip. http://packages.debian.org/sid/xclip

[serecords]

Gut

Also so sieht es aus:

Code: Alles auswählen

Running tests
=============

Use regex file : /etc/fail2ban/filter.d/courierlogin.conf
Use log file   : /var/log/mail.log


Results
=======

Failregex
|- Regular expressions:
|  [1] LOGIN FAILED, .*, ip=\[<HOST>\]$
|
`- Number of matches:
   [1] 18678 match(es)

Ignoreregex
|- Regular expressions:
|
`- Number of matches:

Summary
=======

Addresses found:
[1]
    87.101.***.*** (Sun May 19 09:47:40 2013)
    87.101.***.*** (Sun May 19 09:47:46 2013)

Date template hits:
101713 hit(s): MONTH Day Hour:Minute:Second
0 hit(s): WEEKDAY MONTH Day Hour:Minute:Second Year
0 hit(s): WEEKDAY MONTH Day Hour:Minute:Second
0 hit(s): Year/Month/Day Hour:Minute:Second
0 hit(s): Day/Month/Year Hour:Minute:Second
0 hit(s): Day/Month/Year Hour:Minute:Second
0 hit(s): Day/MONTH/Year:Hour:Minute:Second
0 hit(s): Month/Day/Year:Hour:Minute:Second
0 hit(s): Year-Month-Day Hour:Minute:Second
0 hit(s): Day-MONTH-Year Hour:Minute:Second[.Millisecond]
0 hit(s): Day-Month-Year Hour:Minute:Second
0 hit(s): TAI64N
0 hit(s): Epoch
0 hit(s): ISO 8601
0 hit(s): Hour:Minute:Second
0 hit(s): <Month/Day/Year@Hour:Minute:Second>

Success, the total number of match is 18678

However, look at the above section 'Running tests' which could contain important
information.

[unitra]

Ja der Filter erkennt das wenn du es mit failregex machts, das heisst noch lange nicht dass fail2ban als daemon das kann.
3 Möglichkeiten
1) Fail2ban hat keinen Zugrfiff auf die Datei mail.log zur Laufzeit
2) Fail2ban ist nicht gestartet
3) Fail2ban ist gestartet und hat Zugriff auf die Datei mail.log, aber es it keine Aktion hinterlegt was er machen soll, wenn was "match"t

Die Aktionen was zu tun ist sind im Ordner action.d hinterlegt.

mfg
unitra

[serecords]

1. Der Zugriff ist vorhanden.

2. Es ist gestartet.

3. Theoretisch reicht es doch aber, wenn man in der jail.local die Dinge, die man überwacht haben möchte, auf true stellt. Dann müsste fail2ban ja auch agieren, so hat es bisher auf den Servern, die ich vor diesem hier hatte, auch funktioniert.

[serecords]

Was soll ich denn jetzt machen?

Ich habe weitere Angriffe gehabt und wieder hat fail2ban nicht angeschlagen, könnte mir bitte jemand helfen?

Hier mal noch die Ausgabe von

Code: Alles auswählen

iptables --list

37179