iptables recent die zweite
Mathias Mistrik
Im Thread iptables recent drop vom 03.08. kam u.a. auch die von Heise
vorgeschlagene Vorgehensweise zur Sprache.
Dazu habe ich eine prinzipielle Frage (deswegen neuer Thread):
Habe ich ein Verst�ndnisproblem, oder Heise, oder ist da ein heftiger Bug
im netfilter-Code?
Heise schl�gt zum Blocken von brute force Attacken auf den ssh daemon
folgende Regeln (auf einem System ohne weiteres Regelwerk) vor:
iptables -A INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m
recent --set
iptables -A INPUT -p tcp --dport 22 -i eth0 -m state --state
ESTABLISHED -m recent --update --seconds 60 --hitcount 2 -j
REJECT --reject-with tcp-reset
Die erste Regel sehe ich ein. Mit der zweiten d�rfte aber nach meinem
Verst�ndnis nicht mal eine Passwortabfrage zustande kommen.
Folgendes passiert aber bei mir (Kernel 2.6.25)
Ich mache eine SSH-Sitzung auf, die bleibt stabil (auch wenn ich in
dieser Sitzung Traffic erzeuge, z.B. durch ein "top"), in
/proc/net/ipt_recent/DEFAULT ein Zeitstempel geschrieben, der wird aber
nicht geupdatet.
Warte ich 60s und mache eine zweite Verbindung parallel zur ersten auf,
bleibt auch diese Verbindung stabil, in /proc/net/ipt_recent/DEFAULT
erscheint ein zweiter Zeitstempel, wieder ohne Updates.
Warte ich keine 60s, werden BEIDE Verbindungen resetet,
in /proc/net/ipt_recent/DEFAULT sind danach 4 Zeitstempel zu sehen.
H�? Das Verhalten h�tte ich nun �berhaupt nicht erwartet. Bug? Oder kann
mich jemand aufkl�ren.
merci
Matze
--
Der beste Beweis f�r die Existenz intelligenten au�erirdischen Lebens
ist die Tatsache, dass von denen noch keiner versucht hat, mit uns
Kontakt aufzunehmen.