Tips zur Untersuchung gehackter Webserver

Sobald ein Webserver ein ungewöhnliches Verhalten zeigt oder es schon offensichtlich ist, dass er kompromittiert wurde ist es erforderlich ihn vom Netz zu nehmen und vollständig zu untersuchen. Die Untersuchung ist erst abgeschlossen, sobald das Loch oder die Löcher über die der Angriff erfolgte eindeutig identifiziert wurden. Die folgende Liste ist weder komplett noch kann sie garantieren, dass man eindeutig sagen kann ob ein Webserver tatsächlich gehackt wurde oder nicht. Sie soll lediglich Ansatzpunkte für eine erste Untersuchung zeigen.
Am Ende des Artikels findet sich eine Liste von Softwarepaketen die üblicherweise verwendet werden um Linuxserver abzusichern.

1) Mit 'ps auxf' kann man zuerst mal schauen ob offensichtliche verdächtige Prozesse am Laufen sind. Wichtig ist alle Prozesse anzusehen. Manchmal werden die Namen solcher Prozesse z.B. mit eckigen Klammern versehen um sie zu "verstecken", so könnte man sie auf den ersten Blick eventuell übersehen.

2) Besonderes Augenmerk sollte man auf alle ungewöhnlichen Prozesse richten, die über den www-Benutzer des Systems laufen.

3) Auch sollte man prüfen ob wichtige Prozesse nicht laufen, wie der System-Loggingdienst beispielsweise.

4) Mit 'netstat -tulpen' lässt sich prüfen ob ungewöhnliche Ports geöffnet wurden. Der Port 6667 wäre ein Beispiel dafür. Mit nmap sollte man sein System auch von außen scannen um zu sehen welche Ports wirklich offen sind.

5) Generell sind alle verfügbaren Logs von Firewall, mod_security, Webserver, Mailserver, IDS etc. mit grep auf verdächtige Einträge zu untersuchen. Leider muss man dies auch bis zu einigen Monaten früher durchführen, da ein Angreifer oft längere Zeit nach dem Einbruch wartet bevor er das System tatsächlich für sein Zwecke missbraucht.

6) Wiederum besonders detaillierte Untersuchungen sind bei den Apache-Logdateien angeraten. Strings wie "wget", "fetch", "shell", "=http://" and ähnliche Konstrukte stellen in der Regel Angriffe dar.

7) Jedes ungewöhnliche Verhalten des Gesamtsystems oder einzelner Applikationen kann einen Einbruch oder Einbruchsversuch signalisieren. Die folgenden Parameter sollte man sich anschauen: Freier Platz auf den Festplatten, uptime, CPU-Auslastung, Hauptspeicherverbrauch, Traffic, Mailaufkommen, etc. Auch der Absturz oder Hänger von Anwendungen kann ein Kennzeichen für Angriffe sein, was sich in den entsprechenden Logs zeigen kann.

8) Skripte von Hackern auf Webservern werden oft in /tmp oder /var/tmp geschrieben. Diese Ordner sollte man nach Skript-Code durchsuchen. Hier ist mal als Beispiel ein Auszug eines typischen PHP-Skriptes:

...
if(function_exists('exec')){
@exec($cfe,$res);
$res = join("n",$res);
}
elseif(function_exists('shell_exec')){
$res = @shell_exec($cfe);
}
elseif(function_exists('system')){
@ob_start();
@system($cfe);
$res = @ob_get_contents();
@ob_end_clean();
}
elseif(function_exists('passthru')){
...

Manchmal enthalten diese Datein Source-Code in einer absichtlich unleserlichen Form. Man sieht zwar Source-Code aber Variablennamen, Funktionssnamen etc. haben lange und verwirrende Zeichenfolgen oder bestehen einfach nur aus Ziffern. Einrückungen und Zeilenumbrüche werden entfernt. Hierzu auch ein Auszug aus einem solchem Skript als Beispiel.

$aec12e0af93cb5 = array ( "po" => 8080, "sp" => "uJijk4iVsIXRmQ==", "ch" => "aFaw",
...
function ob5d21085bf2c0($m341be97d9aff9) {
$m341be97d9aff9 = base64_decode(tc8a89c2c306fb($m341be97d9aff9));
...

9) Mit dem Program rkhunter lässt sich das System auf vorhandene Rootkits, manipulierte Systemdateien etc. untersuchen. Wichtig jedoch ist, dass man sich vor dem Ausführen die aktuellsten Daten herunterlädt (rkhunter --update).

10) Weiterhin sind alle hochgeladenen Bilder und Dateien zu untersuchen ob sie Source-Code enthalten. Manche Hacker laden Bilder hoch, die jedoch in Wirklichkeit Skriptdateien sind. Auch alle Dateien mit seltsamen Dateinamen sollte man sich genauer ansehen.

11) Alle Dateien unterhalb des Webserververzeichnisses sollten auf typischen Phishing-Inhalt durchgesehen werden. Zum Beispiel lässt sich ein grep nach "paypal", "ebay" und ähnlichem durchführen.

12) Optimalerweise hat man Tools wie Aide oder Tripwire vorher verwendet. In diesem Fall kann nun das System dahingehend prüfen ob wichtige Binärdateien des Systems wie "ps" oder "top" manipuliert wurden.

13) Die Dateien /etc/passwd, /etc/shadow und /etc/group sollten keine ungewöhnlichen, neuen oder fehlenden Einträge haben.

Leider muss man sagen, dass das bisher beschriebene nur ein Kratzen an der Oberfläche ist. Mit diesen Maßnahmen kann man die Aktivitäten von Skript-Kiddies feststellen. Leute, die nicht vielmehr tun als vorgefertigte Skripte auszuführen. Mit dem eigentlichen Hacken von Systemen hat das alles aber eher wenig zu tun. Ein professioneller Angreifer wird auf einem kompromittierten System kaum Spuren hinterlassen (Logeinträge entfernen usw.). Es gibt sogar fertige Tools um solche Spuren zu eliminieren. Andere Hacker wiederum lassen ganz bewußt falsche Spuren zurück, um eine Untersuchung in eine falsche Richtung laufen zu lassen oder um die Zeitdauer der Untersuchung möglichst hoch zu treiben.

Letztlich entscheidet die Ebene, die ein Angreifer erreicht hat über die weiteren Maßnahmen. Falls er/sie in der Lage ist einfach nur ein Skript mit den Rechten des www-Benutzer zu starten und einen Port zu öffnen kann es ausreichend sein, das Sicherheitsloch zu schließen, das Skript zu entfernen und den Prozess zu killen. Falls das System aber bereits ein Rootkit laufen hat kommt man kaum um eine Formatierung aller Festplatten herum.

Eventuell spart man sich Zeit, Geld und Nerven, wenn man eine solche Untersuchung an professionelle Sicherheitsdienstleister abgibt.

Es ist natürlich wesentlich besser und produktiver sein System abzusichern bevor es soweit kommt. Einige Maßnahmen sind sehr einfach zu implementieren und erhöhen trotzdem dramatisch die Sicherheit des Servers (z.B. ModSecurity). Andere Methoden können extrem kompliziert sein und richten sich vielleicht auch nicht auf das tatsächliche Bedrohungsszenario aus (z.B. SELinux). Hier einige Vorschläge:
sudo
Suhosin
PHPsuexec
Cacti
ModSecurity
Nessus
Iptables
Virtualization (xen, vserver)
Aide
Snort
Grsecurity
SELinux

Härtung von Apache-Webservern