Fail2ban && Logrotate - Frage

[Deleted member 14254]

Hallo Forum,

ich habe folgende Frage:

Seit kürzlich nutze ich fail2ban mit pyinotify-backend, was WESENTLICH schneller reagiert als das Standard-Polling. Gamin funktioniert bei hardened/SELinux-Kerneln nicht, weshalb es (als ebenfalls oft angepriesene zuverlässige Variante) für mich ausfällt :/

Das Poblem ist nur, das wenn die Logs rotieren, fail2ban aufhört zu bannen. (Liegt an Python, schon im Inet recherchiert)

Abhilfe schaffte dies:

In /etc/logrotate.d/fail2ban

# cat fail2ban
/var/log/fail2ban.log {
    daily
    rotate 4
    missingok
    compress
    postrotate
        /usr/bin/fail2ban-client set logtarget /var/log/fail2ban.log 1>/dev/null || true
        /usr/bin/fail2ban-client -x reload > /dev/null
    endscript
}

diese Zeile:

/usr/bin/fail2ban-client -x reload > /dev/null

einzusetzen, um die Konfiguration nach dem Rotieren wieder auf das neue leere File verweisen zu lassen.
Leider ist dies unzuverlässig. Einige Jails funktionieren, einige nicht.
Das ist kein Zustand, auf den man sich verlassen möchte.

Wäre es eine Möglichkeit fail2ban KOMPLETT zu stoppen und wieder zu starten?

Also in etwa so:

/usr/bin/fail2ban-client -x stop > /dev/null
/usr/bin/fail2ban-client start > /dev/null

Hab mir schon Cronjobs als Lösung durch den Kopf gehen lassen, aber der f2b-restart soll(te) ja auch zeitnah in logrotate-Abhängigkeit einhergehen.

Was sagt Ihr dazu? Bin echt ratlos im Moment... Freue mich über jeden Anstoß.

 

[Nebu]

Wie wäre es mit folgender Lösung:

prerotate
  Stoppen des Dienstes
endscript

postrotate
   Starten des Dienstes
endscript

 

[Deleted member 14254]

Soähnlich hatte ich es auch probiert. Das die Konfiguration von f2b nach dem Postrotate reloaded werden soll. Das lief auch, aber unvorhersehbar:

Manchmal kam es dazu das fail2ban teilweise lief:
Er bannte zwar wenn Verdächtiges im access_log -bzw. error_log von apache auftauchte, dafür konnten Flooder im mail.log ihr Unwesen treiben. Dann war mail.log beschützt, aber hunderte Bruteforce-Zeilen auf geschützte Apache-Verzeichnisse.

Ich habe das jetzt mit 2 Scripten für cron gelöst.

Eine f2b-start und eine f2b-stop erstellt. Die in die crontab eingetragen. Nun wird f2b vor dem rotieren gestoppt und dann in Abstand von 1 Min wieder neugestartet.
Ich vermute, das nicht jedesmal nach der selben Reihenfolge von logrotate rotiert wird und es daher dann dazu kam, das Fail2ban wieder reloaded war, noch bevor ALLE Logfiles rotiert waren.
Hoffentlich bringt die nächste f2b Version Abhilfe, denn PyInotify gefällt mir im Gegensatz zu Polling 1000 mal besser. Stellte ich bei Polling auf 10 Fehlversuche ein, liefen mindestens 30 problemlos durch, bevor es zur Sperrung kam (bei Scriptgesteuerten sehr schnellen angriffen) - Jetzt ist wirklich nach der voreingestellten Zahl an maximaler Fehlschläge sofort die IP blockiert. So soll es auch sein.

Danke Dir aber trotzdem, Nebu!