Bei der Verwendung von Ubuntu 20.04 LTS habe ich Folgendes in /etc/fail2ban/jail.local:
[DEFAULT]
bantime = 3600
banaction = iptables
blocktype = drop
[sshd]
enabled = true
protocol = tcp
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
Aber das ist, was ich sehe, wenn ich iptables-Regeln aufliste:
╰─# iptables -L f2b-sshd -n -v
Chain f2b-sshd (1 references)
pkts bytes target prot opt in out source destination
13 1356 REJECT all -- * * 222.187.232.205 0.0.0.0/0 reject-with icmp-port-unreachable
18 1516 REJECT all -- * * 221.181.185.153 0.0.0.0/0 reject-with icmp-port-unreachable
17 1064 REJECT all -- * * 222.186.180.130 0.0.0.0/0 777 55854 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
Das Problem besteht darin, dass REJECT (mit ICMP) statt DROP verwendet wird.
Die Datei action.d/iptables.conf enthält Folgendes:
# Option: actionban
# Notes.: command executed when banning an IP. Take care that the
# command is executed with Fail2Ban user rights.
# Tags: See jail.conf(5) man page
# Values: CMD
#
actionban = <iptables> -I f2b-<name> 1 -s <ip> -j <blocktype>
Es handelt sich um die standardmäßige iptables-Aktionsdatei, die mit dem offiziellen fail2ban-apt-Paket für diese Betriebssystemversion geliefert wird.
Habe auch versucht, "blocktype=drop" unter [sshd] hinzuzufügen, aber das hat keinen Effekt.
Ich bin nicht sicher, wie ich das debuggen soll, da der fail2ban-Dienst die eigentlichen iptables-Befehle nicht protokolliert.
Was vermisse ich?
Antwort1
Um der Aktion eines einzelnen Jails einige Parameter bereitzustellen, müssen Sie actionalle Parameter festlegen (die normalerweise auch im Standardabschnitt von angegeben werden jail.conf). Im Fall einer Sperraktion können Sie alternativ so etwas verwenden:
[some_jail]
banaction = %(known/banaction)s[blocktype=DROP]
Was das Thema DROP vs. REJECT betrifft, ist die Diskussion so alt wie das Netzfilter-Subsystem selbst und es gibt viele Vor- und Nachteile für beide Seiten. Bezüglich
der Bedenken hinsichtlich des Verbots siehehttps://github.com/fail2ban/fail2ban/issues/2217#issuecomment-423248516für Details.
Antwort2
Ich habe die Lösung von @sebres akzeptiert, möchte aber einige Fallstricke hinzufügen.
Für die Sperrung von iptables-allports kann der Blocktyp „reject“ Leerzeichen enthalten. Diese müssen Sie in Anführungszeichen setzen.
Beispiel:
[sshd]
banaction=iptables-allports[blocktype="REJECT --reject-with icmp-port-unreachable"]
Zweite interessante Sache: Sowohl die Banaction- als auch die Jail-Konfiguration haben einen Parameter namens „protocol“. Ich war zunächst verwirrt, als die folgende Konfiguration keine Fehler ausgab, aber keine UDP-Anfragen blockierte:
[named-ddos]
banaction=iptables-allports[blocktype=DROP,protocol=all]
Dies ist passiert, weil mir die Einstellung protocol=all im Jail fehlte. Sie müssen protocol=all auf Jail-Ebene angeben:
[named-ddos]
banaction=iptables-allports[blocktype=DROP,protocol=all]
protocol=all
Der Grund dafür ist, dass der Abschnitt named-ddos eine neue Kette in iptables erstellt und die gesperrten IPs Regeln innerhalb dieser Kette erstellen. Wenn Sie auf Jail-Ebene nicht protocol=all angeben, wird die Kette wie folgt definiert:
Chain INPUT (policy DROP 22 packets, 952 bytes)
pkts bytes target prot opt in out source destination
1371 229K named-ddos tcp -- * * 0.0.0.0/0 0.0.0.0/0
Es stimmt, dass die Verbotsaktion Regeln mit proto=all erstellen wird.innerhalb der Kette, aber die Kette selbst wird nicht für Nicht-TCP-Pakete verwendet. Die Schlussfolgerung ist, dass Sie sowohl auf Jail-Ebene als auch in der Sperraktion (sofern unterstützt) protocol=all angeben müssen, sonst funktioniert es nicht.