RootForum Community

Hallo!

Ganz kurze Vorrede. Der Server ist von FirstDedicated und auf der Maschine läuft OpenVZ die Mailserver, Webserver usw. in jeweils einen Vserver um mehr Sicherheit zu bekommen.

Auf der eigentlichen Host System ist nur der ssh Daemon von außen erreichbar. Es laufen zwar noch diese wie chrony und die restlichen Standarddienste. Der root-Login für ssh ist deaktiviert.

Nun habe ich am 13.05. um ca. 18.50 Uhr bemerkt, dass der Server nicht mehr erreichbar ist. Ab 20.00 Uhr war er wieder Online. Beim betrachten der Log-Dateien konnte ich nachvollziehen, dass 18.50 Uhr der Server hochgefahren ist und das Dateisystem repariert hat. Der chrony konnte aber keine Verbindung herstellen, weil des Netzwerk nicht verfügbar war. Das syslog hat er weiterhin geschrieben und 20.00 Uhr erfolgte dann wieder ein Neustart. Der Provider sagt bis jetzt, dass nicht außergewöhnliches vorgefallen wäre.

Ich habe nach dem Login das Top beobachtet um die VE's wieder hochzufahren. Dabei ist mir aufgefallen, dass auch ein rm kurz last machte. Es könnte sein das alte Log-Dateien gelöscht wurden oder andere Systemskripte liefen. Ich habe aber keine solchen Skripte mit rm am laufen.

Auch beim gründlichen nach schauen der Logs ist mir nichts aufgefallen und rkhunter hat auch nichts gefunden.

Der Server lief übrigens schon wieder über 60 Tage und machte auch vorher mit dem Kernelvorgänger keine Probleme.

Watchdog der ein Neustart machen könnte ich auch nicht installiert.

Was haltet ihr von der ganzen Sache? Soll ich das ganze erst mal beobachten oder sollte ich mir schon noch mehr Gedanken machen ob sich da nicht jemand Zugriff auf dem Server verschafft hat.

Gruß

manticore

Hmm, ich würde an Deiner Stelle so vorgehen:
Zuerst mal alles, was an Logs da ist, per SCP nach Hause runterkopieren. Außerdem /etc/passwd, /etc/group und /etc/shadow runterziehen.
Dann mal prüfen, ob ps noch original ist (z. B. mal md5-Hash mit der Version vom Distributions-Mirror vergleichen) und die Ausgabe von `ps aux` ebenfalls mal als Datei runterziehen. Alle Crontabs und Dateien in /etc/cron.d/* ebenfalls wegsichern.

Dann kannst Du anfangen, Dich da durchzuwühlen. Gibt es verdächtige Einträge in den Logs? Wurden User hinzugefügt, die Dir unbekannt vorkommen? Und vor allem: Ist einer von denen in der shadow aktiv gesetzt? Gibt es Cronjobs oder verdächtige Prozesse? Wurden vielleicht sogar gängige Systemtools durch manipulierte Versionen ersetzt (ls, rm, ps, netstat, cd, touch, cat, ...)

Hallo jfreund,

also es sieht immer mehr so aus, als hätte es etwas mit dem Netzwerk zu tun gehabt. Vielleicht ein Angriff oder ein Bug im Kernel / OpenVZ. Jedenfalls kann ich sehen, dass OpenVZ noch ein „venetclean" durchgeführt hat und dabei die VE's alle gestorben sind. Möglicher weise ist dabei auch irgendwie das Protokoll, Treiber oder etwas anderes ausgefallen.

Dann habe ich mein Backup und das System verglichen. Es gibt vom MD5 keine verdächtigen Unterschiede an den Dateien. Nur ganz wenige vom letzten Update welches ich danach gefahren hatte. Die Grundbefehle und Dateien passwd, shadow usw. sind unverändert.

Also wenn wirklich jemand drauf war, dann muss dieser sehr sauber gearbeitet haben. Denn mehr als einen Blick kann er nicht riskiert haben.

Ich habe mich dennoch mal etwas kundig gemacht und das ganze zukünftig zu vereinfachen und habe TripWare gefunden. Werde das jetzt mal einrichten. Denn wenn nichts verändert wurde sind die Programme zumindest sauber. Wenn das nicht bedeuten soll, dass diese sicher sind.

Also danke dir für deine schnelle Antwort!

Gruß

manticore

Welchen openVZ Kernel hast am Start?

Hallo sledge0303,

ich habe das Patch patch-8.el5.028stab021.1-combined für RHEL5 (Red Hat Enterprise Linux 5) für den Kernel 2.6.18 angewendet. Die Distribution auf dem Server ist Debian. Ich habe mich für das RHEL5 Patch entschieden, weil dort noch andere Dinge gefixed wurden. Die Kernel-Konfiguration habe ich selbst vorgenommen und nach besten gewissen optimiert ;-).

Der Grund warum ich noch nicht auf 028stab031.1 umgestiegen bin ist der, dass er beim Compilieren abbricht. Das hatte ich bei der 028stab021.1 auch schon. Doch da konnte ich durch kurzes lesen im Quellcode herausfinden, welche config-Option einschaltet werden muss, damit die Variable gefüllt ist. Diese mal meckert er wieder eine andere an. Nicht gerade ein Aushängeschild für eine stable-Version.

Gruß

manticore