nach 3x falchen loginsversuchen per ssh firewall sperren

F

fidor

Geschmacksverstärker
nach 3x falschen loginsversuchen per ssh -> firewall sperren

Hi,

Tja der Betreff sagt ja schon alles. Ich möchte sämtlichen Verkehr von und zu einer IP blocken, wenn jemand von dieser IP mehr als 3 fehlerhaft Loginversuche beim sshd gemacht hat. Bei ftp könnte man das ja über snort machen. Aber da ssh verschlüsselt ist.....
in man sshd_config hab ich nichts gefunden. Gibts Lösungsvorschläge?? Suchmaschinenhinweise reichen vollkommen.... :)

fidor(..)
 
Zuletzt bearbeitet:
hi

nicht "direkt".
grober ansatz: logfileparsing aus zB cron heraus, um ueberhaupt mal "3 mal von $foo" festzustellen.
in pf(4) kann man das dann ueber anchors seperat hinzufuegen.
anchors sind in pf.conf(5) beschrieben, das logfile parsing liegt in deiner hand :->>

HTH,
 
evtl. ueber tcp-wrappers?
in der /etc/hosts.allow sowas wie:

sshd : ALL : counter %u %h : allow

womit dann eigentlich pro connect das script "counter" ausgeführt weden sollte %u ist user (oder eher meistens unknown) %h ist host.
In besagtem script könntest Du nach einer gewissen Wartezeit (Logintimeout der ssh) in den logs nach dem connect parsen und mitzählen, wie viele falsche versuche nacheinander kamen.

Ist wie von double-p eher ein grober Ansatz und wahrscheinlich eher nicht empfehlenswert, aber war so mein erster Gedanke ...

Viel Glygg :)
kaz
 
Ich kann dir zwar keine Lösung zu deinem Problem anbieten, ...
aber ich würde z.B. nur PubkeyAuthentication erlauben, dass dürfte doch schon einiges mehr an
Sicherheit bringen.

Und warum eigentlich immer 3 Versuche? Wenn du das ganze auf eine Loginanzahl beschränken willst,
dann nimm doch 100 oder 1000. Man hat sich schnell 3x Vertippt und wenn du dir über 100 oder 1000
Versuche sorgen machen musst, dann solltest du vielleicht ein anderes Passwort wählen.

Meine Meinung ...
 
zeec schrieb:
Man hat sich schnell 3x Vertippt
Zum Vergrößern anklicken....
Also sooo häufig vertippe ich mich nicht 3mal. Das passiert eigentlich nur, wenn meine keybindings nicht ok sind.... :D
Ich dachte mir ich sperre nach 3 Fehlerversuchen erstmal die IP für 10 min. Also noch ertragbar, wenn man was falsch gemacht hat. Reicht aber aus, um nen Dict-Angriff wesentlich zu verlangsamen. Um meine Passwörter mache ich mir eigentlich keine Sorgen. Dies stehen garantiert in keinem Wörterbuch. Noch nicht mal einzelne Unterstrings... hehe... Wirklich nur wirre Zeichenketten. Na wie auch immer. Das ist eigentlich aus Interesse entstanden, nicht weils notwendig wäre. Na ich denke ich muss sshd patchen. Wäre zumindest die sauberste Lösung. Vielleicht dieses Wochenende :D

Gruss
fidor(..)
 
Ich würde auch 10, 50 oder 100 Mal als Limite setzen. Ich habe mich auch schon dreimal
hintereinander vertippt.

Dann musst Du das mit den 10 Minuten auch nicht machen.
 
flomul schrieb:
Dann musst Du das mit den 10 Minuten auch nicht machen.
Zum Vergrößern anklicken....

Ich muss das mit dem Zeitlimit allein schon deswegen machen, da es dynamische IP Vergabe gibt. Wäre doch zu ärgerlich, wenn ich mich einloggen will, das aber nicht geht, weil irgendein Honk mal von der IP ne Dict-Attacke gestartet hat. Und wenn ich es schon realisieren muss, dass die IPs nach x Tage wieder freigegeben werden, dann isses auch kein Problem die nach 10 min freizugehen.

fidor(..)
 
Sowas macht man nicht, weil man dann fuer DoS anfaellig ist. Waehle einfach ein starkes Passwort und aendere das haeufig. Das ist die eigentliche Loesung.
 
warum DoS? Er will den port doch nur für den blocken der 3 mal falsches pw eingegeben hat. alle anderen können problemlos drauf :)
 
Ach, du weisst, dass man Adressen faelschen kann? Wenn ein Angreifer das ganze einfach fuer 1000 Adressen 3x macht, dann geht nichts mehr.
 
@MrFixit
ACK, zu sehr DoS anfaellig.

die 10min sind nicht besser als n-tage. wenn ein dict angriff laeuft, geht der schneller weiter als man sich zwischen zwei 10min intervallen einloggen kann.
 
<ot>
nach 3 mal falsch account sperren is schon ne feine sache, aber wenns einem so geht wie mir der dann 2 tage auf wieder freischalten warten muss dann is es bisl zu heftig
aber wenn man bei dir nicht alle 2 monate sein passwort ändern muss is das ne gute idee
</ot>
 
kith schrieb:
die 10min sind nicht besser als n-tage. wenn ein dict angriff laeuft, geht der schneller weiter als man sich zwischen zwei 10min intervallen einloggen kann.
Zum Vergrößern anklicken....
@kith: Entweder kapiere ich nicht was Du sagen willst, oder Du hast nicht ganz gecheckt worum es hier geht.
@fixit: Ja DOS. Stimmt. Irgendwas in meinem Hinterstübchen hatte sich auch beschwert. Bin aber nicht drauf gekommen.
DOS. Ist eine wirklich begründete Sorge. hm. Ich denke man könnte den DOS zwar noch erheblich erschweren, aber prinzipiell ist der wohl immer da, wenn man IPs aufgrund von miesem Verhalten sperrt. Da bleibt dann abzuwägen, was schlimmer ist dict oder DOS.

fidor(..)
 
Hm ja das mit den keys. Prinzipiell gibts aber auch um alle services. Also auch ftp etc. Aber das kann ich mit dem DOS Argument ja in die Tonne kloppen.
Wie auch immer. Noch ne OT Sache:
Wie einfach ist das überhaupt zu spoofen, wenn die Sequenznummer zufällig gewählt werden (werden sie doch oder??) ? Ich mein auch wenn da nur Pseudo-Zufallszahlen hinterstecken. Ist die Chance (erfolgreich) gespooft zu werden nicht eher verschwindend gering? Also generell: Wie spoof sicher ist OpenBSD?
[edit]
Mal abgesehen von man-in-the-middle attacken und wenn ich davon ausgehen, das der Angreifer nicht im gleichen Netz sitzt und die Sequenznummer einfach raussniffen kann
[/edit]


fidor(..)
 
Zuletzt bearbeitet:
Fuer eine solche Attacke waere die Sequence ja sowieso bekannt. Das "erraten" braucht man nur,
wenn man eine fremde Verbindung uebernehmen oder resetten will.
Aber generell ist eine stehende (syn,syn+ack,..) tcp verbindung schwer zu spoofen, da in beide
Richtungen das Routing "in der Hand" sein muss ;->

Ich hab mir so nen "3 mal" zuletzt auch schon ueberlegt, da die automatischen ssh login-scanner mit
accounts test, guest etc langsam schlicht nervig im authlog werden.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben