Veni, Vidi, VISA

Beim Ueberpruefen eines Routers fiel uns ein Host besonders ins Auge. Einer der vielen dort vorhandenen Root-Server hat innerhalb einer Woche knapp 350G Traffic verursacht. Als wir uns dann die Logfiles genauer angesehen haben, wurde der Traffic ausschliesslich ueber POP/SMTP, FTP und Emule/Torrent verursacht. Was denau alles auf dem Server liegt.. keine Ahnung. Er wurde vom Netz genommen und der firmeneigene Anwalt konsultiert, damit die Kiste bzw. die Daten auf den HDs untersucht werden koennen.
Ich denk mal das die Kiste gecrackt und zum Filesharing missbraucht wurde. Wayne.. in den AGB steh klipp und klar das der Kunde verantwortlich fuer den Server ist. Ergo kriegt auch nur er eine auf den Deckel. Hoffentlich eine richtig heftige, damit es sich rumspricht und nicht noch mehr Kiddies und Idioten auf die Idee kommen sich einen konkret krassen Root-Server anzuschaffen.
Als Lektuere empfehle ich inzwischen http://strcat.de/blog/archives/863-Root-Server-fuer-jeden.html, http://serverzeit.de/FreeBSD/admins-haften/ und http://mi.hostsharing.de/root-Server-mistakes.html.

Am Montag ist es mal wieder soweit. $KUNDE will das ich auf einem Server der gecrackt wurde, eine forensische Analyse und weil ich mal wieder nicht schlafen kann, schreib ich mal zusammen wie ich bei sowas vorgehe. Also nur den technischen Vorgang und nicht das Melden des Angriffes.

Server vom Netz nehmen!

Es gibt kein "Aber.."! Die Kiste muss sofort vom Netz um den Schaden zu minimieren. Einige Personen (hauptsaechlich solche ohne Ahnung, aber mit was zu Sagen) fangen so gut wie immer an zu diskutieren und verlangen das die Analyse/Saeuberung online vorgenommen wird. In solchen Faellen hilft es ungemein wenn man einen Vordruck hat, auf dem steht das der Unterzeichnende die volle Verantwortung fuer diese Entscheidung uebernimmt.
Mit diesem Vordruck in der einen und einen Kuli in der anderen Hand, fragt man dann in die Runde wer unterschreibt. Spaetestens dann darf man den Server vom Netz nehmen.

Nicht rebooten!

Fuer eine Analyse benoetigt man den aktuellen Zustand und der ist nach einem Reboot nicht gegeben. Ein Reboot sorgt dafuer das manuell gestartete Prozesse nicht mehr laufen. Ich hatte aber auch schonmal einen Fall, in dem der Angreifer in einem Runlevel ein Script angelegt hat, dass die von ihm installierten Programme umbenennt und anschliessend startet.

Daten sichern

Nein. Nicht fuer die naechste Installation, sondern fuer eine Kopie des Systems. Nach Moeglichkeit eine Kopie des gesamten Systems im aktuellen Zustand. Sollte der Speicherplatz nicht ausreichen, ist das Minimum /etc und /var.
Es zahlt sich auch aus wenn man sein Vorgehen aufschreibt; das hat den Vorteil das man genau weiss was man schon gemacht/untersucht hat und was nicht.

Logfiles ueberpruefen

Nicht auf irgendwelche Shellscripte von Freshmeat/Sourceforge verlassen; die erleichtern zwar die Arbeit, aber haben auch den Nachteil das sie manipulierbar sind. Das bekannteste Beispiel ist anti-chkrootkit.pl. Wenn man Tools verwendet, dann solche von denen man weiss das sie sauber sind. Ich habe dazu die notwendigen Programme immer auf CD und einem USB-Stick dabei um sie "mal schnell rueberkopieren" zu koennen.

Informationen beschaffen

Dazu gehoert u. a. eine Liste aller laufenden Prozesse, der verwendeten Ports, alle setuid-Programme, neu installierte Programme (Abgleichen mit einer Liste der zuvor vorhandenen Programme), und und und..
Von den existierenden Programmen kann man sich relativ einfach eine brauchbare Liste mit den notwendigsten Informationen erstellen lassen. Dazu benoetigt man lediglich stat(1) und md5sum(1); mal ein kleines Beispiel:

$ mkdir foobar && cd foobar

$ touch foo bar foobar barfoo

$ for i in ~/foobar/*; do stat "$i" && echo -e md5sum: "`md5sum "$i"`\n"; done > ~/chksum.txt

$ cat ~/chksum.txt

  File: `/home/dope/foobar/bar'

  Size: 0               Blocks: 0          IO Block: 4096   regular empty file

Device: 803h/2051d      Inode: 10716848    Links: 1

Access: (0600/-rw-------)  Uid: ( 1000/    dope)   Gid: (  100/   users)

Access: 2007-10-14 04:44:54.000000000 +0200

Modify: 2007-10-14 04:44:54.000000000 +0200

Change: 2007-10-14 04:44:54.000000000 +0200

md5sum: d41d8cd98f00b204e9800998ecf8427e  /home/dope/foobar/bar



  File: `/home/dope/foobar/barfoo'

  Size: 0               Blocks: 0          IO Block: 4096   regular empty file

Device: 803h/2051d      Inode: 10716850    Links: 1

Access: (0600/-rw-------)  Uid: ( 1000/    dope)   Gid: (  100/   users)

Access: 2007-10-14 04:44:54.000000000 +0200

Modify: 2007-10-14 04:44:54.000000000 +0200

Change: 2007-10-14 04:44:54.000000000 +0200

md5sum: d41d8cd98f00b204e9800998ecf8427e  /home/dope/foobar/barfoo



  File: `/home/dope/foobar/foo'

  Size: 0               Blocks: 0          IO Block: 4096   regular empty file

Device: 803h/2051d      Inode: 10716847    Links: 1

Access: (0600/-rw-------)  Uid: ( 1000/    dope)   Gid: (  100/   users)

Access: 2007-10-14 04:44:54.000000000 +0200

Modify: 2007-10-14 04:44:54.000000000 +0200

Change: 2007-10-14 04:44:54.000000000 +0200

md5sum: d41d8cd98f00b204e9800998ecf8427e  /home/dope/foobar/foo



...

Informationen aus dieser Liste ueber einzelne Programme muss man anschliessend nicht lange per Hand suchen, sondern kann sie sich mit grep -B8 barfoo$ chksum.txt anzeigen lassen. Hauptsaechlich dient diese Liste aber dazu, um sie spaeter mit einer (nach dem gleichen Prinzip erstellten Liste) abzugleichen. Dazu benoetigt man ein identisches System (gleiche Distribution, gleiche Software, ..); auf diesem System wird ebenfalls eine solche Liste erstellt und dann via diff(1) auf Unterschiede geprueft.
Prinzipiell sind erstmal alle Dateien (Ja. alle Dateien!) gefaehrlich.

Einbruchserkennung

Wie erkennt man auf welchem Weg sich der Cracker Zugriff auf das System beschafft hat? Das ist manchmal trivialer als man denkt. Zum Grossteil sind Cracker irgendwelche Scriptkiddies, die sich Exploits herunterladen und ausfuehren. Zuerst besorgt man sich einen Ueberblick ueber die installierte Software (mit besonderem Augenmerk auf Netzwerkdienste); anschliessend sieht man sich auf den bekannten Seiten (Securityfocus, milw0rm, SecuriTeam, metasploit, ..) um und wird in 80% aller Faelle fuendig. Ein Blick in die Logfiles des Systems sollte auch nicht versaeumt werden (sofern diese nicht durch den Angreifer geloescht/geaendert wurden).
So traurig es auch ist, aber fast immer basieren erfolgreiche Angriffe auf Nachlaessigkeit des Admins. Sei es durch Fehlkonfiguration oder durch fehlende Security-Updates.

Backups

Von einem solchem System werden keine Backups erstellt, damit man sie anschliessend wieder einspielen kann. Auch nicht ausnahmsweise. Selbst schon vorhandene Backups sollte genauestens ueberprueft werden, bevor man diese einspielt. Sobald ein Server kompromittiert wurde, ist die einzig brauchbare Loesung eine Neuinstallation. Und zwar vom kompletten System und von den Originalmedien.

Es gaebe noch etliche Punkte die man beachten muss und auf die ich eingehen koennte, allerdings fuellt dieses Thema ganze Buecher und es gibt keine allgemein gueltige Vorgehensweise die man per copy&paste nutzen kann. Stattdessen verweise ich jetzt einfach mal auf URLs die sich mit diesem Thema befassen:

• Intruder Detection Checklist
• Steps for Recovering from a UNIX or NT System Compromise
• Linux Security Administrator's Guide
• Focus On Linux: Intrusion Detection on Linux
• Intrusion Detection FAQ (SANS)
• FAQ: Network Intrusion Detection Systems
• Intrusion Detection System Training

Es gibt auch etliche Distributionen welche sich als "Forensic environment" bezeichnen, aber ich persoenlich nutze ausschliesslich BackTrack, Arudius, F.I.R.E, NetSecL und/oder Pentoo