[Frage] Angriffe auf Dropbear/ beschriebene Schwachstelle behoben?

ao schrieb:

Was ist die aktuelleste, im Freetz-Trunk verfügbare Dropbear-Version? Besteht bei dieser die unter dem o.g. Link beschriebene Schwachstelle?

Zum Vergrößern anklicken....

Hi, das ist Version 2012.55, siehe hier. Und diese Version wird in dem von dir verlinkten Artikel empfohlen.

ao schrieb:

Oder muss ich mir Gedanken machen, dass beim 2. Versuch (IP 46.165.201.147) laut Log immerhin ca. 4 Minuten zwischen "Child connection" und "exit before auth" vergingen?

Zum Vergrößern anklicken....

Das sind nur 4 Sekunden.

@ao: Du brauchst dir keine Gedanken machen. Ich hatte früher schon Schlimmeres erlebt. Mit den alten Defaultwerten von dropbear konnte man die alten Boxen (7050) sogar zum Reboot bringen. Daher hatte ich damals die Werte etwas enger angepasst, die da anzupassen wären. Sie sind bestimmt in einem der patches immer noch zu finden. Ich erlaube parallel 3 Sessions, wenn ich mich richtig besinne. 3 darum, weil man im Falle WinSCP+Putty als Terminal alleine schon zwei Sessions belegt. Der alte Wert lag bei 5 oder sogar bei 10. Dann beschränke ich Anzahl der Fehlversuche für falsche Passwörter. Früher lag dieser Wert bei 10, jetzt sind es nur 3. Kannst du gerne ausprobieren, wirst dann rausgeschmießen (Session wird geschlossen). Dann habe ich noch das Warten unter Anmeldepromt auf 30 Sekunden verkürzt. Früher waren es 10 Minuten oder ähnlich. Das ist die Wartezeit zum Eingeben des Passwortes. 30 Sekunden dürfen normalerweise ausreichen. Auch für lange Passwörter.
All diese Maßnahmen erschweren das Leben von möchte-gern-hack-Kiddies, die meistens sowas tun (das konnte man zumindest bei mir anhand von Logs feststellen). Was an der ganzen Geschichte natürlich fehlt, ist die intelligente Sperrung der besagten IP. Da muss man aber sagen, dass wir hier mit einer Box und keinem richtigen Rechner und mit einem kleinen dropbear zu tun haben. Man kann also einfach nicht alles haben.
Wenn dich die Maßnahmen interessieren, wie du sowas grundsätzlich absichern kannst und wie du es auch überwachen kannst, kann ich etwas rausholen, wenn hier Interesse dazu besteht. Mir wurde nämlich zu meiner Schande mal vor Paar Jahren der Strato-Root-Server gehackt. Da ich anschließend zu faul war, den Server neu aufzusetzen, habe ich leider nicht alle Spuren vom Angreifer beseitigt. Bzw. mir war auch der Ausmaß des Schadens nicht bewußt. Irgendwie bin ich aber damals auf die Idee gekommen, einen kleinen login-to-mail-Skript zu schreiben, der bei jeder Anmeldung mir eine E-Mail geschickt hatte. Als ich eines Tages eine Mail bekommen hatte, dass sich die Benutzer "games" und "bin" auf dem Server angemeldet hatten, hatte ich sofort verstanden, wie ernst das Ganze war und wie wenig ich dafür getan hatte. Da es glücklicherweise am Wochenende passiert war und der Angreifer für einige Zeit weg war (warum auch immer), konnte ich diesen Krieg knapp gewinnen. Als Reaktion darauf habe ich mein Überwachungssystem noch weiter verstärkt und die Anmelderichtlinien für den SSH-Server ins fast unmögliche hochgeschraubt.
Was will ich damit sagen? Es ist alles möglich. Man kann die Logs sicherlich etwas ausführlicher gestalten, man kann OpenSSH anstatt dropbear einsetzen, man kann noch viel mehr tun. Ich persönlich würde dies aber für die Box nicht unbedingt tun. Hinter so einer Box mit schlechter DSL-Anbindung und dynamischer IP-Adresse rennen nur solche Skript-Kiddies hinterher. Ernst wird es erst bei Root-Servern mit einer festen IP und einer guten Internetanbindung. Wenn ich dir erzählen würde, mit welchen Tricks der Angreifer bei meinem Root-Server damals gearbeitet hat, stünde es mit den Skript-Kiddies in keinem Vergleich.
Von daher, updates öfter fahren, port von 22 anderswo legen und ruhig schlafen...

MfG

@ ao:

Du könntest auch einfach iptables auf die Box bringen und mit geeigneten Regeln den ssh-Zugriff auf einige wenige IP-Adressen begrenzen (z.B. auf "sichere" Systeme mit fester IP, auf denen Du einen Account besitzt).
Grüße,

JD.

@JohnDoe42: Vergiss es, ist unpraktikabel. Er versperrt sich damit selbst. Wenn du selbst viel unterwegs bist und vor allem von einem anderen DSL-Anschluss mit einer dynamischen IP da rein willst, schaffst du es nicht. Und gegen Angreifer hillft es genau so wenig, wie MAC-Filter im WLAN-Netz. Der Angreifer, der bei mir auf meinem Root-Server unterwegs war ist zu mir von einer IP einer polnischen Uni gekommen. Ich bin aber an der Stelle fast fest davon überzeugt, dass er diese IP einfach nur benutzt hat und selsbt komplett anderswo her kommt. Das ist übrigens einer der Gründe, warum solche Hacker sehr scharf auf STRATO-Root-Server sind. Somit bekommen sie eine gute Möglichkeit von einer frankfurter-IP mit einer guten Anbindung sehr viele wilde Sachen zu machen. In meinem Falle habe ich es damals rein durch Zufall entdeckt, dass der Server gehackt wurde. Der Angreifer hat den Server zwar gehackt, wollte den aber anscheinend für beste Tage aufbewahren. Er wollte sich auch nicht sofort zu erkennen geben. Und aufgefallen war er durch einen reinen Zufall. Er wollte meinen zu dem Zeitpunkt ziemlich veralteten Debian4 auf Debian5 updaten. Und da ist ihm etwas bei "apt-get update" schief gegangen. Dadurch liefen bei mir anschließend einige Dienste nicht mehr und bei der Ursachenforschung ist da einiges ans Licht gekommen.
Ich will damit nur sagen: Wenn da einige Hacker wirklich ernsthaft hinterher sind, dann helfen solche Tricks nicht. Andererseits rennen keine Hacker hinter irgendwelchen Privatanschlüßen mit einer Fritz!Box und DSL-Anbindung.

MfG

hermann72pb schrieb:

Wenn du selbst viel unterwegs bist und vor allem von einem anderen DSL-Anschluss mit einer dynamischen IP da rein willst, schaffst du es nicht.

Zum Vergrößern anklicken....

Möglicherweise meinen wir verschiedene Sachen: Ich meinte den Zugriff auf seine Box auf Systeme zu begrenzen, auf denen er AUCH einen Account hat.
D.h., daß er sich zuerst auf einem anderen System (mit fester IP) einloggt und dann von da aus zu seiner Box.

Somit bekommen sie eine gute Möglichkeit von einer frankfurter-IP mit einer guten Anbindung sehr viele wilde Sachen zu machen.

Zum Vergrößern anklicken....

S.o. Das ist die Vorgehensweise, die ich (für ihn) meinte. Nur halt dieses Mal für Ihn und nicht für einen Angreifer. Und wenn das erste System ausreichend sicher (in Bezug auf Login-Regeln, fremde Accounts usw.) ist, erhöht dies in diesem Fall auch die Sicherheit seines dropbear-Servers, da Logins nur von zwei (oder drei oder vier ...) IPs zulässig sind.
Wenn man viel unterwegs ist, muß man sich halt zunächst auf dem ersten System einwählen. Ist etwas lästig, schafft aber, wie ich finde, Sicherheit.
Grüße,

JD.

hermann72pb schrieb:

port von 22 anderswo legen und ruhig schlafen...

Zum Vergrößern anklicken....

Das dürfte die einfachste und effektivste Methode sein: wenn man schon beim ersten Mal die Portfreigabe nicht auf :22 sondern :12345 macht, hat man keinen zusätzlichen Arbeitsschritt

stan23 schrieb:

...Portfreigabe nicht auf :22 sondern :12345 macht, hat man keinen zusätzlichen Arbeitsschritt

Zum Vergrößern anklicken....

Das ist nicht immer sinnvoll, z.B. dann nicht, wenn man auf dem Weg zu seinem SSH-Server durch Firewalls muß, die alle bis auf einige Standard-Prots blocken.
Dann ist zumindest längeres Portscanning angesagt, wobei man sich ggfs. keine Freunde macht.
Grüße,

JD,

@ao: Wie ich schon oben mehrfach angedeutet hatte, würde ich den Wahnsinn bzgl. Fritz!Box nicht unnötig in die Höhe treiben. Bei echten Serversystemen sieht es anders aus.
1. Ich habe z.B. an meinen Boxen den Port nicht von 22 auf irgendwo anders umgelagert. Gestern hatte ich wieder Paar Angriffe aus Russland im Log gesehen. Wahrscheinlich werde ich doch vom Port 22 weg gehen. Das bringt übrigens am Meisten Erfolg gegen Skript-Kiddies.
2. Ich habe sowohl Passwort-Zugriff als auch Keys. Allerdings sind Keys bei mir ohne Passphrase. Da bist du schon viel weiter, ao. (beim STRATO-Server sieht es natürlich anders aus)
3. Nichtrootzugriff wird im Falle der Box schwer zu machen sein. Ich weiß nur, dass ich bei meiner QNAP-NAS es zwar ging, man musste aber schon vieles im System ändern. Die Fritz!Box ist leider so konzepiert, dass hier ziemlich alles als Root läuft. Es gibt nur vereinzelt Pakete, die chroot-mäßig auf der Box was tun: vsftp, apache usw. D.h., wenn du dich dafür entscheidest wird es ein steiniger Weg sein. Ich sage nicht, dass es unmöglich wird, es wird aber sich schwierig gestalten.
4. dropbear ist ein kleiner SSH-Server. Wenn du dich ernsthaft mit SSH befassen willst, nimm lieber OpenSSH. Übrigens, wenn du FTPS-(oder SFTP)-Zugriff irgendwo in menuconfig auswählst, werden sowieso Teile von OpenSSH da mitkompiliert. Das muss man einfach wissen (man kommt nicht drauf). Von daher OpenSSH ist schon nicht ganz für die Box oversized. Man kann es sicherlich einsetzen. Für OpenSSH gibt es im Netz deutlich mehr Infos, als zu dropbear.
5. Parameter von dropbear habe ich irgendwo im build-Prozess angepasst. Sprich, sie werden da fest einkompiliert. Om man sie im laufenden Betrieb verändern kann, weiß ich nicht. Irgendwie wahrscheinlich schon, man muss es nur wissen. Schau dir im trunk die Quellen und vor allem die Patches dazu. Dieser Patch heißt irgendwie so "dropbear-login" oder ähnlich. Wirst du sicherlich fündig. Da kannst du anschauen, was ich dort verändert hatte.

Jetzt einige Ideen zur totalen Überwachung und zur strengen Absicherung. Die Maßnahmen habe ich bei mir auf dem Root-Server implementiert:
1. Port von 22 auf etwas anderes Verlegen
2. Passowrt-Zugriff für root per ssh verbieten. Zertiffikat mit Passphrase
3. Eine Gruppe "sshusers" oder ähnlich erstellen. In Konfig zu OpenSSH irgendwo angeben, dass nur Benutzer dieser Gruppe sich per SSH anmelden dürfen. OpenSSH kann das. Ob es auch bei dropbear geht, weiß ich nicht.
4. Der Benutzer root ist zunächst nicht in der Gruppe "sshusers"
5. Einen (oder 2-3) nicht-root-Benutzer anlegen und denen Rechte geben, die Gruppe "sshusers" zu verwalten. Diesen Benutzer bitte irgendwelche komische Namen geben, die nur ihr merken könnt. Irgendwas, wie "schulz-wache" oder keine Ahnung. Für diese Benutzer einen SSH-Zugriff mit Zertifikaten einrichten. Hier könnte man sich die Passphrase sparen.
6. Ein Skript auf dem Server ablegen (z.B. "lass-root-rein.sh"), dessen Aufgabe es ist, den Benutzer root temporär zur Gruppe "sshusers" hinzufügen und zu entfernen. Ich habe da in Skripting schon etwas Gehirnschmalz investiert. Bei mir wird es geloggt usw.
7. Die Anmeldung läuft folgendermassen: Der Benutzer "schulz-wache" meldet sich an und startet "lass-root-rein.sh" mit &. Anschließend kann er sich ausloggen. Jetzt darf der root sich anmelden. "lass-root-rein.sh" läuft bei mir im Hintergrung und nimmt den root nach einer bestimmten Zeit automatisch aus "sshusers" wieder raus.
8. Zur Überwachung gibt es bei mir wiederum ein Skript, welches beim jeden Login einen Eintrag ins Log schreibt und zusätzlich eine E-Mail mit interessanten Infos verschickt. Dieses Skript kann man z.B. in /etc/profile oder in /etc/.bashrc oder in beides eintragen lassen. Wichtig ist hier, wirklich in /etc/ und nicht unter den jeweiligen Benutzer. Dann kriegt man deutlich mehr mit. Mit dem E-Mail-Versand kann es natürlich in die Hose gehen. Je nachdem, welcher Benutzer sich anmeldet, darf er die Mails versenden oder eben nicht. Das ist systemabhängig und mail-Server-abhängig. Bei meinem Root-Server funktioniert es aber recht zuverlässig.

Aber wie gesagt, diese Überwachung und Absicherung würde ich nicht unbedingt in diesem Umfang auf einer Box treiben. Dafür ist es schon etwas oversized. Vielleicht übernimmst du da aber eine oder andere Idee für dich.

Edit:Bzgl. Verlegung vom Port 22. Genau das ist der Grund: Du weiß nie, ob du über andere Ports durch kommst.
Bzgl. eines großen Servers als quasi-proxy. Ich persönlich würde sowas nicht machen. Bei meinem Root-Server will ich z.B. dadurch keine zusätzlichen Löcher schaffen, nur um an eine Fritz!Box zu gelangen. Klar, sind Root-Server an sich besser geschützt. Und klar, dass man diesen "proxy-pfad" sicher machen kann. Aber auch da kannst du Fehler machen und zusätzlich Löcher an deinem Hauptserver erzeugen, die dir letztendlich viel mehr Ärger bringen können.

MfG

Eigentlich hättest du dropbear auf Port 22 lassen können und über AVM-Firewall die Regel 443->22 erstellen. Natürlich solltest du dafür sorgen, dass AVM-Fernzugriff 443 nicht belegt.
Zu meinem Skript. Ich würde es ungerne hier für die Allgemeinheit posten. Erstens hat es eher weniger hier mit dem eigentlichen Thema zu tun, zweitens gibt es im Skript oder im Konzept an sich sicherlich irgendwelche Lücken, die ich damit verraten würde. Lass uns per PN in Verbindung treten und die Infos untereinander austauschen. So wie es aussieht, hast nur du Interesse daran. Von daher müssen wir es hier nicht unbedingt diskutieren.
Die Hintergrundinfos zu meinem Skript: Nein, es läuft auf einem richtigen Root-Server mit einem eigenständigen sendmail (postfix) unter Debian. Daher wirst du sicherlich einige Anpassungen an Skript tätigen müssen, damit es überhaupt auf FB läuft.

MfG

Wieso startet und stoppt ihr SSH nicht einfach über Port Knocking? Oder gibts da auch wieder einen Haken?

Wenn du irgendwo draußen bist, dann hast du unter Umständen keine Lust oder keine Möglichkeit das "Klopfen" durchzuführen. Darum wäre es zumindest für mich zu umständig.
Im Grunde genommen, mache ich auch in meinem Beispiel (s. oben) so eine Art "anklopfen". Mit dem Unterschied, dass es nicht über die Ports passiert, sondern über einen Zwischenbenutzer.

MfG

Hat irgendwer zufällig denyhosts auf seiner Box laufen? Ich hab letzte Nacht vergessen SSH zu deaktivieren und heute morgen war das Logfile einfach mal übervoll. Da hab ich scheinbar eine schlecht IP erwischt beim reconnect.

In der Beschreibung zu denyhosts steht folgendes:
Ich stelle mir folgende Fragen in dem Zusammenhang:
1. Ist es nicht oversized, nur dafür einen Python-Skript auf der Box laufen zu lassen. Nur weil der Author zu faul war oder nicht in der Lage ist, shell Programme zu schreiben und sed/grep zu bedienen, muss man das jetzt nicht sofort auf die Box portieren.
2. Wir haben hier in erster Linie über dropbear gesprochen, nicht über OpenSSH. Bei OpenSSH gibt es deutlich mehr Möglichkeiten, IP-s zu blocken, als bei dropbear. Wenn ich mich richtig erinnere, sogar mit internen Mitteln. OpenSSH anstatt dropbear zu verwenden kann man zwar auch, es stellt sich aber wiederum die Frage, ob es dann für eine arme Box zu viel wird.

Bzg. Attaken letzte Zeit. Ja, die haben sich wieder vermehrt. Das beobachte ich auch. Die Frage ist nur, wie willst du sie blocken? Alle Logauswerte/Block-Programme nutzen meistens iptables als Instrument zum blocken. iptables kann man zwar für die Box auch bauen und es funktioniert auch, ich persönlich finde es aber auch schon etwas oversized.

Zusammenfassend: Um deine belange zu erfüllen, muss man wahrscheinlich Python + OpenSSH + iptables auf der Box haben. Das mag ja alles funktioneren, wäre es aber nicht einfacher, den Port von 22 nur zu verlegen?

MfG

Theradur schrieb:

Ich hab letzte Nacht vergessen SSH zu deaktivieren und heute morgen war das Logfile einfach mal übervoll.

Zum Vergrößern anklicken....

Wenn Du sshd auf deiner Box hast, dann kannst Du auch sshguard ( http://freetz.org/ticket/1270 ) benutzen.
Aus http://www.sshguard.net/docs/man/sshguard/1_5/ :

ao schrieb:

Geht das mit dem o.g. sshguard und /etc/hosts.allow?

Zum Vergrößern anklicken....

Nein. Z. Zt. kann sshguard mit folgenden Anwendungen benutzt werden:
Evt. sind die Entwickler von sshguard bereit Wünsche zu erfüllen: