Warnung: ssh-scans mehren sich!

[Reiner]

Hi,

ich wollte hier mal eine Warnung geben!
In den letzten Tagen mehren sich bei uns auf allen im Internet verfügbaren Servern heftige Attacken auf SSH.
Dabei werden Usernamen durchgetestet. Dann wird versucht, das PW von root zu treffen und dann gibt es noch einen kurzen Portscan (wahrscheinlich um festzustellen, ob sshd verschoben wurde).

Kann das jemand bei seinem Server bestätigen?
(/var/log/messages)

Mir scheint das ein Wurm o.ä. zu sein, da die Angriffe bei uns bisher aus China, Panama und von Schlund kamen.

Gruß
Reiner

[wahsaga]

hi,

Mir scheint das ein Wurm o.ä. zu sein, da die Angriffe bei uns bisher aus China, Panama und von Schlund kamen.

Also allesamt aus der Dritten Welt.

scnr
wahsaga

[Sven Rautenberg]

Moin!

In den letzten Tagen mehren sich bei uns auf allen im Internet verfügbaren Servern heftige Attacken auf SSH.
Dabei werden Usernamen durchgetestet. Dann wird versucht, das PW von root zu treffen und dann gibt es noch einen kurzen Portscan (wahrscheinlich um festzustellen, ob sshd verschoben wurde).

Gähn... sowas ist doch normal.

Und sinnlos, wenn man vernünftige Maßnahmen ergriffen hat:
1. Immer alle Sicherheitsupdates für den sshd und seine Libs einspielen.
2. Vernünftige Passworte (insbesondere in der Länge!) wählen. Oder:
3. Auf Passworte ganz verzichten und nur RSA-Schlüssel einsetzen (macht die Benutzung außerdem angenehmer).

Und ansonsten: Gerne auch mal bei den Providern melden, die da als Angriffsbasis genutzt werden. Zusammen mit entsprechenden Logfile-Auszügen. Insbesondere deutsche Provider unternehmen da auch was.

- Sven Rautenberg

[Reiner]

Hi,

In den letzten Tagen mehren sich bei uns auf allen im Internet verfügbaren Servern heftige Attacken auf SSH.
Dabei werden Usernamen durchgetestet. Dann wird versucht, das PW von root zu treffen und dann gibt es noch einen kurzen Portscan (wahrscheinlich um festzustellen, ob sshd verschoben wurde).

Gähn... sowas ist doch normal.

Wenn Dich das Thema langweilt, warum antwortest Du dann?
Um Dein Wissen zur Schau zu stellen?

Und sinnlos, wenn man vernünftige Maßnahmen ergriffen hat:

1. Immer alle Sicherheitsupdates für den sshd und seine Libs einspielen.

Machen wir!

2. Vernünftige Passworte (insbesondere in der Länge!) wählen. Oder:

Machen wir!

3. Auf Passworte ganz verzichten und nur RSA-Schlüssel einsetzen (macht die Benutzung außerdem angenehmer).

Machen wir!
Ansonsten: Super Tip! Insbesondere ohne die Aufforderung an Newbies, bei Laptops dann möglichst nur verschlüsselte Partitionen einzusetzen. In meinem Fall könnte (m)ein geklautes Laptop die ganze Firma in den Ruin stürzen!

Und ansonsten: Gerne auch mal bei den Providern melden, die da als Angriffsbasis genutzt werden. Zusammen mit entsprechenden Logfile-Auszügen. Insbesondere deutsche Provider unternehmen da auch was.

Habe ich getan!

Ich frage mich ernsthaft, was Dein Posting sollte bzw. sinnvolles beitragen sollte.

Ich hatte weder Panik noch ein Sicherheitsproblem.
Stattdessen wollte ich nur darauf aufmerksam machen, daß die Scans in letzter Zeit _extrem_ gehäuft auftreten und andere hiermit warnen.

Gruß
Reiner

[Sven Rautenberg]

Moin!

Ich frage mich ernsthaft, was Dein Posting sollte bzw. sinnvolles beitragen sollte.

Immerhin hatte ich Anregungen gegeben, wie man solchen Scans gelassen entgegensehen kann. Gefahr besteht nämlich nur, wenn

• der sshd angreifbar ist, oder
• ein Useraccount angreifbar ist durch zu einfache Passworte bei bekanntem Usernamen.

Ich hatte weder Panik noch ein Sicherheitsproblem.
Stattdessen wollte ich nur darauf aufmerksam machen, daß die Scans in letzter Zeit _extrem_ gehäuft auftreten und andere hiermit warnen.

Damit aber erzählst du nichts neues. Solche Scans gibt es schon immer. Man muß die Gefahr also in Betracht ziehen, sogar ernst nehmen.

Aber dein Posting enthält außer dieser Warnung ja nichts, was man gegen diese Scans tun könnte. Auf SSH verzichten und nur noch lokal an der Konsole arbeiten ist vermutlich keine brauchbare Alternative, oder?

- Sven Rautenberg

[Manuel B.]

Hi,

Immerhin hatte ich Anregungen gegeben, wie man solchen Scans gelassen entgegensehen kann. Gefahr besteht nämlich nur, wenn

• der sshd angreifbar ist, oder
• ein Useraccount angreifbar ist durch zu einfache Passworte bei bekanntem Usernamen.

Das stimmt so nicht.
Ein Angriff kann im extremfall die Bandbreite ausreizen und somit den Server lahmlegen. Und da helfen dir weder Sicherheitsupdates, noch gesperrte Ports.

[Sven Rautenberg]

Moin!

Immerhin hatte ich Anregungen gegeben, wie man solchen Scans gelassen entgegensehen kann. Gefahr besteht nämlich nur, wenn

• der sshd angreifbar ist, oder
• ein Useraccount angreifbar ist durch zu einfache Passworte bei bekanntem Usernamen.

Das stimmt so nicht.
Ein Angriff kann im extremfall die Bandbreite ausreizen und somit den Server lahmlegen. Und da helfen dir weder Sicherheitsupdates, noch gesperrte Ports.

Richtig, aber ein DoS ist nochmal was ganz anderes, als ein SSH-Accountscan.

Die zu beobachtenden SSH-Scans dienen offenbar einzig und allein dazu, durch Masse an gescannten Systemen genau die ausfindig zu machen, bei denen vorgegebene Accountnamen und simple Passworte benutzt werden.

Wäre hingegen ein DoS beabsichtigt, wäre erstens überhaupt kein aktiver Service notwendig, und man würde zweitens nicht nur für die zu beobachtende kurze Zeit scannen. Meine Beobachtungen haben bislang das Muster "ein Account pro Sekunde, Dauer zwischen 30 Minuten und 3 Stunden" bei diesen Scans gezeigt. Das ist alles andere als ein DoS. Es sei denn, das reizt die Bandbreite schon komplett aus - dann wäre das allerdings ein unbeabsichtigter Nebeneffekt.

- Sven Rautenberg

[Reiner]

Richtig, aber ein DoS ist nochmal was ganz anderes, als ein SSH-Accountscan.

Die zu beobachtenden SSH-Scans dienen offenbar einzig und allein dazu, durch Masse an gescannten Systemen genau die ausfindig zu machen, bei denen vorgegebene Accountnamen und simple Passworte benutzt werden.

Wäre hingegen ein DoS beabsichtigt, wäre erstens überhaupt kein aktiver Service notwendig, und man würde zweitens nicht nur für die zu beobachtende kurze Zeit scannen. Meine Beobachtungen haben bislang das Muster "ein Account pro Sekunde, Dauer zwischen 30 Minuten und 3 Stunden" bei diesen Scans gezeigt. Das ist alles andere als ein DoS. Es sei denn, das reizt die Bandbreite schon komplett aus - dann wäre das allerdings ein unbeabsichtigter Nebeneffekt.

das sehe ich anders!
Beides ist eher richtig. Ich glaube, daß der "Sinn" ist, Rechner zu übernehmen und damit eventuell Krieg (u.U. im wahrsten Sinne) per DoS zu führen. Mit entsprechender Anzahl an Rechnern steht Dir ein Parabolspiegel zur Verfügung, mit dem man gezielt sehr große Systeme lahmlegen kann, ohne selbst in Verdacht zu geraten.

Insofern (auch wenn ich keine Tips gegeben habe) bleibe ich dabei, daß meine Warnung gerechtfertigt war, denn nur weil ich weiß, worauf ich achten sollte, kann jemand anderes, dem das nicht bewußt ist, zur Gefahr werden.

Viele Grüße,
Reiner

[Sven Rautenberg]

Moin!

Beides ist eher richtig. Ich glaube, daß der "Sinn" ist, Rechner zu übernehmen und damit eventuell Krieg (u.U. im wahrsten Sinne) per DoS zu führen.

Na und?

Was hinterher mit dem Server geschieht, ist vermutlich vielfältig. Ebenso wahrscheinlich, bzw. eigentlich noch wahrscheinlicher, ist z.B. ein Warez-Tauschpunkt, oder ein Relay, um von dort aus andere Systeme anzugreifen (wenn die Spuren gut verwischt sind, kriegt man dann nur den Serverbesitzer ermittelt, aber nicht den Täter).

Insofern (auch wenn ich keine Tips gegeben habe) bleibe ich dabei, daß meine Warnung gerechtfertigt war, denn nur weil ich weiß, worauf ich achten sollte, kann jemand anderes, dem das nicht bewußt ist, zur Gefahr werden.

Deine Warnung ist ein Allgemeinplatz. "Leute, paßt alle schön auf, im Internet laufen böse Leute rum". Ok, so allgemein doch nicht, eher "Leute, paßt alle schön auf, im Internet sind Leute, die mit Standardschlüsseln eure Türen testen" - was ähnlich allgemein ist.

Natürlich ist gerechtfertigt, Pseudo-Admins, die sich bislang noch keinen Gedanken über Sicherheit gemacht haben, entsprechend aufzuklären. Allgemein, speziell und grundsätzlich. Gar kein Widerspruch dagegen.

Aber weder ist das Gefahrenpotential "heute" (nach deinem Posting) im Vergleich zu "gestern" (vor deinem Posting) irgendwie verändert, noch hat sich qualitativ irgendetwas getan durch neue, zwingend zu patchende Exploit-Möglichkeiten.

Eine Meldung der Art "In SSH ist ein böser Bug gefunden worden, und jetzt suchen schon automatisierte Bots nach der Lücke - aktualisiert sofort alle euren sshd" - die wäre ja noch sinnvoll, auch weil es dabei zeitkritisch wäre, und je schneller die Lücke gefixt ist, desto besser.

Aber nur so allgemein festzustellen, dass SSH auch gescannt wird (genauso wie vermutlich jeder andere Dienst, den ein Server anbietet), ist absolut keine Neuigkeit. Die Häufigkeit der Scans ist kein Maß für die Unsicherheit - ein einziger erfolgreicher Scan aufgrund eines Standard-Accounts mit zu simplem Passwort reicht aus. Anders herum beweisen Millionen erfolglose Scans, dass die Sicherheit offenbar doch gegeben ist.

- Sven Rautenberg

[Manuel B.]

Hi,

"ein Account pro Sekunde, Dauer zwischen 30 Minuten und 3 Stunden" bei diesen Scans gezeigt. Das ist alles andere als ein DoS. Es sei denn, das reizt die Bandbreite schon komplett aus - dann wäre das allerdings ein unbeabsichtigter Nebeneffekt.

Bei den "aktuellen" Scans hast du recht, ich selbst hatte aber shconmal das, von mir genannte, Problem.

Und ob es ein unbeabsichtigter nebeneffekt ist, war mir in dem Fall völlig wurscht ;)
Mal abgesehen davon, das ein Server mit Kundenseiten nicht mehr erreichbar war, wurde auch ne Masse Traffic verursacht, und das zu Zeiten, in denen es noch keine Server mit 100Gb Freitraffic gab. Da hab ich noch richtig geld abgedrückt für jedes GB, das verbraten wurde.

Ich will damit ja nur sagen, das solche Scans auch Server sachädigen könnne, die Sicherheitstechnscih auf dem neuesten Stand sind. Eine entsprechende Abwehr (Paketsniffer o.ä.) ist oft trotzdem nötig.

[Sven Rautenberg]

Moin!

Bei den "aktuellen" Scans hast du recht, ich selbst hatte aber shconmal das, von mir genannte, Problem.

Wenn's wirklich ein DoS war, war es aber kein Scan. Weil DoS und Scannen sich gegenseitig irgendwie ausschließen - was will man denn noch als Ergebnisse vom Scan erhalten, wenn die Kiste kaum noch antwortet?

Mal abgesehen davon, das ein Server mit Kundenseiten nicht mehr erreichbar war, wurde auch ne Masse Traffic verursacht, und das zu Zeiten, in denen es noch keine Server mit 100Gb Freitraffic gab. Da hab ich noch richtig geld abgedrückt für jedes GB, das verbraten wurde.

Man hat als Serverbetreiber keinerlei Chance, etwas gegen einen DoS-Angriff zu unternehmen.

Zwingend erforderlich ist in solchen Fällen immer die Mitarbeit mindestens des lokalen Providers, bei dem der Server steht, eventuell auch von dessen Provider, um auf den vorgelagerten Routern die bösen Pakete schon rauszufiltern und so den Traffic erst gar nicht entstehen zu lassen. Als Nebeneffekt bleibt dann auch die Leitung zu anderen Kunden frei.

Ich will damit ja nur sagen, das solche Scans auch Server sachädigen könnne, die Sicherheitstechnscih auf dem neuesten Stand sind. Eine entsprechende Abwehr (Paketsniffer o.ä.) ist oft trotzdem nötig.

Absolut richtig - nur: Gegen DoS und Scans kann man sich nicht wehren, die passieren, wenn jemand es für erforderlich hält, sie durchzuführen. Firewallregeln auf dem Server verhindern nicht den Traffic des DoS, und sie sind oftmals nicht einsetzbar gegen Scans (wobei es in meinen Augen auch vollkommen egal ist, ob eine dynamisch aktivierte Regel niemals, nach tausend, zehn oder einem einzigen erfolglosen Scanversuch irgendetwas abriegelt, weil die trotzdem möglichen Scans ja dennoch Informationen liefern - wenngleich es eben ein wenig länger dauert, die Liste durchzutesten), weil die Gruppe der erwünschten Nutzer identisch ist mit "das gesamte Internet kann es sein". Dynamische Benutzer-IP und so. Selbst der Versuch, ausschließlich das DSL-Netz der Telekom zu erlauben artet einerseits in extreme Arbeit aus (wer kennt schon den DSL-IP-Range der Telekom, der konkret benutzt wird), und hilft andererseits trotzdem nicht gegen Scans, weil sich mutmaßlich genügend Zombie-Rechner auch bei Telekom-Kunden finden lassen und dann eben scannen können.

- Sven Rautenberg

[Manuel B.]

Moin!

Bei den "aktuellen" Scans hast du recht, ich selbst hatte aber shconmal das, von mir genannte, Problem.

Wenn's wirklich ein DoS war, war es aber kein Scan. Weil DoS und Scannen sich gegenseitig irgendwie ausschließen - was will man denn noch als Ergebnisse vom Scan erhalten, wenn die Kiste kaum noch antwortet?

Da hast du recht. Was der Sinn war, ist mir auch wurscht ;) Zumindest war mein Log nach dem Angriff voll Loginversuchen per SSH

Man hat als Serverbetreiber keinerlei Chance, etwas gegen einen DoS-Angriff zu unternehmen.

Die einzige Möglichkeit ist IMO das Runterfahren des Servers. Diverse paketsniffer bieten diese Option bei einem erkannten Angriff, dessen Regeln man selbst definieren kann. Dann kann man zumindest "auf die harte Tour" den Traffic verhindern. Oft wird der Angriff dann abgebrochen, wenn die Verbindung zum Server weg ist.

Eine rechtlich bedenklich Lösung wäre der Einsatz von einem Script zum Gegenangriff. ich glaub "Stacheldraht" heisst da eins. Da werden andere rechner kontaktiert, die dieses Script installiert haben, ihnen mitgeteilt, welche IP der Angreifer hat und dann wird ein gemeinsamer Gegenangriff gestartet. In dem Fall aber schlecht, wenn der ANgreifer die IP maskiert hat und der Gegenangriff gegen den falschen Server läuft :D

[Marc Reichelt]

Hallo Reiner,

ich wollte hier mal eine Warnung geben!
In den letzten Tagen mehren sich bei uns auf allen im Internet verfügbaren Servern heftige Attacken auf SSH.
Dabei werden Usernamen durchgetestet. Dann wird versucht, das PW von root zu treffen und dann gibt es noch einen kurzen Portscan (wahrscheinlich um festzustellen, ob sshd verschoben wurde).

Kann das jemand bei seinem Server bestätigen?
(/var/log/messages)

Da findet sich bei mir zum Schlagwort "ssh" nichts - bei mir gibt's eine /var/log/auth.log.
Und die hat so wie es aussieht bis jetzt keine Einträge von irgendwelchen Programmen, die versuchen, sich auf unserem Server einzuloggen - bis auf unsere eigenen, latürnich. ;-)

Um solchen Attacken dennoch vorzubeugen, gibt es jede Menge Dinge, die man unternehmen kann:

• Login von root verhindern ("PermitRootLogin no")
• anderen Port als 22 setzen ("Port x")
• mit AllowGroups und AllowUsers die Gruppen bzw. Benutzer angeben, die sich einloggen dürfen
• sichere Passwörter

Wenn man das unternimmt und auch sonst keine unsicheren Einstellungen vorgenommen hat, ist man eigentlich mehr auf der sicheren Seite als auf der unsicheren.

Grüße

Marc Reichelt || http://www.marcreichelt.de/

[Dennis]

Hi Marc,

• Login von root verhindern ("PermitRootLogin no")

Eine schöne Sache finde ich da auch noch PermitRootLogin without-password - erlaubt den Root Login nur mit RSA-Schlüsseln, so kann man dann für Backup-Zwecke z.B. immer noch einen Root Login ermöglichen.

Wo wir schon dabei sind: Natürlich sollte PermitEmptyPasswords auf no gesetzt sein und alle nicht verwendenten Authentifizierungs-Methoden deaktiviert werden, nicht sichere Auth-Methoden sollte man natürlich gar nicht erst verwenden.

MfG, Dennis.

[fastix®]

Moin!

Kann das jemand bei seinem Server bestätigen?
(/var/log/messages)

Ich habe ähnliches. Bei werden kassische englische Vornamen und Systembenutzer durchprobiert. Da sucht jemand nach fehlkonfigurierten Systemen.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix®

[fastix®]

Moin!

Gab es nicht mal irgendwo ein Script, welches nach dem dritten fehlgeschlagenen Login-Versuch Zugriffe von der IP des Angreifers blockierte? Ich finde es einfach nicht mehr.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix®

[fastix®]

Moin!

Ich habe es wiedergefunden und zwar hier.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix®

[Julian von Mendel]

Hi,

Ich habe es wiedergefunden und zwar hier.

ergänzend möchte ich noch folgende drei Programme nennen:
DenyHosts
SSH Blocking
fail2ban

Schöne Grüße
Julian

[hh]

Wo liegt das Problem? Das dein logfile zu lang wird?
Wenn du ein Passwort benutzt, dass nicht in jedem Wörterbuch nachgelesen werden kann, solltest du dir keine Gedanken darüber machen. Zu deiner Beruhigung kannst du ja aber deinen Server auch so einstellen, dass die IP nach X anfragen für XX Minuten nicht mehr zugelassen wird. Also etwa bei 3 Fehlversuchen die IP für 30 Minuten sperren für ssh-zugang. Die meisten Skripte gehen dann automatisch zu einer anderen IP. So machen wir es zumidest bei uns, da man ja sonst die anderen interessanten log infos gar nicht mehr findet vor lauter "failed password for invalid user .... ssh2" nachrichten.

[Manuel B.]

Hi,

Kann das jemand bei seinem Server bestätigen?

Kann ich bestätigen, erst gestern wieder. IP von einem Server, der einem spanischen(?) Serveranbieter gehört. Nach einem Reboot war dann ende. Schätze, dass das Script des Angreifers abgeschalten hat, nacshdem die Verbindung weg war.

[Candid Dauth]

Heißa, Reiner,

Kann das jemand bei seinem Server bestätigen?
(/var/log/messages)

In meiner /var/log/auth.log finde ich nur pro Tag etwa einen Versuch, der sofort fehlschlägt, da versucht wird, ohne einen RSA-Schlüssel zu authentifizieren. Hier stecken höchstwahrscheinlich keine Bots dahinter, sondern ein paar neugierige, die halt mal schauen wollen, ob sie nicht rein zufällig ohne Passwort auf den Server kommen. Nichts Auffälliges also.

Ich glaube aber, dass ich mich auch ganz gut abgesichert habe: Für Benutzer meines Servers ist Public-Key-Anmeldung über die SSH Pflicht, ebenso ist nur SFTP möglich. Auf diese Weise möchte ich Bruteforce-Attacken vorbeugen. Die Systempasswörter werden eigentlich nur fürs E-Mail-Abholen verwendet, die Benutzer, die keine E-Mail-Adresse brauchen, haben also gar kein Passwort. Und wenn jemand über eine POP3-Bruteforce-Attacke ein Systempasswort herausbekommt, bringt ihm das ja nichts, außer, dass er die E-Mails abfangen kann.
Wogegen ich noch nichts unternommen habe, sind Bruteforce-Attacken auf HTTP-Login-Formular-Ebene. Hierzu habe ich auch noch keine vernünftige Möglichkeit gefunden, außer eben auf Seite der Webanwendung. Aber dadurch, dass man die Adressen der Adminbereiche nicht öffentlich (ob versteckt oder nicht) verlinkt, kann man denke ich auch schon einiges erreichen.

Gautera!
Grüße aus Biberach Riss,
Candid Dauth