fail2ban.log mit fail2ban überwachen für hartnäckige Angreifer

nn man mit fail2ban die eigene Logdatei überwacht kann man besonders hartnäckige Angreifer für einen längeren Zeitraum ausschließen. Dazu wird ein eigener Filter auf die fail2ban.log Datei angelegt. Fail2ban logt hier sämtliche bans und unbans. Wenn also ein Angreifer bspw. bereits mehrere Male wegen fehlgeschlagener SSH Login-Versuche aufgrund des "ssh"-Jails gebannt wurde, kann dieser jetzt mit einer längeren bantime versehen werden.

Beispiel aus der fail2ban.log für einen geduldigen Angreifer, der jedes Mal die bantime des ssh-Jails abwartet:

2016-05-24 04:28:30,113 fail2ban.actions[726]: WARNING [ssh] Ban 218.255.3.67
2016-05-24 04:38:30,867 fail2ban.actions[726]: WARNING [ssh] Unban 218.255.3.67
2016-05-24 04:38:49,899 fail2ban.actions[726]: WARNING [ssh] Ban 218.255.3.67
2016-05-24 04:48:50,681 fail2ban.actions[726]: WARNING [ssh] Unban 218.255.3.67
2016-05-24 04:49:13,715 fail2ban.actions[726]: WARNING [ssh] Ban 218.255.3.67
2016-05-24 04:59:14,497 fail2ban.actions[726]: WARNING [ssh] Unban 218.255.3.67
2016-05-24 04:59:38,533 fail2ban.actions[726]: WARNING [ssh] Ban 218.255.3.67
2016-05-24 05:09:39,313 fail2ban.actions[726]: WARNING [ssh] Unban 218.255.3.67

Der Filter für die fail2ban.log ist somit eigentlich ganz einfach. Taucht eine IP hier mehr als maxretry auf, erfolgt ein Ban mit extra hoher bantime.

Wir legen einen Filter für die fail2ban eigene Logdatei unter /etc/fail2ban/filter.d/fail2ban.conf an:

[Definition]
failregex = fail2ban.actions\[(.*)\]?: WARNING \[(.*)\] Unban <HOST>
ignoreregex = fail2ban.actions\[(.*)\]?: WARNING \[fail2ban\] Unban <HOST>

Wir aktivieren unser Jail in /etc/fail2ban/jail.local:

[fail2ban]
enabled = true
action   = iptables-allports[name=fail2ban]
filter = fail2ban
logpath = /var/log/fail2ban.log
findtime = 86400
bantime = 86400

Dieser Filter ist deutlich rabiater als die Standardwerte von fail2ban und blockt alle Ports für einen ganzen Tag.

Je nach fail2ban Version kann es vorkommen, dass der Unban des zuerst auslaufenden ssh-Jails auch den fail2ban-Jail aufhebt. Ich konnte dies mit fail2ban unter Debian Jessie zwar nicht nachvollziehen, ein Workaround hierzu wäre aber beim fail2ban eigenen Jail auf die Unbans statt Bans zu monitoren, somit ist der fail2ban-Jail niemals parallel zu anderen Jails aktiv, sondern erst direkt nach deren Aufhebung.