ssh attack

Mr. BBQ

Mr. BBQ

Der Wurstfachverkäuferin
was kann man dagegen machen, wenn man um ca 2300-0000 hunderte wahnwitzige einloggversuche in der authlog stehen hat von diversen IPs. So wies aussieht muss es aber immer der gleiche typ sein - von den loginnamen her. ich möchte ssh weiterverwenden. aber kann man da das ganze nicht noch sicherer machen. ich hab nämlich angst, dass mein server gehackt wird.
 
Wenn du root Login verbietest und ein sicheres Passwort für deine User verwendest, brauchst du dir eigentlich keine Sorgen machen.
 
Ich habe meinen externen SSH-Zugang auf key-Authentifizierung umgstellt. Insofern niemand meinen Key hat und das zugehörige Passwort kennt, wird er sich mit herkömmlichen Einlog-Versuchen wohl vergebens abstrampeln!

Gruß,

Ice
 
was auch noch eine (imho) sehr gute moeglichkeit ist, ist den sshd auf einem anderen port laufen zu lassen.
und vielleicht auf port 22 einen kleinen honeypot, der eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeewig braucht um irgendwas auszugeben. keine ahnung, was es da gibt, aber das nimmt zumindest einer automatisierten attacke erstmal den wind aus den segeln.

ansonsten.... keine sorge, ist normal:

Code: 
% for I in authlog*gz ; do gzcat $I ; done | grep -i illegal.user | wc -l
   5987
% for I in authlog*gz ; do gzcat $I ; done | grep -i failed.password | wc -l
   6564
*g*
 
Zuletzt bearbeitet:
ich hatte auch mal diese hässlichen meldungen seitdem es diesen ssh brutforce
rauskam letztes jahr.

habe einfach ne schöne table gemacht mit allen ip ranges die ich an der arbeit
habe ( x.x.*.*) und die ips von meinen shells, das schön als incoming filter auf ssh
und ruhe war imnu, hat mich zwar and 2 oder 3 mal etwas nerven gekostet als ich
wo anders war wo ich anz andere ip ranges hatte und über 4 server ssh"en
muste um nach hause drauf zu kommen, aber es beruhigt ungemein ;)

Code: 
table <ALLOWED>    { $IP1, $IP2, ..... }    

pass in on $EXT_DEV inet proto tcp from <ALLOWED> port 1025:65535 to any   port $SSH flags S/SAFR modulate state label SSH

und das is auch das was dir dann helfen kann wenns wieder mal nen bösen ssh
remote exploid geben sollte.
 
Ich hab mir was lustiges einfallen lassen.
Erstmal komm ich bei mir nur noch mit einem Benutzer rein. Für alle anderen Benutzer kommt ne Meldung von wegen invalid user blabla ip-adresse.
Jetzt bastelt man sich mit pf eine kleine Tabelle und schreibt sich für diese Tabelle eine lustige Blockregel.
Jetzt kann man mit dem Proggi swatch in Echtzeit nach dem invalid user in den Logs ausschau halten und die ip adresse einem Script übergeben, welches die ip in die vorher angelegte Tabelle reinschreibt. Siehe da, alles geht sowas von schnell, dass das Angriffsscript nichtmal zum Passwort kommt. Es kommt lediglich noch ne Meldung, dass sshd vergeblich auf ein Passwort gewartet hat. :D
Ich find das irgendwie lustig :D
Wenn so ein system erstmal steht, dann kann man sich um ein ids gedanken machen, welches Logs für swatch produziert. Falls noch Fragen sind, dann fragt einfach.
 
@raver-softi
Die ganzen Haken an dem System werden bei einem Tippfehler im Benutzernamen deutlich oder wenn du über einen NAT-Gateway ins Netz gehst und ein anderer Benutzer "zufällig" den ssh-port deines Servers erwischt.
Oder kannst du von aussen die erstellte pf-Regel wieder aufheben? ;)
 
raver-softi schrieb:
Jetzt kann man mit dem Proggi swatch in Echtzeit nach dem invalid user in den Logs ausschau halten und die ip adresse einem Script übergeben, welches die ip in die vorher angelegte Tabelle reinschreibt.
...
Ich find das irgendwie lustig :D
Zum Vergrößern anklicken....

Lustig wird's erst, wenn du ausgesperrt wirst, weil jemand deine IP gespooft hat. Mit automatischem Blocken oeffnest du DoS Tuer und Tor.

Du solltest vielleicht noch ueber eine Whitelist nachdenken, bzw. den Regeln eine relativ kurze Lebenszeit geben. "Sauber" ist das aber trotzdem nicht ...
 
ich find's trotzdem ne nette idee, ansonsten kann ja noch ein
"anklopfen" oder isdn für einen sicherungszugang eingerichtet werden.
 
mit public key auth und "permit rootlogin no" können die sich von mir aus hunderttausend mal versuchen einzuloggen......


k33n
 
Auch eine Möglichkeit.:

Per default alles dicht machen und erst durch Portnocking den ssh-port frei klopfen. Das sollte glaube ich maximale Sicherheit bieten.
 
Aber nur, wenn das Port-knocking gegen replay-Attacken gesichert ist. Falls nicht, ist der Gewinn gleich Null.

Und ueberhaupt, Security through obscurity funktioniert nicht. IMHO ist port knocking ueberbewertet.
 
Ich hab noch webmin laufen. Damit kann ich einfach die Tabelle löschen und alles wäre wieder freigeschaltet. Sicher hakt meine Lösung an einigen Punkten aber ich schätze einen Angriff per IP-Spoofing als eher gering ein. Ich kann mir so einen Angriff ehrlichgesagt nur aus dem internen Netz vorstellen, lasse mich aber gerne eines besseren belehren. Hab DSL und ne dynamische IP die alle 24h erneuert wird. Das mit der zusätzlichen whitelist ist eine gute Idee. Danke für den Tipp. Dann wäre da noch das Argument mit dem Tippfehler. Ja gut, da muss ich halt aufpassen, dass ich da keinen Tippfehler reinbaue. Sowas kann man aber sicherlich irgendwie in dem Blockscript einbauen, dass man sich vielleicht einmal vertun darf. Irgendwie ist mir da ein Stichwort authpf eingefallen. Weis jetzt aber nich wieso. Jemand ne Idee?
 
Die Wahrscheinlichkeit viel groesser, dass jemand durch eine Sicherheitsluecke in (IMHO unnoetiger)
Software wie Webmin deinen Server kompromittiert, als das ein _gutes_ Passwort geknackt wird.
Meiner Meinung nach ist der ganze Aufwand nicht gerechtfertigt und schadet mehr, als er nuetzt.
 
Ich sag ja, wenn so ein System ersteinmal läuft, kann man das auch auf Webmin ausweiten. Manchmal ist es doch so, dass man von irgendwo kein ssh machen kann, weil alles nur übern webproxy läuft. Deswegen hab ichs noch laufen. Ansonsten hast du Recht, dass man es eigentlich nicht braucht. Dieses ssh Angriffsscript beschränkt sich aber nur auf ssh und nicht auf webmin. Wenn mich jemand scannt, dann landet der auch in dieser tabelle. Man muss also schon wissen, dass bei mir webmin läuft. es geht aber jetzt nicht um webmin, sondern darum, wie man solchen ssh Attacken aus dem weg geht bzw. sie begrenzt. Da hat webmin nix mit zu tun, deswegen sollten wir unsere Gedanken wieder auf das eigentliche Thema lenken, ok? Weitere Vorschläge?
 
Ich sag ja, wenn so ein System ersteinmal läuft, kann man das auch auf
Webmin ausweiten
Zum Vergrößern anklicken....
jo das thema webmin extern bereitzustellen sollten wir mal ganz schnell
vergessen, das hat dann nichtsmehr mit dem wort "security" zutun.

Manchmal ist es doch so, dass man von irgendwo kein ssh machen kann,
weil alles nur übern webproxy läuft.
Zum Vergrößern anklicken....
in dem fall kann man eventuell mit https tunnel gegenwirken um ssh zu machen
durch webproxys.

Man muss also schon wissen, dass bei mir webmin läuft. es geht aber
jetzt nicht um webmin, sondern darum, wie man solchen ssh Attacken aus dem
weg geht bzw. sie begrenzt. Da hat webmin nix mit zu tun, deswegen sollten wir
unsere Gedanken wieder auf das eigentliche Thema lenken, ok? Weitere
Vorschläge?.
Zum Vergrößern anklicken....
SSHD port verändern sowie im packetfilter die incoming IP"s beschränken auf den
SSHD port (am besten statische ips oder mindestens x.x.x.0). damit geht man
schonmal 99% aller kiddy scänns und angriffen aus dem weg.

die restlichen 1% die darf man dann noch ernst nehmen weil da jemand
hintersteckt ders wahrscheinlich auf einen abgesehen hat, weil keiner spooft ne
ip(die erlaubt is) und greift einen port an (der wo ganz anders liegt als default)
der nicht schon etwas übers system weiss.

mehr als den sshd würd ich von aussen garnicht zugänglich machen, alles weitere
was man haben möchte kann man ja ohne weiteres mit authpf regeln.
 
ich habe seit dem ich das jail howto von asg gemacht habe und ein paar jails am laufen habe, keine so große angst mehr. du kannst ja eine jail nach außen zugänglich machen und da schon ein hartes passwort vergeben. rootlogin natürlich verbieten. naja und dann von deiner jail aus auf deinen host zugreifen, sofern das nötig ist.
 
SSHD port verändern sowie im packetfilter die incoming IP"s beschränken auf den SSHD port (am besten statische ips oder mindestens x.x.x.0). damit geht man
schonmal 99% aller kiddy scänns und angriffen aus dem weg.
Zum Vergrößern anklicken....

Ich sags nochmal, das sind keine kiddys, das sind kompromittierte Server von denen die ssh Atacken ausgehen. Normalerweise müsste man den Admins ne Mail schreiben, dass ihr Server da gerade was böses tut und ganz viel Traffic und Geld kostet.

Dann hatte ich das mit authpf doch noch richtig in Erinnerung. Das werd ich demnächst mal einbauen. Das ist ne wirklich gute Idee.

Für alle die authpf nicht kennen sei gesagt, dass authpf ein Teil der Firewall darstellt, bei dem man sich per ssh anmelden kann. Wenn man jetzt noch entsprechene Regeln einbaut, kann jeder User seine individuellen Ports und Dienste freischalten. War doch richtig oder?

Sind ja doch noch ne menge guter Vorschläge zusammengekommen. Das ist zu einer guten Resource für andere geworden, die die selben Probleme haben!
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben