Unbekannter versucht sich ständig via ssh einzuloggen

Status
Für weitere Antworten geschlossen.
Lord Kefir

Lord Kefir

König
Tach!

Bei meiner Freundin versucht sich seit geraumer Zeit ein Fremder via ssh einzuloggen. Ich denke die entsprechende Person nutzt ein Script:

/var/log/messages schrieb:
[...]
Feb 14 14:19:41 linda sshd[5578]: Invalid user yonchun from 203.236.160.38
Feb 14 14:19:41 linda sshd[5578]: Failed password for invalid user yonchun from 203.236.160.38 port 40838 ssh2
Feb 14 14:19:44 linda sshd[5580]: Invalid user yoneda from 203.236.160.38
Feb 14 14:19:44 linda sshd[5580]: Failed password for invalid user yoneda from 203.236.160.38 port 40967 ssh2
Feb 14 14:19:48 linda sshd[5582]: Invalid user yoneko from 203.236.160.38
Feb 14 14:19:48 linda sshd[5582]: Failed password for invalid user yoneko from 203.236.160.38 port 41100 ssh2
Feb 14 14:19:51 linda sshd[5584]: Invalid user yonekura from 203.236.160.38
Feb 14 14:19:51 linda sshd[5584]: Failed password for invalid user yonekura from 203.236.160.38 port 41234 ssh2
Feb 14 14:19:57 linda sshd[5586]: Invalid user yonemitsu from 203.236.160.38
Feb 14 14:19:57 linda sshd[5586]: Failed password for invalid user yonemitsu from 203.236.160.38 port41369 ssh2
Feb 14 14:20:05 linda sshd[5588]: Invalid user yonemoto from 203.236.160.38
Feb 14 14:20:05 linda sshd[5588]: Failed password for invalid user yonemoto from 203.236.160.38 port 41598 ssh2
Feb 14 14:20:10 linda sshd[5590]: Invalid user yoneyama from 203.236.160.38
Feb 14 14:20:10 linda sshd[5590]: Failed password for invalid user yoneyama from 203.236.160.38 port 41856 ssh2
[...]

Die IPs führen in der Regel zu irgendwelchen Firmenseiten. Ich frage mich nun, wer der Bösewicht ist und wie er an die IP meiner Freundin kommt (sie chattet nicht, hat kein GAIM oder sonst was drauf und ist auch in keinem Forum angemeldet).

Hat einer 'nen Tipp für mich, was ich als nächstes für Schritte unternehmen kann?!

Mfg, Lord Kefir
 
Solche Attacken sind voellig normal. Ich schaetze, dass irgendein Kid oder Virus ein Windows-Skript ausprobiert, dass einen bestimmten IP-Bereich abklappert und versucht, sich dort mit Standardnamen/Passwoertern einzuloggen. Bei mir passiert so etwas mehrmals pro Woche(grade zum Beispiel). Ist laestig, v.a., wenn die Platte nicht die leiseste ist.
Das einfachste, was Du machen kannst, ist sicherstellen, dass die Passwoerter alle sicher sind (min 8Zeichen, nicht nur Buchstaben, usw...).

Wenn es Dich wirklich nervt, schalte eine OpenBSD-Firewall davor. Dort kann man einstellen, anfragen von IP-Adressen, die sich in einem bestimmten Zeitintervall oft melden, zu sperren, ganz oder zeitweise.
 
Hm... 'ne BSD-Firewall würde mir dann doch zuviel Aufwand werden. Nervig ist das mit den Login-Versuchen schon, aber ich denke, dass die Passwörter etc. sicher genug sein sollten.

Mfg, Lord Kefir
 
@rikola:
warum gerade ne BSD-firewall? kann man das mit iptables nicht auch? oder meinst du damit das selbe?

manu
 
ich hab dass problem nicht mehr hab eine IPFire Firewall mit Guardian ob der automatisch alles blockiert was inerhalb eines gewissen zeit intervall ist.
 
Hallo
Solche Scripte (auf meist verseuchten Windows-Kisten) sind die Normalität, stellen das allgemeine Netzrauschen dar.
Um das etwas einzuschränken, kannst du den sshd auf einem anderen Port lauschen lassen.
Das hilft merklich, da die Scripte fast ausschließlich auf den Standardport zugreifen.
Du musst dann nur den relevanten Personen, die sich einloggen dürfen diesen selbstgewählten Port bekanntgeben.

Wenn du paranoid bist, dann verbiete den root-Login.
Dann muss sich auch root über einen erstellten Useraccount einloggen, und kann dann erst durch su zu root werden.

Auf meiner rein privaten Kiste verbiete ich z.B. alles was irgendwie MS oder Windows oder Winnt im User-Agent enthält, meinen Apache zu besuchen.
Das verhindert die lästigen Scripte die nach bekannten php-Lücken scannen. Abgesehen davon arbeite ich nur mit perl, php ist gar nicht installiert.
:devil:

Wie dicht du die Kiste auch machst, Scriptkiddispuren wirst du immer finden. Allein die Anzahl an Windows-Zombies ist gigantisch.

Gruß Wolfgang
 
oyster-manu schrieb:
@rikola:
warum gerade ne BSD-firewall? kann man das mit iptables nicht auch? oder meinst du damit das selbe?

manu
Ich habe mich nur noch nie mit Firewalls unter Linux auseinandergesetzt. Und mit BSD scheint das sehr einfach zu gehen.
 
das ssh ausgehorche ist normal. falls es dich nervt, mach nur publickeyauth. ist sicherer und der "angreifer/kiddie" hat keine chance. außerdem spart es dir die passwort eingabe beim einloggen. rootlogin würde ich generell abstellen.
 
saiki schrieb:
das ssh ausgehorche ist normal. falls es dich nervt, mach nur publickeyauth. ist sicherer und der "angreifer/kiddie" hat keine chance. außerdem spart es dir die passwort eingabe beim einloggen. rootlogin würde ich generell abstellen.

Hab ich da was flasch verstanden? Oder hat man(Sie) dann nicht mehr die möglichkeit von "Außen" via SSH zuzugreifen?

Ich verwende SSH ja zur "Fernwartung" :D Von Außen!
Oder sollte ich mir doch noch mal die man sshd durchlesen?

L.G Jörg
 
@joharrer vieleicht schon *g*

saiki meinte das man auch eine publik key authentifizierung nutzen kann. Dh du generierst mit (ich glaub) ssh-keygen eine key pair. Den public legst du unter ~/.ssh/authorized_keys auf allen kisten ab die du warten moechtest. Dann kannst du auf deiner kiste deinen Private Key laden und brauchst ab dem zeitpunkt kein pwd mehr einzugeben wenn du Dich auf den andern kisten anmelden moechtest.

Hoffe es hilft dir ein wenig weiter

gruss Daniel
 
Ok, klingt gut. Aber mit keygen hab ich genau 0 am hut?(
 
Falls Du nur noch Authentifizierung per public key erlaubst, kannst Du Dich nicht mehr von neuen Maschinen auf dem Rechner einloggen, weil der Schluessel dann nicht vorhanden ist! Ueberlege es Dir gut, bevor Du sshd entsprechend konfigurierst!
Ausserdem denke ich, dass dadurch der Angreifer trotzdem noch mit dem sshd in Kontakt treten muss, bevor der ihm den Zutritt verwehrt, d.h., an Deiner Log-Datei wird sich nicht viel aendern.
 
Wolfgang_1 schrieb:
Um das etwas einzuschränken, kannst du den sshd auf einem anderen Port lauschen lassen.
Das hilft merklich, da die Scripte fast ausschließlich auf den Standardport zugreifen.
Du musst dann nur den relevanten Personen, die sich einloggen dürfen diesen selbstgewählten Port bekanntgeben.
Security by Obscurity ist imho völlig falsch.

Wenn du paranoid bist, dann verbiete den root-Login.
Dann muss sich auch root über einen erstellten Useraccount einloggen, und kann dann erst durch su zu root werden.
immer! root über ssh reinlassen ist ja wie eine Einladung. Optimalerweise sollte man bei entsprechender Umgebung nur bestimmte IP - Adressen auf SSH zugreifen lassen lassen. Mit DynDNS auch für dynamische IP kein Problem, da die meisten Firewalls auch mit Hostnamen arbeiten ;).


Wie dicht du die Kiste auch machst, Scriptkiddispuren wirst du immer finden. Allein die Anzahl an Windows-Zombies ist gigantisch.
Ich habe im Netz eine Kiste, auf der die ganze Welt auf den SSH zugreifen kann, doch ich habe nicht einen Einbruchsversuch, obwohl die Kiste schon 1 Jahr und 50 Tage so da steht. Naja, manche werden von diesen "Attacken" wohl angezogen.
 
joharrer schrieb:
Ok, klingt gut. Aber mit keygen hab ich genau 0 am hut?(
man 1 ssh-keygen
Btw: Das "keygen" in dem Namen hat nichts mit serials für kommerzielle software usw. zu tun, falls du das falsch verstanden hast. Es werden lediglich keys für rsa/<andere asymmetrische kryptosysteme hier einsetzen> generiert.
 
avaurus schrieb:
immer! root über ssh reinlassen ist ja wie eine Einladung. Optimalerweise sollte man bei entsprechender Umgebung nur bestimmte IP - Adressen auf SSH zugreifen lassen lassen. Mit DynDNS auch für dynamische IP kein Problem, da die meisten Firewalls auch mit Hostnamen arbeiten ;).
Das wollte ich schon immer mal erklaert bekommen! Wenn ich eine Maschine von ausserhalb verwalten moechte, benoetige ich auf jeden Fall entweder das root-Passwort oder benutze sudo und brauche dazu das Passwort eines Users. In beiden Faellen haengt die Sicherheit des Systems doch einzig an einem Passwort, oder was uebersehe ich da? Waere fuer eine Erklaerung sehr dankbar.
 
Der Aufwand ist grösser. Bei root-Sperrung muss man sich als normaler User anmelden und dann per su root-Rechte erhalten --> Der Angreifer muss also den User-Namen haben, dessen Passwort sowie dann noch das Root-Passwort...

edit: Natürlich sollte man dem User keine sudo-Rechte geben.
 
Zuletzt bearbeitet:
Hallo
@avaurus
Mein Verschieben des Port für sshd war nicht als die alleinige Maßnahme gedacht.
Es war eher dazu gedacht, die Logfiles zu verkleinern, bzw. eine weitere Hürde beim Loginversuch zu stellen.
Login nur über pubkey ist auf jeden Fall eine gut Ergänzung.

Wenn du auf verschiedene Maschinen gehen musst, musst du deinen Key eben mitnehmen.

Betreff sudo sollte zumindest auf Rechte ohne Passwort verzichtet werden.
Wer zweimal versuchen muss ein Passwort zu knacken, hinterlässt dabei genug Spuren, die jeder nicht allzu blinde Admin erkennen sollte.

Gruß Wolfgang
 
Phorus schrieb:
edit: Natürlich sollte man dem User keine sudo-Rechte geben.

also dem muss ich jetzt mal widersprechen. bei richtiger konfiguration kann der benutzer sehr wohl sudo-rechte bekommen. annahme es ist nur publicauth gestattet für user. root login verboten. selbst wenn ein einbrecher den ssh knackt, was bei publicauth dann nur ein softwarebug sein kann oder glück ;), muss er beim sudo immernoch das userpasswort eingeben. und das dann zu finden sollte auch ne weile dauern.

und wenn man sudo noch vernünftig abgesichert hat in der sudoers, kann ein kompromitierter user garnichts mehr. wenn das root passwort nicht gesetzt ist, wird es für einen angreifer sehr sehr schwer irgendein rootkit in stellung zu bringen. das wird ihn ne weile beschäftigen. dann aller paar minuten per cron nen rootkitscanner laufen lassen und es ist alles kein problem :)


sudo ist definitiv kein sicherheitsrisiko, so lange man ne man-page lesen kann...
 
noch sicherer wird die fernwartung per ssh wenn du portknocking verwendest. dabei meldet sich der ssh-daemon nur am definierten port, nachdem vorher eine zeitlich definierte signalfolge eingetroffen ist. alles andere lässt ihn stumm. somit erkennen die scanner einen nicht belegten port.
 
Perlscripte zum blocken...

Um Bruteforce Attacken zu blockieren gibts perlscripte, mit denen man z. b. nach dem dritten Versuch die IP blocken kann.
http://www.pettingers.org/code/sshblack.html

Gibts aber auch noch ein anderes script. Name fällt mir jetzt nicht ein.
Ich verbiete auch den Root-ssh Login, und kann mich nur mit einem Benutzer einloggen. Muss dann auch mit su wechseln.
Kam mir am Anfang kompliziert vor, aber nachdem ich rootkits auf verschiedenen Servern hatte, und alles neu machen musste, sah ich das als wichtig an.

gruss
 
Status
Für weitere Antworten geschlossen.

Ähnliche Themen

3 Wege zur Authentifizierung?

Fail2Ban won't ban

sftp mit vsftpd und mysql

localhost versucht ssh Verbindung alle fünf Minuten

Samba 4 Gast Zugang unter Ubuntu funktioniert nicht

Zurück
Oben