Einbruchversuche über SSH (dropbear)

[_pepe_]

Hallo,

ich habe bei mir den SSH Server dropbear am laufen. Über eine virtuelle IP und Portweiterleitung ist der SSH Zugang auch über das Internet erreichbar. Wenn ich mir nun meinen syslog anschauen, finde ich jeden Tag mehrere fehlgeschlagene Einlogversuche. Heute hat's ein Server aus China sogar 45 min lang versucht rein zu kommen.

Oct 12 08:10:23 fritz authpriv.warn dropbear[4067]: login attempt for nonexistent user from 58.223.251.3:59612
Oct 12 08:10:24 fritz authpriv.info dropbear[4067]: exit before auth: Disconnect received
Oct 12 08:10:28 fritz authpriv.info dropbear[4069]: exit before auth (user 'root', 1 fails): Disconnect received
Oct 12 08:10:32 fritz authpriv.warn dropbear[4070]: login attempt for nonexistent user from 58.223.251.3:35910
Oct 12 08:10:33 fritz authpriv.info dropbear[4070]: exit before auth: Disconnect received

Ist das bei Euch auch so, dass da permanet jemand anklopft zum hacken ?
Soll man sich da Sorgen machen ?

Ich habe mir die Sourcen von dropbear noch nicht angeschaut, aber gibt's da keine Möglichkeit (Patch), dass man eine IP-Adresse die es mehrmals vergeblich versucht, für einige Zeit auszusperren. Evtl. würde ein Delay von mehreren Sekunden zwischen 2 Einlogversuchen das Ganze auch schon etwas entspannen.

Gruss pepe

 

[sterkel]

Das sind typische Login-Scans, die eiern wohl bei jedem ab und zu durch. Wenn man ein gutes Passwort hat, müllen einem diese Klapsköpfe also nur die Logfiles zu. Dagegen gibt es den sshdfilter: http://www.sshdfilter.org/ , ich selbst habe die dropbear-Variante aber noch nicht getestet.
Probiers aus: http://www.csc.liv.ac.uk/~greg/sshdfilter-1.4.3.2-dropbear.tar.gz

 

[kriegaex]

Mit Perl und iptables als Anforderungen wird man sich da schwer tun. Wie wäre es mit einem Knock-Daemon? Knock gibt es als Paket im DS-Mod. Oder einfach entspannen im Gedanken an das gute laaaange Paßwort. Bei mir sieht das auch oft ähnlich aus im Log.

 

[_pepe_]

vielen Dank für eure Antworten

@sterkel
Hab mir das sshdfilter runtergeladen. Ich werde mich mal einlesen in die Funktion/Installation/Konfiguration des Filters, bin allerdings nicht so fit im Scripten lesen, evtl. ist der knockd leichter zu konfigurieren.

@kriegaex
Ich hatte den knockd brereits mit reinkompiliert, nur noch nicht gestartet gehabt (war deshalb auch nicht in der Signatur) -> leere Anzeige für die knockd.conf. Die Suche nach knockd hier im Forum war auch nicht sehr ergibig. Nach dem Starten des knockd war die knockd.conf mit sinnvollen Werten gefüllt. Damit kann ich schon mal was anfangen. Jetzt muss ich wohl noch suchen wie ich den SSH Port 22 ein/ausschalten kann (IPTables). Einziger Nachteil ist, dass der Zugriff von der Arbeit aus durch die Firmen-Firewall (aktuell Tunnel über 443) dann nicht mehr geht. Evtl. kann man ja auch die IP der Firma bei der FB freischalten. Die Suchfunktion wird schon was passendes ausspucken

pepe

 

[donpepe]

Bei mir wird auch versucht auf alle 3 Fritzboxen zurückzugreifen ich habe nen key ales Sicherheit, konnte sogar einen GegenAngriff starten und habe vollen root zugriff auf den Angeifer bekommen (root,admin) habe ihn dann runtergefahren ( den rechner) deitdem ist er offline (dyndns)
abertrotzdem habe ich überlegt den ssh Port zu ändern, oder mit knock zu arbeiten, aber für knock fehlt mir noch der support über Putty, bzw Windows...
puh bin voll gute N8

 

[frank_m24]

Hallo,

konnte sogar einen GegenAngriff starten und habe vollen root zugriff auf den Angeifer bekommen (root,admin) habe ihn dann runtergefahren ( den rechner) deitdem ist er offline (dyndns)

Na toll, stellst du einfach so dem Schäuble den Computer aus ... ne, ne, ne ...

Viele Grüße

Frank

 

[Tarnkappe]

abertrotzdem habe ich überlegt den ssh Port zu ändern, oder mit knock zu arbeiten, aber für knock fehlt mir noch der support über Putty, bzw Windows...
puh bin voll gute N8

Port ändern kann eigentlich nie schaden. Bei mir ist der dropbear nach außen mit einem Port jenseits der 30000 freigegeben. Laut Logdatei hab ich dadurch Ruhe ;-)

 

[_pepe_]

@donpepe
habe ein Tool für Windows gefunden, das unter Cygwin bzw. mit einer DLL davon funktioniert. Die Tests waren erfolgreich.
http://blog.roothell.org/archives/146-Portknocking-Tools-Teil-1-knockd.html

Hab noch ein zweites Tool gefunden, bei dem soll man sogar noch gleich ein Programm starten können.
http://doorman.sourceforge.net/KNOCK.HTM

Der einzigen Nachteil den ich bei knockd sehe ist das Problem durch Firewalls durchzukommen. Port ändern, wie auch von Tarnkappe erwähnt, ist wohl die bessere Lösung.

 

[Igi2003]

Hallo zusammen,
da hab ich euch mal nen kleinen Tip, und zwar SSH über einen anderen öffentlichen Port freizugeben, z.B. einfach die 80, 90, oder 99 vor den Port. Anstatt SSH über Port 22 nach aussen freizugeben, die 9922. Das Webinterface z.B. auf 9980, das ds-mod Webinterface auf 9981. Auf diesen hochen Ports wird sehr sehr selten nach SSH, FTP, oder HTTP Protokoll gescannt.

Mfg Igi

 

[frank_m24]

Hallo,

das Problem mit dem Verlagern von Ports ist aber, dass diese in Firewalls oft nicht ausgehend freigegeben sind. Die Standard-Ports oder Ports unterhalb von 1024 gehen oft noch, alles andere nicht.

Viele Grüße

Frank

 

[u.g]

Gibts beim dsmod sowas wie /etc/hosts.allow und hosts.deny?

Dann könntet ihr doch -sofern nur wenige bestimmte IPs erlaubt sind- diese in hosts.allow eintragen ... ?

Auf einem Suse-Linux-PC hatte ich mir mal ein Script gebastelt, was die Log-Datei durchsucht, und bei zuviel Fehllogins diejeweilige IP in hosts.deny einträgt.

 

[hermann72pb]

Die Idee ist nicht so schlecht. Ich glaube schon, dass es irgendwie möglich ist hosts.allow/deny-Dateien auf der Box zu verwenden. Wenn du es mal gemacht hast, bastele doch ein Skript für Fritz!Box. Die Unterstützung wirst du hier kriegen, wenn du Fragen hast. crond gibt es unter ds-mod bereits, sodass man dein Skript sagen wir alle 2-3 Minuten ausführen könnte. Ich würde allerdings die Adressen nicht permanent sperren, sondern für die nächsten 24 Stunden oder so. Damit wird deine "deny"-Datei dann nicht übermässig groß und wenn die dynamische Adresse vom "Feinden" zum "Freunden" kommt, wird sie dann akzeptiert.

MfG

 

[RalfFriedl]

Der wirksamste Schutz ist ein vernünftiges Paßwort. Dann sind die Einträge im Protokoll einfach nur lästig.

Das Verlegen auf einen anderen Port kann man zusätzlich machen, aber nicht als einzige Sicherheitsmaßnahme.

Interessanterweise werden bei diesen SSH Scans in den meisten Fällen (anscheinend auch hier) nicht Anmeldungen als root versucht, sondern als andere Benutzer. Vielleicht gibt es irgendwelche Systeme, bei denen Benutzer mit Standard-Paßwörtern angelegt werden, und diese Systeme werden von den Angreifern gesucht.

Es könnte interessant sein, den SSH Server so abzuändern, daß er den Benutzernamen und das Paßwort ausgibt, das bei einem Anmeldeversuch verwendet wurde.

 

[masterSLZ]

*seufz* Der wichtigste und absolut einzig wirklich sinnvolle Punkt wurde hier bisher unterschlagen:

Dafuer sorgen, das immer eine aktuelle SSH(d) Version (+OpenSSL und sonstige dependencies) laeuft, die keine (bekannten) remote Exploits hat/haben.

Im Falle von einer Fritzbox eben immer eine aktuelle dropbear Version.
[Ueber die Wahrscheinllichkeit eines Scans auf dropbear/mips exploits will ich hier mal nicht eingehen, hier geht es um das Prinzip ]

Alle andere (Port verschieben, Access Listen etc.) ist aus schon im Thread erwaehnten Gruenden zum Teil recht halb-gar.

Exploits sind der Hauptgrund fuer Einbrueche, Admins die sich um Updates nicht scheren sind das groesste Sicherheitsproblem in dieser IT Welt.
Dannach kommen dann die bereits erwaehnten unsicheren/default Passwoerter - am Besten nach Moeglichkeit SSH-Keys only und/oder OTP.

Ansonsten sind die reinen Scans harmlos, gerade auf Embedded Devices wie Fritzboxen bringt alles andere ("Gegenmassnahmen", filter, knockd, sonstwas) hoechstens noch hoehere CPU Last, was sinnlos ist.

Und spaetestens wenn ich hier was von "Gegenangriffen" lese, krig ich spontanten Anfall - geht's noch? Schuss nich gehoert?

bye
-slz

 

[_pepe_]

Ich habe nun meinen SSH Zugang auf einen Port oberhalb von 30000 gelegt und nun scheint Ruhe zu sein.

@u.g
Das mit dem Script gibt's für dropbear schon (siehe Post von sterkel mit Verweis auf sshdfilter http://www.ip-phone-forum.de/showpost.php?p=958322&postcount=2)

@frank_m24
Ich habe bei mir den 443 noch für SSH verwendet und komme damit sogar durch die Firewall in der Firma

@masterSLZ

am Besten nach Moeglichkeit SSH-Keys only und/oder OTP

Was braucht man zu einem OTP (one time password) damit man das auf der Fritzbox verwenden kann ?

 

[masterSLZ]

Oehm, auf einer Fritzbox duerfte OTP schwierig werden wegen der ueblichen Platzenge, wenn ueberhaupt.

Aber wer mit SSH Keys keine Probleme hat - das kann dropbear.
Halt nur nicht vergessen, dann die Password-logins mit '-s' glaube ich wars auszuschalten.

Meine Anmerkungen waren eher allgemein gehalten und nicht 100% auf dropbear/Fritzbox bezogen.

bye
-slz

 

[kriegaex]

Ich habe vor ein paar Wochen mal OPIE - genauer: opielogin - mit telnetd als Login-Methode ausprobiert, ging gut. Aber um es mit Dropbear zum Laufen zu kriegen, braucht man einen Kernel mit PAM. Erst seit kurzem unterstützt wohl auch die Busybox PAM, Dropbear hat da auch irgendwas. Steht mit mittlerer oder niedriger Prio auf unserer To-Do-Liste. Daß es mit Telnet schon mal geht, ist für Notfälle, wenn man unbedingt mit telnet ran muß aus dem Internet-Café, sehr praktisch. Man kann zwar die Session mitloggen - macht meistens wenig aus - und auch das eigegebene OTP, aber das nützt nichts, weil das PW ja prinzipbedingt beim nächsten Mal ein anderes ist, der Angreifer kann also kaum Kapital daraus schlagen, da müßte er schon gleich die aktuelle Sesison klauen.

OPIE mit Dropbear wäre dann die Kür. Irgendwann schaue ich das nochmal an. Platzbedarf kenne ich momentan nicht, mal sehen.

 

[ao]

Gibts beim dsmod sowas wie /etc/hosts.allow und hosts.deny?

Dann könntet ihr doch -sofern nur wenige bestimmte IPs erlaubt sind- diese in hosts.allow eintragen ... ?

Auf einem Suse-Linux-PC hatte ich mir mal ein Script gebastelt, was die Log-Datei durchsucht, und bei zuviel Fehllogins diejeweilige IP in hosts.deny einträgt.

Das sind typische Login-Scans, die eiern wohl bei jedem ab und zu durch. Wenn man ein gutes Passwort hat, müllen einem diese Klapsköpfe also nur die Logfiles zu. Dagegen gibt es den sshdfilter: http://www.sshdfilter.org/ , ich selbst habe die dropbear-Variante aber noch nicht getestet.
Probiers aus: http://www.csc.liv.ac.uk/~greg/sshdfilter-1.4.3.2-dropbear.tar.gz

Ließe sich das in den Freetz-Trunk einbauen?

 

[Silent-Tears]

Das tool benötigt für seine Regeln iptables. Allerdings sind in den headern der dropbear-Dateien einige Werte drin, mit denn man "spielen" kann.

Anderer Variante ist die Passwortfreie Version des Dropbear. Nur durch Austausch der korrekten Schlüssel klappt das. Somit hat man ein zugemülltes Logfile, mehr aber auch nicht.

Die allereinfachste MEthode ist das verschieben des listening port für den dropbear. Dann nämlich passiert bei den Scans gar nichts mehr.

 

[MrMcCrash]

Um noch einmal auf das Thema OTP zu kommen:

Wäre es denn nicht möglich, eine Nebenstelle einzurichten, die man von einer in der Box hinterlegten Nummer anruft (Handy z.b.), eine Pin eingibt und dann einen zufällig erzeugten Teil eines Passworts angesagt bekommt? Dieser wiederum mit einem geheimen Teil zusammen könnte als Passwort für den Benutzer gesetzt werden. Das ganze evtl. auch noch zeitlich beschränkt, z.b. 5min ab Anruf, dann wird der User wieder gesperrt oder SSH beendet. Man kann das auch noch weiter spinnen und zusammen mit dem zufälligen Teil auch noch eine "TAN" aus einer beiden Seiten bekannten liste abfordern. Damit liesse sich das Problem von besonders aufmerksamen Zeitgenossen recht elegant umgehen.

Das ganze sollte sich doch mit Mitteln aus dem DS-mod/Freetz realisieren lassen, oder? DTMF und speex waren afaik drin, alles weitere dürfte mit ein "paar" Zeilen Shell-Code erledigt sein.

Wenn ich dann nicht noch so unendlich faul wäre, würde ich das gleich mal implementieren :? :lamer:

_.-=: MFG :=-._