Re: libssh-Bruteforcer in IPTABLES Chain bannen
On Wed, 30 Mar 2005, Bruno Hertz wrote:
> Stefan Muthers <grau@tastensuppe.de> writes:
> Stimmt, sorry. Auf Sarge:
>
> $ dpkg -l iptables
> ii iptables 1.2.11-8 Linux kernel 2.4+ iptables administration
Ich rudere auch zurück! Funktioniert in der Tat. Die Regeln mußte ich für
die shorewall ein wenig anpassen, da die "/etc/shorewall/start" erst nach
dem Start der Shorewall ausgeführt wird und ein APPEND damit unwirksam wäre,
aber ansonsten funktioniert die Sache wie gewünscht, wie der Test zeigt:
extfw:~ # nmap -p 22 -sS antepoth.de ; date
Starting nmap V. 2.54BETA30 ( www.insecure.org/nmap/ )
Interesting ports on a15166696.alturo-server.de (212.227.20.60):
Port State Service
22/tcp open ssh
Nmap run completed -- 1 IP address (1 host up) scanned in 0 seconds
Thu Mar 31 10:07:48 CEST 2005
extfw:~ # nmap -p 22 -sS antepoth.de ; date
Starting nmap V. 2.54BETA30 ( www.insecure.org/nmap/ )
Interesting ports on a15166696.alturo-server.de (212.227.20.60):
Port State Service
22/tcp open ssh
Nmap run completed -- 1 IP address (1 host up) scanned in 0 seconds
Thu Mar 31 10:07:49 CEST 2005
extfw:~ # nmap -p 22 -sS antepoth.de ; date
Starting nmap V. 2.54BETA30 ( www.insecure.org/nmap/ )
Interesting ports on a15166696.alturo-server.de (212.227.20.60):
Port State Service
22/tcp open ssh
Nmap run completed -- 1 IP address (1 host up) scanned in 0 seconds
Thu Mar 31 10:07:50 CEST 2005
extfw:~ # nmap -p 22 -sS antepoth.de ; date
Starting nmap V. 2.54BETA30 ( www.insecure.org/nmap/ )
Interesting ports on a15166696.alturo-server.de (212.227.20.60):
Port State Service
22/tcp filtered ssh
Nmap run completed -- 1 IP address (1 host up) scanned in 3 seconds
Thu Mar 31 10:07:53 CEST 2005
Für Interessierte: Die /etc/shorewall/start enthält folgende Aufrufe:
== cut ==
############################################################################
# Shorewall 1.4 -- /etc/shorewall/start
#
# Add commands below that you want to be executed after shorewall has
# been started or restarted.
#
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW \
-m recent --update --seconds 60 --hitcount 4 -j DROP
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW \
-m recent --update --seconds 60 --hitcount 4 -j LOG --log-prefix "SSH_BRUTE_FORCE "
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW \
-m recent --set
== cut ==
Hierdurch wird dieses Regelset in der INPUT-Chain beim Start der Shorewall
erzeugt (sorry für die langen Zeilen):
Chain INPUT (policy DROP 1 packets, 28 bytes)
pkts bytes target prot opt in out source destination
0 0 tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 state NEW recent: SET name: DEFAULT side: source
0 0 LOG tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 state NEW recent: UPDATE seconds: 60 hit_count: 4 name: DEFAULT side: source LOG flags 0 level 4 prefix SH_BRUTE_FORCE '
0 0 DROP tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 state NEW recent: UPDATE seconds: 60 hit_count: 4 name: DEFAULT side: source
0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
72 5336 eth0_in all -- eth0 * 0.0.0.0/0 0.0.0.0/0
0 0 ipsec0_in all -- ipsec0 * 0.0.0.0/0 0.0.0.0/0
0 0 Reject all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 6 prefix horewall:INPUT:REJECT:'
0 0 reject all -- * * 0.0.0.0/0 0.0.0.0/0
Alle weiteren Zugriffsregeln werden dann wieder von der "eth0_in"
behandelt und dort greifen dann wieder die normalen Regeln.
Der Drop schützt somit mindestens mal bei einem Threshold
von 4 Connections pro Minute. Man darf gespannt sein, bis die ersten
SSH-Scanner dies auch noch konfigurieren können - insofern ist
das "Illegal user ... from ..." noch nicht ganz vom Tisch.
Merci noch einmal vielmals - das andere Problem mit dem Lesen von Logfiles
in PERL ist zwar damit noch nicht gelöst, aber das ist in der Tat nicht
ganz trivial. Ich probier noch einmal ein wenig herum.
t++
Reply to: