Login-Versuche bei SSH

[larry]

Hoi,

ich hatte mal auf einem System eingestellt, dass man sich 3mal einloggen kann, danach wird bei jedem nächsten Login-Versuch eine Zeit mit einem Faktor mulipliziert. So wird die Wartezeit zum nächsten Prompt immer länger.
Wo kann ich das einstellen?
Hab schon rumgesucht und das hier gefunden. Ist für JunOS, aber genau das suche ich.
Schon mal Danke

 

[Dizzy]

openSSH?

Edit: Wenn openSSH: http://www.fz-juelich.de/jsc/files/docs/tki/tki-0330.pdf utner Konfiguration, dort wird eine für dich relevante Option aufgezeigt. Du könntest aber auch mal das Manual lesen.

 

[larry]

Nutze OpenSSH.
Hm... welche Option meinst du?
man-page hab ich schon durchforstet.

 

[Gast1]

Und welchen Sinn soll diese ganze Aktion haben?

Dienst ordentlich einrichten (Login nur als User, die Anzahl der berechtigten User beschränken, Rootlogin verbieten, nur keybasierter Login) und zurücklehnen (sofern man keine ungepatchte Debian-Version und schwache Keys verwendet).

Damit ist die Zeit besser verwendet als mit irgendwelchen "Loginbremsen".

Greetz,

RM

 

[Akendo]

Hoi,
ich hatte mal auf einem System eingestellt, dass man sich 3mal einloggen kann, danach wird bei jedem nächsten Login-Versuch eine Zeit mit einem Faktor mulipliziert. So wird die Wartezeit zum nächsten Prompt immer länger.
Wo kann ich das einstellen?

Also wenn ich das richtig verstand habe benutzt du OpenSSH (was sonst?) und hatte einmal einen eingerichtet SSH-Server welcher 3 Logins erlaubt und dann bei jeder weiter Login bis zu einem gewissen Zeitpunkt erlaubt? Die moechtest du nun auf einen Loaklen Server (wie auch immer) anweden.

Wo kann ich das einstellen?
Hab schon rumgesucht und das hier gefunden. Ist für JunOS, aber genau das suche ich.
Schon mal Danke

Also verweist du auf einem Link der etwas aehnlich Darstellen soll?
Richtig verstanden?

 

[keks]

Hallo,

Vielleicht ist Fail2Ban das was du suchst.
Ich setze das schon eine ganze Weile ein. Nicht nur für SSH sondern auch für Apache und Mailserver.

Das Tool blockiert anhand frei definierbarer Regeln zugreifende IP-Adressen und gibt sie nach einer gewissen (konfigurierbaren!) Zeit wieder frei.
Ganz nützlich um das sinnlose angehämmer mancher Script Kiddies, auf den sshD zu unterbinden.

Keks

 

[Akendo]

hm....Wenn es das waere wuerde /etc/hosts.* (access/deny) ausreichen, Ich denke mal nicht dass, es das ist was er sucht.
Aber Danke sowas hab ich gesucht xD.

so far
MFG Akendo

 

[keks]

hm....Wenn es das waere wuerde /etc/hosts.* (access/deny) ausreichen

Falsch. Ich will die Adressen ja nicht dauerhaft blockieren.
Ausserdem will ich die Adressen nicht per Hand eintragen.
Wie stellst du dir vor zu bemerken wenn sich ein host 3-n mal falsch anmeldet? Willst du die ganze Zeit vor deinem Rechner sitzen und ip's sperren und entsperren ?

 

[larry]

Ich erkläres nochmal, hoffe es gelingt mir besser.
Es sei MaxAuthTries irgend ein großer Wert und T eine Zahl größer als 1. Angenommen das Passwort wird durchgehend falsch eingegeben, dann erscheinen MaxAuthTries Prompts. Nun sollen die ersten 3 Prompts ohne Verzögerung erscheinen. Ab diesem Zeitpunkt soll eine Verzögerung eintreten. Nach dem n-ten Login-Prompt soll ein Delay von (n-2)*T Sekunden auftreten.

Bsp.: T = 3
Prompt: vertippt
Prompt: vertippt
Prompt: vertippt
3s warten
Prompt: vertippt
6s warten
Prompt: vertippt
9s warten
...

Warum ich das ganze will? Naja, Interesse und ist ein nettes Feature
So brauchen Dictionary-Attacks ein bisschen länger und sind beschäftigt :-)
@RM: Den Dienst hab ich, bis auf keybasiertes Login, so eingerichtet.

P.S.: Wobei es nichts ausmacht wenn sich die Verzögerung durch (n-2)^T oder T^(n-2) berechnet

 

[Gast1]

Die ganze Aktion ist dann trotzdem (oder vielleicht um so mehr) sinnlos.

Aber eine schöne Möglichkeit für einen DoS-Angriff, der Angreifer muss nur versuchen, sich mit einem validen Usernamen anzumelden (was ihm zwar nicht gelingt, daber das ist ja bei DoS schnurzpiepegal), das Ganze per Script, die Timeouts stören ihn also nicht die Bohne und der echte User ist geDoSt, weil sein Login blockiert ist.

 

[larry]

Ok, guter Punkt. Dann sollte sich das Ganze nur auf die aktuelle SSH-Session beziehen.

 

[Gast1]

*LOL*

Genial, und was soll das bitteschön bringen?

Nur auf die aktuelle Session bezogen?

Also auf gut Deutsch, nur wenn jemand eh schon eingeloggt ist, wird ein Brute Force auf genau diesen Account "ausgebremst"?

Da werden die bösen "H4xx0rz" aber grossen Respekt vor haben.

Dein ganzes Konzept ist Humbug, begreif es endlich.


Anstatt hier weiter Zeit und Hirnschmalz auf komplett sinnlose Aktionen zu verwenden, solltest Du Dich lieber um wirkliche Sicherheitsfeatures kümmern:

@RM: Den Dienst hab ich, bis auf keybasiertes Login, so eingerichtet.

Aber auch das schrieb ich ja bereits.

Und für alle, die immer noch glauben, solche Tools wie fail2ban wären ein Sicherheitsgewinn, mal was zum Nachdenken:

http://www.rootforum.de/forum/viewtopic.php?f=77&t=46097

Zweiter Beitrag von Captain Crunch.

 

[supersucker]

@RM

Das das, was der TE versucht, sinnlos ist sehe ich genau wie du.

fail2ban allerdings hat IMHO schon einen Nutzen, nämlich genau den gleichen wie den SSH-Port auf was anderes als 22 zu verlegen -> die Logs werden nicht komplett zugemüllt.

Außerdem kann man damit wenigstens die "dümmsten" DDOS-Attacken verhindern -> ist doch schon mal was.

Aber klar, gegen "intelligente" DDOS-Attacken bringt das alles nix....

 

[sim4000]

Wo wir grad bei dem Thema sind:
Wie schaut das denn mit Port Knocking aus? Bringt das denn was?

 

[Mike1]

Wo wir grad bei dem Thema sind:
Wie schaut das denn mit Port Knocking aus? Bringt das denn was?

ja, Rain_Maker hat das mal ziehmlich genial gemacht: der Computer erscheint komplett geschlossen...nur wenn man drei bestimmte Ports in einer bestimmten Reihenfolge knockt öffnet sich der SSH-Port hinter dem dann ein sshd wartet

 

[Gast1]

fail2ban allerdings hat IMHO schon einen Nutzen, nämlich genau den gleichen wie den SSH-Port auf was anderes als 22 zu verlegen -> die Logs werden nicht komplett zugemüllt.

Da muss ich Dir nun teilweise widersprechen, denn wie der verlinkte Artikel zeigt, gab (zumindest dieser einfache "Loginjection"-Angriff ist wohl gefixt) es in dem Fall eine Möglichkeit eines einfachen DoS _weil_ fail2ban oder ein anderes Tool installiert war.

Dann doch lieber Port verlegen, wobei natürlich (ich denke da besteht bei uns Konsens) die wirklich wichtigen Maßnahmen in der sicheren Konfiguration des Dienstes liegen und da besteht beim TE noch ein deutliches Defizit.

Außerdem kann man damit wenigstens die "dümmsten" DDOS-Attacken verhindern -> ist doch schon mal was.

Aber klar, gegen "intelligente" DDOS-Attacken bringt das alles nix....

Nun ja, dumm oder intelligent will ich gar nicht mal unterscheiden, gegen eine "richtige" DoS-Attacke mit entsprechender Bandbreite und Streuung (DDoS) ist eh kein Kraut gewachsen (zumindest keines, welches man _auf_ seiner Kiste installieren kann, das muss dann schon der Hoster an seiner Firewall/Gateway/Router wegwerfen).

Ich will auch saubere Logs und nutze Portknocking, nur das macht dann z.B. keinen Sinn, wenn viele User SSH-Zugriff haben sollen (bei mir soll das nur ein User dürfen, namentlich meinereiner).

Trotzdem (OK, auch hier besteht sicher Konsens) war Schritt Nr.1 die sichere Konfiguration des Dienstes, alles andere sind Features, die man haben kann, aber die die wirklich wichtigen Maßnahmen nie ersetzen und maximal ergänzen können, immer mit der Gefahr sich dadurch ein weiteres Leck zu bohren.

Ich besitze vielleicht ein gutes Maß an Phantasie, aber sich "meinen" DoS-Angriff von vorhin auszudenken, war wirklich nicht schwer, ich bin mir sicher, daß da draussen noch sehr viel phantasievollere und cleverere Burschen/Mädels sind, die noch viel bessere Ideen haben, wie man die Tatsache ausnutzen kann, daß sich jemand solche Zusatztools installiert.

Complexity breeds Bug .....

Greetz,

RM

 

[sim4000]

ja, Rain_Maker hat das mal ziehmlich genial gemacht: der Computer erscheint komplett geschlossen...nur wenn man drei bestimmte Ports in einer bestimmten Reihenfolge knockt öffnet sich der SSH-Port hinter dem dann ein sshd wartet

Schade, das so etwas nicht auf einem VServer geht. :\
Da kann man die iptables nur über ein Webpanel einstellen, wo nur simples Accept und Drop geht. Der Befehl "iptables" selber ist ja bekanntlich deaktiviert.

 

[supersucker]

Schade, das so etwas nicht auf einem VServer geht. :\
Da kann man die iptables nur über ein Webpanel einstellen, wo nur simples Accept und Drop geht. Der Befehl "iptables" selber ist ja bekanntlich deaktiviert.

Das wage ich mal stark zu bezweifeln, hier mal die Ausgabe von meinem VServer (Strato):

iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

 

[sim4000]

Das wage ich mal stark zu bezweifeln, hier mal die Ausgabe von meinem VServer (Strato):

iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Wenn ich bei mir als "root iptable -L" mache, kommt ein "Permission Denied". Was mit der Fritze vom Support auch bestätigt hat.

Bitte bedenken Sie lediglich das bei einem vServer kein eigener Kernel
eingesetzt werden kann und z.B. iptables nicht verwendet kann. Alternativ
haben Sie die Möglichkeit die Firewallfunktion im Server Control Panel
freischalten zu lassen. Dies ist kostenfrei.

Und das Webpanel kann halt nur stink normales Accept und Drop.

 

[larry]

Also auf gut Deutsch, nur wenn jemand eh schon eingeloggt ist, wird ein Brute Force auf genau diesen Account "ausgebremst"?

Na klar, wenn er eingeloggt ist bringts was ...
Also vor dem Einloggen wurde der Kanal ja schon verschlüsselt, dann soll sich das ganze auf den Login-Prozess dieser SSH-Verbindung beziehen. Sei es durch PID oder sonstiges.