Re: Delay nach erfolglosem login
Am 2004-11-22 19:34:23 schrieb(en) Andreas Kretschmer:
am Mon, dem 22.11.2004, um 17:56:32 +0100 mailte Richard
> ich hab das eben erfolglos versucht, scheint als waehre das unfug.
Ohne es probiert zu haben: es ist Unfug, weil es maximal Sinn machen
würde, das Limit auf SYN-Pakete zu setzen. Mit obiger Regel werden
Verbindungen generell kaputt gemacht. Und Sicherheit gewinnt man _SO_
auch nicht.
wahr. aber das sollte doch irgendwie zu schaffen sein? nur die syn zu
limitieren klappt nicht.
iptables sollte die tuer zumachen sobald der erste verbindungsversuch
fehlschlaegt - nur fuer eine minute. ein delay kenn ich sonst von der
login.defs ...jetzt in /etc/sec*? (pam) aber ich kenne das modul/
parameter nicht.
> --source-rng, man iptables.
> aber wenn eure erlaubten zugriffe von einer dynamischen ip kommen,
kann
> man mit der netmask entsprechende bereiche definieren.
Damit öffnet man aber auch Angreifern via DOS die Tür. LIMIT als
Security-Regel zu nehmen ist IMHO einfach nur krank.
asche auf mein haupt - hab' mich geirrt.
mit limit waechst hier nichts.
die doc hatte ich noch (zu) blass in erinnerung :(
http://www.netfilter.org/documentation/HOWTO/de/packet-filtering-HOWTO-7.html
(7.3 Andere gueltige Erweiterungen --limit)
> ich denk' das logfile verwenden und daraus eine rule fuer iptables
> (oder hosts.allow/xinetd) erstellen ist kein schlechter weg. einen
Wenn ich weiß, daß Du das machst, mache ich spielend einfach Deinen
Zugang kaputt. Okay, ich bin noch nicht drin, aber: Du auch nicht.
Immerhin.
Wieso? nichts interessantes hier :)
DOS an mein sshd - dazwischen sind noch hwrouter. und soll syncookies
hier nicht auch helfen? ich hab das (schon vor einiger zeit) mit ua.
einem eineinhalb tage lauf des nessusd versucht und es trotz teilweiser
hoher load nicht hinbekommen was kaputtzumachen - was nichts heisst:
ich beschaeftige mich viel zu wenig mit dem cracken einer schuessel.
angenommen man nimmt also die limit rule um exzessives logging zu
verhindern - wofuer es eigendlich gedacht ist?. periodisch faehrt ein
cronjob drueber und entscheidet aus dem ipt-logging und der auth.log
ueber ip/mac-durchkommen oder ip-fallenlassen. schliesslich fuegt's 'ne
rule ein oder/und entfernt eine zu alte.
als standard ist 22 listening.
selbiges script wird vom tcpwrapper und crond gestartet. es entscheidet
darueber andere ports fuer einen validen user fristig freizuschalten
(zb. weil bei login success jemand auch an den ftpd oder httpd will)
und macht bei einem falschen login ein paar gegencheck's mit nmap und
um die ernsthaftigkeit des versuches zu checken ein 500 packets langes
tcpdump. um bessere info im log zu haben.
das hilft freilich nichts mehr, wenn man schon gehackt ist. dafuer ist
dann aber auch bsign/tripwire zustaendig.
2.4,noipv6,full nat,ssh (sftp-only)
was daran waere gefaehrlich?
Andreas, sinnvolle andere Wege genannt habend.
gruss, ritch.
Reply to: