Server hacked, Angriffe auf SSH

[Baer]

Hallo,

ich dachte immer mein Server ist Sicher, fail.
Heute bekam ich die Mail von Strato, dass mein Server scheinbar gehacked wurde und Angriffe auf andere SSH startet.

Auszug aus der Mail:

hiermit informieren wir Sie darüber, dass Ihr Server (XXXXXX) mit dem Hostnamen XXXXXX für Hack-Attacken über das SSH-Protokoll missbraucht wird. Hierauf haben uns Dritte aufmerksam gemacht, deren Systeme attackiert worden sind.



<<<<<<<<<<<<< Auszug aus eingereichten Log-Files >>>>>>>>>>>>



Jan 26 12:40:48 OutpostNUE01 sshd[14414]: Did not receive identification string from XXXXXX

Jan 26 20:14:11 OutpostNUE01 sshd[18414]: Failed password for root from XXXXXX port 52284 ssh2

Jan 26 20:14:14 OutpostNUE01 sshd[18416]: Failed password for root from XXXXXX port 52518 ssh2

Jan 26 20:14:17 OutpostNUE01 sshd[18418]: Failed password for root from XXXXXX port 52717 ssh2

Jan 26 20:14:21 OutpostNUE01 sshd[18420]: Failed password for root from XXXXXX port 52917 ssh2

Jan 26 20:14:24 OutpostNUE01 sshd[18422]: Failed password for root from XXXXXX port 53121 ssh2

Jan 26 20:14:27 OutpostNUE01 sshd[18424]: Failed password for root from XXXXXX port 53309 ssh2



<<<<<<<<<<<<< Ende des Auszuges >>>>>>>>>>>>


Wir fordern Sie hiermit auf, Ihren Server eingehend zu untersuchen, Gegenmaßnahmen zu ergreifen und uns über diese per E-Mail zu informieren.

Bin nun etwas ratlos.
Das System ist ein Strato VServer mit Opensuse 10.3 (ja ich weiß allerdings ist ein Update auf die neue Version leider nicht möglich).

Hab ich eine Chance den Server wieder abzusichern ohne ihn neu aufzusetzen?

Die üblichen Sicherheitsvorkehren hatte ich getroffen (SSH Port, Protokoll ändern, Root Login etc etc.)

Hab leider nicht die Chance Momentan auf den Server zu kommen, da auf der Arbeit...
Root Passwort hab ich soeben über Strato ändern lassen.

Ich bitte um eure Hilfe

Gruß

 

[DjTom-i]

Lücke lokalisieren, Daten sichern, neu installieren mit einem aktuellen OS, Daten zurückspielen.

Selbst machen oder wenn du es nicht kannst kann das auch ein Dienstleister für dich gegen Bares übernehmen.

Kommt beides nicht in Frage solltest du den Server abschalten.

 

[schnoog]

Die Frage ist, wie der Angreifer auf Deinen Server kam.
Meist ist das ja nicht via ssh, sondern über irgendwelche veraltete Software mit Lücken oder unsichere php-Skripte o.ä.

Zuerst solltest Du mal die üblichen Verdächtigen abklappern. Greppe z.B. mal in den Logs der Indiaers nach der IP Adresse des angegriffenen Servers.

Ohne zu wissen wie besagter Angreifer auf Dein System gekommen ist, ist IMO die einzig passable Lösung das System neu aufzusetzen.

Andere Frage: OpenSuSe 10.3 ist nun ja schon Museumsreif. Biete Strato überhaupt neuere Versionen von OpenSuSe zur Installation an?

 

[Baer]

Ja es wird von Strato die Version 11.1 mit und ohne Plesk Installation angeboten.

Werde mir aber wohl Debian installieren und Webmin drauf machen. Das wird wohl die bessere Variante sein denk ich.

Ich habe keine IP von dem Dritten der sich bei Strato gemeldet hat.
Ich hab nur die Info aus der Mail, dass es auf andere SSH Ports von Dritten Angriffe gibt, mehr leider nicht.

 

[Joe User]

Ja es wird von Strato die Version 11.1 mit und ohne Plesk Installation angeboten.

Auch 11.1 und in Kürze auch 11.2 steht/stehen bereits im Museum...

http://en.opensuse.org/Lifetime

 

[PapaBaer]

Sicherheit ist ein Gesamtkonzept und benötigt eine Menge KnowHow. Vor allem ist es mehr, als irgendwelche HowTos abzutippern und den ssh-Port umzulegen. Leider merken das viele immer erst, wenns knallt.

So gehts weiter:

- Image vom System machen
- Server vom Netz (!!!)
- Die Sicherheitslücke im Image finden (alte Software, Scripte, ... alles kann in Frage kommen)
- System neu aufsetzen und Lücke dabei fixen
- In Zukunft Updates einspielen und ständig auf neue Sicherheitslücken achten

Ein System mit nem prähistorischen Suse kann nicht sicher sein.

 

[d4f]

Eine der wichtigen Fragen ist ob dein Server selbst kompromittiert wurde oder 'nur' ein Webspace respektiv nicht-privilegierter Account.

 

[Joe User]

@d4f: In Zeiten ungepatchter local-root-Exploits ist das völlig unherheblich...

 

[d4f]

In Zeiten ungepatchter local-root-Exploits ist das völlig unherheblich

Ich gehe mal davon aus da es ein vServer ist dass der Fehler in der RDS-Implementierung sowie in der 32bit Kompatibilitaetsumgebung im 64bit-Kernel beide fixed sind.
Bleiben noch angreifbare Programme wie proftpd.

Ich kenne jetzt keinen Webhoster der bei Exploit der veralteten Joomla-Version und Infizierung des Webspaces mit einer Skript- oder Programmdatei (Spam, Flooding, Bruteforce, ...) die ganze Hostmachine respektiv das Cluster neu installiert

 

[Joe User]

Dafür kenne ich mehrere ISP/Hoster die durch solche Nachlässigkeiten ganze Hostmaschinen und mindestens einer so gar die halbe Serverfarm verloren haben. Drei der ISP/Hoster landeten damit gar in der Presse, weil sie trotz mehrfacher unabhängiger Hinweise nicht zeitnah und angemessen reagiert haben. Einem der ISP/Hostet hat es zudem das "Genick gebrochen".

Und was LREs betrifft, so darfst Du Dir gerne mal die entsprechenden Policies von Linux, OpenBSD und Apple ansehen, denn in bei allen Drei werden LREs als "unwichtig" eingestuft. LREs werden dort also nur gefixt, wenn irgendein Core-Dev irgendwann mal Lust dazu hat, egal ob die Community bereits Patches dafür hat oder nicht. In diesem Punkt ist Microsoft mal als gutes Beispiel anzuführen, wo solche Fehler umgehend untersucht und gefixt werden. Lediglich die QA ist bei Microsoft manchmal etwas zu träge, aber sie arbeitet immerhin.

Von veralteter und verbuggter Systemsoftware oder dem Userland fange ich gar nicht erst an...

 

[ChrisServer]

Dafür kenne ich mehrere ISP/Hoster die durch solche Nachlässigkeiten ganze Hostmaschinen und mindestens einer so gar die halbe Serverfarm verloren haben. Drei der ISP/Hoster landeten damit gar in der Presse, weil sie trotz mehrfacher unabhängiger Hinweise nicht zeitnah und angemessen reagiert haben. Einem der ISP/Hostet hat es zudem das "Genick gebrochen".

Welche waren denn das? Hab ich gar nicht mitbekommen...

 

[d4f]

In diesem Punkt ist Microsoft mal als gutes Beispiel anzuführen, wo solche Fehler umgehend untersucht und gefixt werden.

Ja zumals die Stuxnet-Luecken welche Microsoft 1.5 Jahre bekannt waren sind ein gutes Beispiel dafuer dass Microsoft bedeutend schneller reagiert als die GNU/Linux Community welche knappe 24 Stunden brauchte um einen Fix fuer den Overflow im 32bit-Kompatibilitaetslayer zu entwickeln.



Im Hosting-Bereich muss man mit gewissen Kompromissen zwischen Sicherheit und Machbarkeit leben. Der Hoster kann nicht jede Benutzerinteraktion manuell kontrollieren respektiv ein Duzend Machinen neu installieren wenn ein Darkmailer mittels FTP hochgeladen wurde

Mir ist uebrigens "LRE" nicht gelaufig und Google respektiv Wikipedia in diesem Kontext auch nicht. Du redest weder von einem MAN-Netzwerk noch vom "Individuals with Disabilities Education Act"

 

[Joe User]

Ja zumals die Stuxnet-Luecken welche Microsoft 1.5 Jahre bekannt waren

Quelle für die 18 Monate?

http://www.golem.de/1012/80357.html

sind ein gutes Beispiel dafuer dass Microsoft bedeutend schneller reagiert als die GNU/Linux Community welche knappe 24 Stunden brauchte um einen Fix fuer den Overflow im 32bit-Kompatibilitaetslayer zu entwickeln.

Den Teil mit der QA hast Du gelesen? Und weisst Du überhaupt wie komplex die QA bei Microsoft sein muss? Wie komplex ist die QA bei Linux oder OpenBSD?

Der Hoster kann nicht jede Benutzerinteraktion manuell kontrollieren respektiv ein Duzend Machinen neu installieren wenn ein Darkmailer mittels FTP hochgeladen wurde

Es geht und gute Hoster tun dies auch.

<flame on>

Mir ist uebrigens "LRE" nicht gelaufig und Google respektiv Wikipedia in diesem Kontext auch nicht.

Da Du Dich auf mein Vorposting, insbesondere local-root-Exploit, bezogen hast, ist für jeden der deutschen Sprache halbwegs mächtigen Menschen ersichtlich, das LRE in diesem Zusammenhang für local-root-Exploit steht.

Wenn Du auf den vorigen Satz reagieren möchtest, dann bitte gemäss Nutzungsbedingungen per privater Nachricht und nicht in diesem Thread.
</flame off>

 

[d4f]

Ich muss zugeben dass ich nicht direkt eine Quelle gefunden habe um die in Erinnerung gebliebenen 1.5 Jahre zu unterstuetzen, laut Symantec hat Stuxnet ein entsprechendes Exploit zirka Maerz 2010 erhalten, das Update wurde Anfang August zur Verfuegung gestellt, was die Luecke auf 'nur' 5-6 Monate in Wildbahn beziffert.

ist für jeden der deutschen Sprache halbwegs mächtigen Menschen ersichtlich, das LRE in diesem Zusammenhang für local-root-Exploit steht.

Hmm. Keines der 3 zusammengesetzten Woerter ist im Duden zu finden, wieso muss man also des deutschen maechtig sein?

Wie komplex ist die QA bei Linux oder OpenBSD?

Da alle Linux-Inhalte durch eine einzige Person geleitet werden welche ausschliesslich mit der Kernelentwicklung beauftragt ist und diesen besser kennt als sonst jemand, denke ich ganz gut =)
Die von Redhat sollte auch nicht schlecht sein
Bei Debian kann man die einzelnen QA-Prozesse hier verfolgen: http://qa.debian.org/

Es geht und gute Hoster tun dies auch.

Ach darum laden verschiedene Seiten so langsam. Eine Armee an hochtrainierten Spezialisten analysiert meine POST- und GET-Parameter, waehrend eine andere die Sicherheitsauswirkungen von Joomla-Extensions testet. Ich dachte immer der Server sei nur ueberladen...

@Threadersteller:
Bereits Neuigkeiten ueber den Server respektiv seinen Zustand?

 

[Joe User]

was die Luecke auf 'nur' 5-6 Monate in Wildbahn beziffert.

Du hast also noch immer nicht verstanden was QA ist und wie komplex diese ist.

Da alle Linux-Inhalte durch eine einzige Person geleitet werden welche ausschliesslich mit der Kernelentwicklung beauftragt ist und diesen besser kennt als sonst jemand, denke ich ganz gut =)

Diese eine Person kann wieviele verschiedene Hardware- und Software-Umgebungen auf Kompatibilität prüfen?

Die von Redhat sollte auch nicht schlecht sein

Gleiche Frage wie zuvor...

Bei Debian kann man die einzelnen QA-Prozesse hier verfolgen:

Debian und QA? Eine gute QA hätte niemals ein Paket (Exim) mit einem bekannten und per local-root-Exploit aktiv ausgenutzten Bug abgenickt, insbesondere wenn der notwendige Patch seit Jahren öffentlich bekannt ist. Das war leider kein bedauerlicher Einzelfall, diese Probleme treten bei Debian zu häufig auf, als das man da auch nur ansatzweise von QA reden könnte.

Ach darum laden verschiedene Seiten so langsam. Eine Armee an hochtrainierten Spezialisten analysiert meine POST- und GET-Parameter, waehrend eine andere die Sicherheitsauswirkungen von Joomla-Extensions testet. Ich dachte immer der Server sei nur ueberladen...

Das Hoster wie 1&1 eigene hochqualifizierte Entwickler beschäftigen und nahezu den gesamten Softwarestack vom Kernel bis zum Userland auditen, patchen und mit eigenen Sicherheitserweiterungen versehen, ist Dir bekannt? Zudem existieren einige kommerzielle wie nicht-kommerzielle proaktive Sicherheitslösungen, welche zusätzlich eingesetzt werden. Desweiteren gibt es auch Hoster (vorwiegend im aussereuropäischen Gebiet) die DPI und andere nette Kleinigkeiten betreiben, um ihre Netze und Systeme weitestgehend schadfrei zu halten.

 

[d4f]

Wenn ich dich mal zitieren darf:

[...] dann bitte gemäss Nutzungsbedingungen per privater Nachricht und nicht in diesem Thread.

Haters gonna hate

 

[Joe User]

Wenn ich dich mal zitieren darf:

Gerne, wenn Du den Zusammenhang noch erläuterst, denn der ist so nicht erkennbar.

Haters gonna hate

Schade, hatte gehofft, mit Dir könne man nicht nur reell sondern auch virtuell vernünftig diskutieren.


EDIT: Wurde per PN geklärt, alle Wogen geglättet.