On Wed, 30 Mar 2005, Bruno Hertz wrote:
> Stefan Muthers <[EMAIL PROTECTED]> 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++
