kompromittierter Server?

CEW4

Member
Hi,

auch ich habe heute von Strato einen Hinweis bezüglich meines V-Servers bekommen:

Code:
Ihr Server blabla.stratoserver.net hat in den letzten Stunden 
in unserem Monitoring ein auffälliges Verhalten aufgewiesen. Wir vermuten 
daher, dass Ihr Server kompromittiert ist.
Aha. Naja.

Dann geht es weiter:

Code:
Bitte prüfen Sie umgehend, ob sich in der Datei 
/root/.ssh/authorized_keys ein SSH-Key befindet, der nicht von Ihnen 
hinterlegt wurde.
Dort waren zwei Zeilen, die ich mich nicht erinnern könnte dort eingetragen zu haben. Können die auch von Plesk stammen, das sich mehr oder weniger ungefragt dort verewigt hat?

Dann habe ich chkrootkit laufen lassen. Ergebnis war nur dieses:

Code:
bindshell'... INFECTED (PORTS:  465)
Laut Google ist das i.d.R. ein Fehlalarm. Der dürfte bei mir an Plesk liegen, oder?

Nun bin ich allerdings so schlau wie zuvor:

- Die Backups bei Strato sind wertlos: Dort kann ich nur "wiederherstellen" anklicken, aber nicht nachschauen, ob bspw. die beiden Keys schon immer in dieser Datei steckten oder nicht.

- Ich weiß nicht einmal, was die Meldung von Strato ausgelöst hat. In den Traffic-Logs findet sich eine aussergewöhnliche Beule, diese aber bereits vorgestern, nicht wie in der Strato-Nachricht beschrieben "in den letzten Stunden".

- Mein Server hat normalerweise recht geringen Traffic. Es wäre also schon möglich, daß eine kurze, zufällige Belastung von Stratos "Monitoring" gleich als so aussergewöhnlich angesehen wird, daß es eine Warnung wert ist.

- Benutzer "default" oder "userx", wie in einem anderen Thread beschrieben, sind nicht vorhanden.


Aber was mache ich jetzt? Ich kann doch nicht jedesmal den Server neu installieren, wenn sich jemand meldet "es könnte sein... vielleicht auch nicht... möglicherweise doch..."

Abgesehen davon frage ich mich ernsthaft, wie man ein solches System beherrschen soll. Wo sind zum Beispiel überhaupt erst die Logdateien, aus denen hier gelegentlich Auszüge gepostet werden (FTP-Log, OS ist Suse Linux mit Plesk)? Wie soll man die als Normalmensch finden? Gibt es da irgendeine Logik? Gleiches gilt für Configdateien - müssen die derart wild über das System verteilt sein oder hat das einen Grund?

Noch etwas: Falls mein Server tatsächlich ungebetenen Besuch hatte, müssten doch jetzt entweder Ports offenstehen, die nicht offenstehen sollten, oder in irgendeinem bereits laufenden Dienst ein neuer User eingetragen worden sein. Ist nicht das eine "endliche" Anzahl zu überprüfender Stellen? Gibt es davon vielleicht eine Liste?

Gruß,
CEW4
 
Das sieht klassisch nach einem übernommenen (gehackten) Server aus.

Bitte überprüfe die aktuell gestarteteten Prozesse mit

Code:
ps aux

und durchsuche diese nach ungewollt gestarteten Programmen und Skripten.
Dann nach würde ich nach offenen Ports suchen, vielleicht wurde eine Backdoor installiert.

(müsste vielleicht nach installiert werden, unter Debian mit apt-get)

oder mit Netstat

netstat -tulpen
 
Deine "Tips" sind für die Katz, siehe:

Sorry.
 
Deine "Tips" sind für die Katz, siehe:
Sorry.

Ohne jetzt zu weit vom Thema ab zu weichen, viel konstruktiver war dein Beitrag jetzt aber nicht, oder?

Ich gehe meist immer vom schlimmsten aus, wenn der Provider sich schon beim Endkunden meldet. Das hat im Normalfall immer eine Vorgeschichte, sonst würde der Provider sich nicht beim Endkunden melden. Klar kommt es vor, dass es sich ab und an um "false positives" handelt, doch in den meisten Fällen ist etwas beim Endkunden schief gelaufen.

Auch verstehe ich nicht, was du mir mir dem Thread sagen möchtest?

Ich habe lediglich versucht auf die Fragen von CEW4 etwas ein zu gehen.

...müssten doch jetzt entweder Ports offenstehen, ...

etc..

@CEW4:
du könntest Logfiles von deinem Provider anfordern zu dem Vorfall, um dann deinen Server mit den vom Provider übersendetet Zeitstempeln ab zu gleichen.
 
Ich würde Strato mal auffordern zu erklären was denn das "auffällige Verhalten" überhaupt sein soll, nur ein zeitweise erhöhtes Trafficaufkommen? Zeitrahmen? Mit diesen Angaben kannst du dann der Sache nachgehen, ohne solche Angaben ist die Warnung von Strato für meinen Geschmack reichlich schwammig und trägt nicht gerade zur Aufklärung bei.
 
Last edited by a moderator:
@its: "für die Katz" sind deine Tips deswegen, da sie - nach Dir - auf dem evtl. kompromittierten System selbst ausgeführt werden sollen.

Wenn "der Hacker" aber ein bisschen mehr als gar keine Ahnung von dem hat, was er tut - wirst Du ihn so nicht entdecken.

eine saubere forensische Analyse lässt sich nur von einem vertrauenswürdigen Drittsystem aus durchführen.
 
Das sieht klassisch nach einem übernommenen (gehackten) Server aus.
Woraus genau schließt Du das?

- Die Traffic-"Beule" könnte von allem sein - vielleicht hat ein User einen neuen IMAP-Client eingeschaltet und die gesammte Mailbase geladen. Vielleicht haben zufällig ein paar Webuser auf einmal eine Datei gedownloaded - wie gesagt, bei meinem Trafficaufkommen wäre es leicht, eine Anomalie zu produzieren.

- Angreifer verursachen heutzutage doch nciht mehr primär Traffic, sondern verschicken Spam. Dann aber müsste es doch jede Menge Bounces als Rückläufer geben, die ich wiederum sehe. Oder?

- Das einzige Handfeste sind die beiden Keys in .ssh/authorizedkeys. Dummerweise kann ich nicht mit Sicherheit sagen, ob die nicht schon immer dort waren. Kurz: Gibt es irgendeine Möglichkeit, wie diese Keys ohne mein Zutun, aber trotzdem legal, dort hingekommen sein können? Trägt Plesk dort etwas ein?


Alle Vorkommnisse wären also als Fehlalarm erklärbar - bis eben auf die Keys.


MfG,
CEW4
 
...
- Das einzige Handfeste sind die beiden Keys in .ssh/authorizedkeys. Dummerweise kann ich nicht mit Sicherheit sagen, ob die nicht schon immer dort waren. Kurz: Gibt es irgendeine Möglichkeit, wie diese Keys ohne mein Zutun, aber trotzdem legal, dort hingekommen sein können? Trägt Plesk dort etwas ein?...MfG,
CEW4

Wohl eher nicht.
 
Ich habe lediglich versucht auf die Fragen von CEW4 etwas ein zu gehen.
... und der weiß das sehr zu schätzen, um das einmal ganz nebenbei zu bemerken! :-)

du könntest Logfiles von deinem Provider anfordern zu dem Vorfall, um dann deinen Server mit den vom Provider übersendetet Zeitstempeln ab zu gleichen.
Ja, das werde ich, allerdings habe ich da nicht viel Hoffnung. Strato wird wohl aus zwei Gründen nicht viel herausrücken: Erstrens wäre es Arbeit für sie, zweitens möchten sie wahrscheinlich nicht, daß sich herumspricht, was genau ihr System erkennt und was nicht.

MfG,
CEW4
 
@marce:

...eine saubere forensische Analyse lässt sich nur von einem vertrauenswürdigen Drittsystem aus durchführen.

Da stimme ich dir zu, meine Tipps am Anfang des Threads, waren reine standard Tools mit denen man einen basis Hack relativ schnell erkennnen sollte.
 
Nur so als Gedankenspiel:
Bei einem vServer habe ich ja immer das Problem, dass ich nicht mit einem sauberen System von außen rankomme, also z.B. das System nicht von einem Zweitsystem aus untersuchen kann.
Das Rescue-System bietet auch nur sehr eingeschränkte Möglichkeiten.

Wäre es nun möglich, eine Kopie des vServers folgendermaßen zu erhalten:
1. boote den vServer im Rescue-System
2. # chroot /rescue
3. # tar cpjf /var/private-backup/system.tar.bz2 *
4. Tarball (system.tar.bz2) auf ein lokales System herunterladen

Nun folgende Schritte z.B. in einer virtuellen Maschine lokal machen:

5. sauberes Linux in der lokalen virtuellen Maschine installieren, dabei dieselbe Linux-Version und Distro wie die des "verdächtigen" Systems verwenden
6. System von (beliebiger Rettungs-) CD starten
7. # tar xpfC system.tar.bz2 /mnt/root-des-sauberen-systems

Nun sollte doch das lokale System in der virtuellen Maschine identisch mit dem aus dem vServer sein, oder?
Vorteil hier wäre jetzt, dass ich das lokale System von außen untersuchen kann, beispielsweise mit einem garantiert "sauberen" rkhunter, ich könnte md5-Prüfsummen vergleichen usw.

Der Kernel ist natürlich davon ausgenommen. Nur frage ich mich, wie groß ist das Risiko eines Kernel-Exploit bei einem vServer überhaupt?

Hinweise auf Denkfehler werden gern entgegengenommen! :)
 
Last edited by a moderator:
Alle Vorkommnisse wären also als Fehlalarm erklärbar - bis eben auf die Keys.

Das ist die falsche und vollkommen gefährliche Denkweise. Du willst unbedingt einen sicheren und vertrauenswürdigen Server, nicht wenig Arbeit.

Entscheident ist nicht, ob du es als Fehlalarm erklären könntest, sondern, ob du mit Sicherheit sagen kannst (100%), dass es ein Fehlalarm war. Das kannst du nicht, also gehst du bitte dir zuliebe immer vom Schlimmsten aus -> Server so schnell wie möglich neu aufsetzen!
 
Abgesehen davon frage ich mich ernsthaft, wie man ein solches System beherrschen soll. Wo sind zum Beispiel überhaupt erst die Logdateien, aus denen hier gelegentlich Auszüge gepostet werden (FTP-Log, OS ist Suse Linux mit Plesk)? Wie soll man die als Normalmensch finden? Gibt es da irgendeine Logik? Gleiches gilt für Configdateien - müssen die derart wild über das System verteilt sein oder hat das einen Grund?

Ganz kurz und schonungslos: wenn du dir solche Fragen stellst, dann solltest du dir einmal Gedanken darüber machen, ob ein Managed Server nicht viel besser für dich wäre.

Man sollte nämlich wissen, dass die Hoster ihren potentiellen Kunden natürlich scheinbare Einfachheit und Sicherheit vorgaugeln und die Administration eines eigenen Servers durch die Vielzahl div. Admin Panels wie Plesk & Co. mittlerweile ein Kinderspiel zu sein scheint, das ist aber leider nicht der Fall. Wer das wirklich glaubt, der ist lediglich in die Marketingfalle der Hoster getappt, denn die wollen ihre Produkte doch primär auch nur verkaufen. Die Verantwortung trägt aber IMMER der Kunde, siehe AGBs, Managed Server davon ausgenommen.

Geänderte Keys im Root-Verzeichnis? Root-Zugang per SSH ist überhaupt erlaubt? Ich für meinen Teil sehe hier akuten Handlungsbedarf, der sich primär durch einen sauberen Reinstall des Systems auszeichnet bzw. durch einen Wechsel auf einen Managed Server.
 
Die Traffic-"Beule" könnte von allem sein - vielleicht hat ein User einen neuen IMAP-Client eingeschaltet und die gesammte Mailbase geladen. Vielleicht haben zufällig ein paar Webuser auf einmal eine Datei gedownloaded - wie gesagt, bei meinem Trafficaufkommen wäre es leicht, eine Anomalie zu produzieren.

"Könnte" gibts nicht. Dafür gibt es Logs, erste Anlaufstelle also /var/log. Interessant sind hier sämtliche access Logs, je nach Kompromittierungsgrad könnte sich die Herkunft des SSH Keys eventuell noch durch das lastlog aufklären lassen.
Aber leider muss ich mich da tomasini anschließen, beim Betreiben eines Servers sind die Logs das A&O, und wenn du nicht einmal weißt wo sich diese befinden ist das schon sehr bedenklich.
 
Last edited by a moderator:
Entscheident ist nicht, ob du es als Fehlalarm erklären könntest, sondern, ob du mit Sicherheit sagen kannst (100%), dass es ein Fehlalarm war.

Naja, das kann man nie- das kann auch Strato nicht!
Beispielsweise könnte auch deren Monitoring eine Fehlfunktion haben, auch wenn das sehr unwahrscheinlich ist. Oder die Warn-eMail kam garnicht von Strato. Oder ein Mitarbeiter hat einen Fehler gemacht. Usw.
Letztendlich hast Du nie 100%ige Sicherheit, wie die aktuell gefundene Backdoor in ProFTPd zeigt: Selbst wenn ich meine Pakete selbst aus den Sourcen übersetzt hatte, habe ich mir so die Backdoor eingefangen.
Aktiv werden sollte man aber auf jeden Fall.

Aber: Vorsicht mit Prozentzahlen! Und völlige Sicherheit ist imho Illusion.
 
Das ist die falsche und vollkommen gefährliche Denkweise. Du willst unbedingt einen sicheren und vertrauenswürdigen Server, nicht wenig Arbeit.
Nicht ganz: Du sprichst Theorie, ich spreche Praxis.

Wenn ich den Server neu installiere, dann bedeutet das für mich einen Monat Arbeit. Full Time. Support für die User, die ihre Mailclients und wasweißich neu konfigurieren müssen geht noch länger.

Ein solches Unternehmen packe ich nur an, wenn es sein muß, nicht wenn etwas passiert "sein könnte". Wo soll das enden? Nächsten Monat kommt wieder eine solche automatische Warnung, die berechtigt sein kann, aber es nicht sein muß. Soll ich dann wieder von vorne anfangen?

Entscheident ist nicht, ob du es als Fehlalarm erklären könntest, sondern, ob du mit Sicherheit sagen kannst (100%), dass es ein Fehlalarm war.
Das versuche ich ja die ganze Zeit herauszubekommen. Stratos Meldung kann ein Fehlalarm gewesen sein, weil sie nur von "merkwürdigem Verhalten" sprachen, nicht etwa von "Signatur gefunden". Ein Umstand ist noch nicht erklärt (die Keys), alles andere spricht _gegen_ eine Kompromittierung.

Könnte ich einen handfesten Beweis für einen Einbruch finden, sähe die Sache ganz anders aus.

MfG
 
Beispielsweise könnte auch deren Monitoring eine Fehlfunktion haben, auch wenn das sehr unwahrscheinlich ist.
Nicht einmal: In der email wird z.B. chkrootkit empfohlen. Dieses zeigt einmal INFECTED an, obwohl es sich dabei mit allergrößter Wahrscheinlichkeit um ein "false positive" aufgrund von Plesk handelt. Falls also das bei Strato laufende Skript das Ergebnis von chkrootkit verwertet, ist es gar nicht so unwahrscheinlich, daß es sich um einen falschen Alarm handelt.

MfG
 
NFalls also das bei Strato laufende Skript das Ergebnis von chkrootkit verwertet, ist es gar nicht so unwahrscheinlich, daß es sich um einen falschen Alarm handelt.

Naja, so blöd wird Strato bei der Entwicklung ihres Monitoringtools auch nicht gewesen sein! :) Und Du hast ja noch Deine unbekannten SSH-Keys! :(
Versuche aber mal, wie oben schon empfohlen, nähere Infos (Logfiles?) von Strato anzufordern.
Ein zweiter Versuch wäre u.U., mal "probeweise" ein Backup einzuspielen. Sind dann die SSH-Keys verschwunden, kamen sie wohl von dem Einbruch. In diesem Fall würde ich dann sofort alle Updates und anschließend die vorher hoffentlich gesicherten Daten zurückspielen.
Hinterher alle Passwörter zu ändern, sollte selbstverständlich sein.

Grundsätzlich ist aber sowieso zuerst eine Analyse angesagt- die Lücke muss ja nicht von einem manipulierten Binary kommen...
 
Last edited by a moderator:
wenn du dir solche Fragen stellst, dann solltest du dir einmal Gedanken darüber machen, ob ein Managed Server nicht viel besser für dich wäre.
Da hast Du völlig Recht, die mache ich mir auch gerade. Ich kenne aber noch kein passendes Angebot: Root-Zugriff sollte bleiben, aber ich brauche einen Admin, der einen Teil der Systempflege übernimmt. "Managed Root" würde schon passen, aber der Begriff ist mir noch ein wenig zu schwammig. Kennt jemand ein empfehlenswertes Angebot in der Richtung?

durch die Vielzahl div. Admin Panels wie Plesk & Co. mittlerweile ein Kinderspiel zu sein scheint, das ist aber leider nicht der Fall.
Das ist mir schon klar. Aber daß ein System im Auslieferungszustand derart gravierend unsicher ist, gab es in der Windows-Welt zum letztenmal vor zehn Jahren (dieser RPC-Wurm, Ihr erinnert euch?)

Daß ein vorkonfiguriertes (!) OS im Jahr 2010 noch derart gefährlich, chaotisch und unbeherrschbar sein kann, lässt man sich als verwöhnter MS-Admin nicht träumen.

Geänderte Keys im Root-Verzeichnis? Root-Zugang per SSH ist überhaupt erlaubt?
Der Auslieferungszustand wurde nicht verändert. Woher soll ich das also wissen?

Vernünftigerweise sollte er deaktivert sein, es sei denn, ich hätte ihn manuell aktiviert. Das gleiche sollte auch gelten für FTP sowie den ganzen restlichen Kram, der auf dem System läuft.

Aber offenbar scheint das alles hier nicht der Fall zu sein.

MfG
 
Naja, so blöd wird Strato bei der Entwicklung ihres Monitoringtools auch nicht gewesen sein! :)
Wie wir vorher sagten: Können wir es ausschließen? <eg>

Ein zweiter Versuch wäre u.U., mal "probeweise" ein Backup einzuspielen. Sind dann die SSH-Keys verschwunden, kamen sie wohl von dem Einbruch.
Das kann ich ja so einfach nicht machen. Die Web-Präsenzen zu sichern ist das geringste Problem, aber was ist mit Mailbases, Useraccounts und Einstellungen? Ich weiß ja nicht einmal, wo die alle verstreut sind. Sichern ist damit unmöglich, ich müsste statt dessen "nachher" alles neu konfigurieren. Das einfach so zum Probieren... na, ich danke.

Grundsätzlich ist aber sowieso zuerst eine Analyse angesagt- die Lücke muss ja nicht von einem manipulierten Binary kommen...
Das ist sowieso unklar: Der Patch für FTP ist seit Wochen installiert. Rein theoretisch kann da also gar nichts passiert sein.

... aber beweis' das mal einer, wenn einem eine solche Strato-Warnung den Schlaf raubt.

MfG
 
Back
Top