kohlmajer.de

Integration von AbuseIPDB in fail2ban

495 Wörter, Lesezeit: 3 min

Die Integration von AbuseIPDB in fail2ban ist schnell und einfach durchgeführt. AbuseIPDB bietet hierfür auch eine Konfigurationshilfe an:

Die Konfiguration der Jails erfolgt in /etc/fail2ban/jail.local. Dort kann die AbuseIPDB Action mit der passenden Kategorie konfiguriert werden. Der API Key braucht nicht in action_abuseipdb mit eingebaut werden, da er bereits in /etc/fail2ban/action.d/abuseipdb.conf definiert wurde!

[DEFAULT]
bantime  = 1d
bantime.increment = true
bantime.factor = 2
bantime.maxtime = 360d
findtime = 30d
maxretry = 4
banaction = iptables-allports

#
# JAILS
#

[sshd]
enabled = true
port    = 31437
backend = systemd
maxretry = 2
action = %(action_)s
         %(action_abuseipdb)s[abuseipdb_category="18,22"]

[nginx-auth]
enabled = true
filter = nginx-auth
port = http,https
logpath = /var/log/nginx/*.log
backend = auto
action = %(action_)s
         %(action_abuseipdb)s[abuseipdb_category="15,21"]

[nginx-noscript]
enabled = true
port = http,https
filter = nginx-noscript
logpath = /var/log/nginx/*.log
backend = auto
action = %(action_)s
         %(action_abuseipdb)s[abuseipdb_category="15,21"]

[nginx-login]
enabled = true
filter = nginx-login
port = http,https
logpath = /var/log/nginx/*.log
backend = auto
maxretry = 2
action = %(action_)s
         %(action_abuseipdb)s[abuseipdb_category="15,21"]

[nginx-4xx]
enabled = true
port = http,https
filter = nginx-4xx
logpath = /var/log/nginx/*.log 
backend = auto
action = %(action_)s
         %(action_abuseipdb)s[abuseipdb_category="19,21"]

Fail2ban einmal neustarten (sudo fail2ban-client stop && sudo fail2ban-client start) und fertig!

Achtung! Es gibt ein GitHub-Issue für Fail2Ban (#3428), um sensitive Informationen für AbuseIPDB zu maskieren. Ein einfacher Workaround ist in diesem Kommentar. Die Anpassungen in jail.local sind minimal und einfach durchzuführen 😅.

Subnetze blocken

Wie oben in meiner Config zu sehen ist, nutze ich die Standard-Aktion iptables-allports. Diese Aktion ist von iptables abgeleitet, d. h. ich habe /etc/fail2ban/action.d/iptables.conf so angepasst, dass bei IPv4 der CIDR-Range /24 und bei IPv6 der CIDR-Range /96 geblockt wird 😁. Angreifer probieren es oft von mehreren IP-Adressen aus dem gleichen Netz heraus:

# angepasste Zeilen in /etc/fail2ban/action.d/iptables.conf

[Definition]

actionban = <iptables> -I f2b-<name> 1 -s <ip>/<mask> -j <blocktype>
actionunban = <iptables> -D f2b-<name> -s <ip>/<mask> -j <blocktype>

[Init]

# block entire /24 net for IPv4
mask = 24

[Init?family=inet6]

# block entire /96 net for IPv6
mask = 96

Das ganze sieht dann in iptables bzw. ip6tables so aus:

sudo iptables -S | grep f2b.*REJECT | tail
-A f2b-nginx-4xx -s 141.255.162.0/24 -j REJECT --reject-with icmp-port-unreachable
-A f2b-nginx-4xx -s 138.68.183.0/24 -j REJECT --reject-with icmp-port-unreachable
-A f2b-nginx-4xx -s 138.197.16.0/24 -j REJECT --reject-with icmp-port-unreachable
-A f2b-nginx-4xx -s 130.89.144.0/24 -j REJECT --reject-with icmp-port-unreachable
-A f2b-nginx-4xx -s 111.249.66.0/24 -j REJECT --reject-with icmp-port-unreachable
-A f2b-nginx-4xx -s 108.165.153.0/24 -j REJECT --reject-with icmp-port-unreachable
-A f2b-nginx-4xx -s 107.174.224.0/24 -j REJECT --reject-with icmp-port-unreachable
-A f2b-nginx-4xx -s 106.75.33.0/24 -j REJECT --reject-with icmp-port-unreachable
-A f2b-nginx-4xx -s 103.39.93.0/24 -j REJECT --reject-with icmp-port-unreachable
-A f2b-nginx-noscript -s 146.70.194.0/24 -j REJECT --reject-with icmp-port-unreachable

sudo ip6tables -S | grep f2b.*REJECT
-A f2b-nginx-4xx -s 2a0e:97c0:3e3:b6::/96 -j REJECT --reject-with icmp6-port-unreachable

Statistik

AbuseIPDB bietet auch einen nette Statistik 😄. Da ich meinen SSH-Port nicht auf 22 liegt und ich auch Port Knocking verwende, sehe ich zum Glück nicht all zu viele Angriffe auf meine Server 😅.

Tags: