ipv6 ist nett. Aber der User bekommt halt jedes mal idR ein /64 Subnet. Für so Tools wie fail2ban, die einzelne IPs blocken, wenn irgendetwas komisches auftaucht irgendwie schlecht. Der Angreifer schnappt sich halt irgendeine neue IP, denn die unteren 64bit stehen ja voll zu seiner Verfügung.
Jetzt verhält es sich mit dem originalen fail2ban so, dass das nicht mal ipv6 kann. Zeit sich auf die Suche zu machen. In einem github-Repo bin ich fündig geworden. Der gute Mensch hat fail2ban so erweitert, dass es v6-fähig wird. Also flugs mal installiert, um direkt die Ernüchterung zu spüren: Es blockt mit /128 🙁
Also erweitern:
Die /etc/fail2ban/action.d/iptables-46-multiport-log.conf passen wir wie hier in diesem gist sichtbar an. Hinzugekommen ist lediglich <mask> bei der ban und unban-Regel sowie unter init. Das bedeutet, dass – sofern nicht anders angegeben – immer eine /32er CIDR-Mask gelegt wird, also die gesamte v4-IP (bei v6 halt ebenfalls /32 – aber dazu später mehr) geblockt wird.
Da die fail2ban-Variante von “usrweiss” im Wrapperscript nicht so granular zwischen v4 und v6 differenzieren kann, als dass wir da andere cidr-Masken drauflegen könnten, legen wir einfach in der /etc/fail2ban/jail.conf ZWEI Jails an:
[web_v4]
enabled = true
filter = web_v4
action = ip64tables-multiport-log[name=web_v4, protocol="tcp", port="80,443", mask=32]
logpath = /var/log/apache2/web_f2b/fails.log
maxretry= 5
bantime = 60
findtime= 60
[web_v6]
enabled = true
filter = web_v6
action = ip64tables-multiport-log[name=web_v6, protocol="tcp", port="80,443", mask=64]
logpath = /var/log/apache2/web_f2b/fails.log
maxretry= 5
bantime = 60
findtime= 60
Die benötigen wiederrum auch 2 Configs in der /etc/fail2ban/filter.d:
/etc/fail2ban/filter.d/web_v4.conf:
# Fail2Ban configuration file
#
#
# $Revision: 250 $
#
[INCLUDES]
[Definition]
failregex = Applikation: v4 (<HOST>) Detaillierte Fehlermeldung .*
/etc/fail2ban/filter.d/web_v6.conf:
# Fail2Ban configuration file
#
#
# $Revision: 250 $
#
[INCLUDES]
[Definition]
failregex = Applikation: v6 (<HOST>) Detaillierte Fehlermeldung .*
Der Haken ist, dass unsere Applikation, die die Events auslöst (hier eine Loginseite, die die Fehlversuche nach /var/log/apache2/web_f2b/fail.log wegschreibt) an die Zeile dranschreiben muss, ob es sich um v4 oder v6 handelt. Bezogen auf die o.g. Configs sieht das in dem fail.log der App so aus (Von der Applikation generierte Einträge. Erster: v6, zweiter v4)
[May 31 10:08:12] Applikation: v6 (2a03:2880:2130:cf05:face:b00c:0:1) fehlerhafter Loginversuch blabla
[May 31 10:09:12] Applikation: v4 (173.252.120.6) fehlerhafter Loginversuch blabla
Von nun an blockt fail2ban die Ports 80 und 443 sobald in der Logdatei der Applikation (/var/log/apache2/web_f2b/fail.log) 5 mal innerhalb von 60 Sekunden die selbe IP mit einem Fehler aufschlägt für 60 Sekunden. Und zwar bei einer v4 halt die v4, bei einer v6 das /64er Subnet der v6. Die gerade greifende Netzmaske wird in der/etc/fail2ban/jail.conf als Variable “mask” in der action mit angegeben – sollte dort nichts stehen, gilt der Defaultwert von /32 aus der iptables-46-multiport-log.conf
Wie üblich, geht das sicherlich noch eleganter. Bin gespannt, wann fail2ban endlich eine v6-Variante releast.
