»wwwrun« gehört, ist der Befund schon
offensichtlich.
Keine Chance bei Rootkits
Nur wenn ihm echter Rootzugriff gelun-
gen ist, kann sich der Angreifer tatsäch-
lich unsichtbar machen. Rootkits mo-
difizieren Systemtools oder den ganzen
Kernel, sodass sie verräterische Prozesse,
Dateien, offene TCP-Ports und den IP-
Traffic das Angreifers ausblenden. Auf
dem kompromittierten System ist es dann
kaum möglich, den Angreifer zu finden,
denn der Admin sieht alles durch die
Filterbrille des Angreifers.
In der Praxis kommt ein Großteil der
Angreifer jedoch kaum so weit. Dort do-
miniert das Brot-und-Butter-Geschäft der
Spammer, Phisher und Kreditkartenbe-
trüger: Über eine Sicherheitslücke in ein-
schlägigen CMS-Webseiten installiert der
Angreifer eigenen Content auf dem Web-
server, versendet Spam oder hostet Mal-
ware – echten modifizierenden Zugriff
auf das System erlangen die wenigsten.
Linux-Magazin: Welche sind die häufigsten Feh-
ler, die Admins nach dem Erkennen eines er-
folgreichen Angriffs auf ihre Systeme begehen?
Peer Heinlein: Wie so oft gilt: Keine Panik!
Wenn der Geschädigte davon ausgehen
darf, dass das Problem schon länger be-
steht und dass nicht gerade akut sensible
Daten aus dem Netzwerk abfließen, be-
steht kein Grund zu blinder Hektik.
Wer das System gut gemeint neu instal-
liert, aber am Ende das gleiche kaputte
CMS ohne Bugfix wieder einspielt, wird
wenige Stunden oder Tage später wieder
infiziert sein. Sind alle Beweise zerstört,
lässt sich auch kein Code mehr analy-
sieren, der Rückschlüsse darauf zulässt,
welche Ziele der Angreifer verfolgte und
ob er beispielsweise Datenbanken kopiert
oder ausgelesen hat. Am Ende ist diese
Unwissenheit der größte Schaden.Linux-Magazin: Welche Vorgehensweise emp-
fiehlst Du? Betroffene Systeme abschalten und
Festplatten- beziehungsweise VM-Images – fo-
rensisch untersuchen? Oder weiterlaufen las-
sen und den Einbrecher beobachten? Lohnt es,
Energie in die Attribution zu investieren?
Peer Heinlein: In jedem Fall sollte der
Admin recherchieren und vor allem do-
kumentieren, um die Ursachen für den
Einbruch aufzuklären. Denn er muss aus
dem Vorfall lernen und Lücken schließen,
sonst ist es nur eine Frage der Zeit bis zur
Wiederholung. Das Dokumentieren sollte
umfassend erfolgen, selbst in den Berei-
chen, die zunächst harmlos aussehen:Ein vollständiger Dump der Prozessliste,
offener TCP-Verbindungen, neural gischer
Speicherorte wie dem »/tmp«-Verzeichnis
und aller Logfiles.
Auch sollte der Admin mit »lsof« offene
Dateien als Liste dokumentieren. So
kommt er Angreifern auf die Spur, die
eigene Dienste ins System kopiert und
gestartet, dann aber die Programmda-
teien gelöscht haben, damit diese nicht
mehr im Dateisystem zu finden sind. Of-
fene, aber bereits als gelöscht markierte
Dateien sollten argwöhnisch machen,
und der Admin sollte den zugehörigen
Prozess genau anschauen. Er kann dann
über die Prozessnummer im »/proc«-Ver-
zeichnis sogar noch auf den gelöschten
Programmcode zugreifen (Abbildung 1).Leichter bei Virtualisierung
Von virtualisierten Servern ist in vielen
Fällen ein Snapshot mitsamt allen Daten33http://www.linux-magazin.deTitelthemaExpertenratAbbildung 1: Über die Prozessnummer im »/proc«-Verzeichnis ist der Zugriff auf Executables möglich, die
nicht mehr auf der Festplatte liegen.