![[HaBo]](/styles/default/logoklein.png){kind=small}
SSH Brute Force unterbinden
- Themenstarter thodt
- Beginndatum
Wenn du die Passwort-Authentifizierung abgeschaltet hast, dann stören nur die Meldungen im auth.log. Eigentlich braucht man sich darum kaum kümmern.
fail2ban hilft dagegen, wenn es richtig viel wird. SSH auf einen anderen Port legen kann das auch, aber als Sicherheitsgewinn ist das nicht zu sehen. Also eigentlich brauchst du dir keine Sorgen machen. Wenn du ne Kiste ans Netz setzt, dann setzen diese Versuche früher oder später ein, dagegen kann man kaum was tun.
Fazit: Public Key Authentication und gut ist.
fail2ban hilft dagegen, wenn es richtig viel wird. SSH auf einen anderen Port legen kann das auch, aber als Sicherheitsgewinn ist das nicht zu sehen. Also eigentlich brauchst du dir keine Sorgen machen. Wenn du ne Kiste ans Netz setzt, dann setzen diese Versuche früher oder später ein, dagegen kann man kaum was tun.
Fazit: Public Key Authentication und gut ist.
die chance existiert
bitmuncher
Senior-Nerd
Meine Erfahrung zeigt, dass zumindest die Log-Einträge stark zurück gehen, wenn man SSH auf einen anderen Port legt, da die meisten Versuche von Bots kommen, die nur den Standard-SSH-Port testen. Auf fail2ban kann man aber getrost verzichten, wenn Passwort-Auth deaktiviert ist.
Als Alternative zu fail2ban kannst du dir mal ossec anschauen. Damit lassen sich nicht nur Bruteforces aller Art unterbinden, sondern gleichzeitig werden z.B. auch Änderungen an Dateien, Fehler in Netzwerk-Streams usw. erkannt. Es ist also ein komplettes HIDS. Bei der Verwaltung von mehreren Servern lassen sich die Daten auch zentralisiert sammeln.
Als Alternative zu fail2ban kannst du dir mal ossec anschauen. Damit lassen sich nicht nur Bruteforces aller Art unterbinden, sondern gleichzeitig werden z.B. auch Änderungen an Dateien, Fehler in Netzwerk-Streams usw. erkannt. Es ist also ein komplettes HIDS. Bei der Verwaltung von mehreren Servern lassen sich die Daten auch zentralisiert sammeln.
Mit dem logbased HIDS habe ich mich auch schon auseinander gesetzt. Das IDS ist recht gut, in mancher Hinsicht sind die gelieferten Regelsätze jedoch unvollständig. Ich habe meine
Webserver/Webanwendungen ein wenig penetriert und das meiste konnte das System nicht erkennen.Im Web-Bereich hat mich das IDS also nicht wirklich überzeugt.
Nur so am Rande.
bitmuncher
Senior-Nerd
Angriffe auf Webapps sind erfahrungsgemäss sehr individuell und natürlich sind Default-Regelsätze eines jeden IDS auf die Anforderungen anzupassen. Selbst so komplexe IDS wie Snort schaffen es nicht Angriffe auf Webapps anständig zu erkennen, wenn man die Rulesets nicht entsprechend anpasst. Die Default-Regelsätze beziehen sich im Normalfall auf bekannte Fehler und Schwachstellen der Server-Software und nicht irgendwelcher Webapps.
Hinzu kommt, dass viele Webentwickler den Fehler machen, dass sie z.B. bei einem fehlgeschlagenen Login keinen entsprechenden HTTP-Error-Code auslösen, sondern auf eine Fehlerseite umleiten, die mit einem 200er ausgeliefert wird. Sowas kann ein IDS natürlich nicht als Angriffsversuch erkennen.
Da verhalten sich aber auch Tools wie fail2ban nicht anders. Wenn die nicht wissen wie Log-Einträge auszusehen haben, erkennen sie auch nichts.
Bruteforces, Angriffe auf das TCP u.ä. werden aber erfolgreich erkannt indem z.B. Meldungen ausgelöst werden, wenn ungewöhnliche TCP-Flag-Kombis auftauchen oder wenn die Anzahl der Logeinträge signifikant steigt.
Kurzum: Ein IDS ist immer nur so gut wie der Admin, der die Regelsätze dafür erstellt.
Hinzu kommt, dass viele Webentwickler den Fehler machen, dass sie z.B. bei einem fehlgeschlagenen Login keinen entsprechenden HTTP-Error-Code auslösen, sondern auf eine Fehlerseite umleiten, die mit einem 200er ausgeliefert wird. Sowas kann ein IDS natürlich nicht als Angriffsversuch erkennen.
Da verhalten sich aber auch Tools wie fail2ban nicht anders. Wenn die nicht wissen wie Log-Einträge auszusehen haben, erkennen sie auch nichts.
Bruteforces, Angriffe auf das TCP u.ä. werden aber erfolgreich erkannt indem z.B. Meldungen ausgelöst werden, wenn ungewöhnliche TCP-Flag-Kombis auftauchen oder wenn die Anzahl der Logeinträge signifikant steigt.
Kurzum: Ein IDS ist immer nur so gut wie der Admin, der die Regelsätze dafür erstellt.
Hackse
0
Solange die Passwortauthentifizierung via ssh eingeschaltet ist, ist das Verlagern des ssh-Ports auf einen beliebigen, z.B. 5-stelligen Port ein großer Unterschied. So habe ich auf einem meiner Server seit der Portverlagerung von ssh seit Jahren keinen einzigen Bruteforce-Angriff mehr zu verzeichnen, während ich zuvor auf Port 22 beinahe stündlich mehrere Bruteforce-Angriffe aus den unterschiedlichsten Regionen der Welt zu verzeichnen hatte.
Statistisch gesehen bist Du mit einer Portverlagerung somit durchaus sicherer, da in der Praxis oftmals mehrere IP-Ranges auf die Standardports gescannt werden und sich so gut wie niemand die Mühe macht alle 2^16-1 Ports zu scannen, es sei denn jemand möchte genau Deinen Host hacken und scannt daher alles durch.
Vollkommen richtig. Was mich nur verwunder hat, dass codierte Anfragen überhaupt nicht beachtet wurden. Somit konnte ohne Probleme eine SQL-Injection durchgeführt werden. Hätte gedacht, dass ein Produk von TrendMicro so etwas kann, schließlich ist eine Codierung einer Anfrage der beste und einfachste Weg als ein Angreifer seinen Code zu verbergen. Naja das wird nun OffTopic, wollte es nur mal erwähnt haben
Vollkommen richtig. Was mich nur verwunder hat, dass codierte Anfragen überhaupt nicht beachtet wurden. Somit konnte ohne Probleme eine SQL-Injection durchgeführt werden. Hätte gedacht, dass ein Produk von TrendMicro so etwas kann, schließlich ist eine Codierung einer Anfrage der beste und einfachste Weg als ein Angreifer seinen Code zu verbergen. Naja das wird nun OffTopic, wollte es nur mal erwähnt haben
Wenn du so willst, automatisiert ein IDS nur deine Admintätigkeiten. Du musst dem IDS über die Regelsätze sagen, was du als Admin als auffällig empfindest und genau das wird dann auch vom IDS aus auffällig gemeldet werden