Artikel mit Tag ids
Verwandte Tags
aide gotcha stat backdoor bsd bug bundesregierung checksum cracker debian diff email exploit forensic heise html iphone kernel linux malware patch penetration security sicherheitsluecken snap store trojaner ubuntu xss backup cksum current openbsd stable bash filesharing logfiles login-shell mp3s passwort shadow root server router admins affaere aikido koalition paintball sigh user verbot wahlen bundestrojaner hacken hacker keylogger kiddies killfile lka mail online durchsuchungen phishing ueberwachungForensische Analyse nach einem Angriff
Submitted by Christian Schneider on So, 2007-10-14 03:33
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.
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.
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.
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:
Prinzipiell sind erstmal alle Dateien (Ja. alle Dateien!) gefaehrlich.
So traurig es auch ist, aber fast immer basieren erfolgreiche Angriffe auf Nachlaessigkeit des Admins. Sei es durch Fehlkonfiguration oder durch fehlende Security-Updates.
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:
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 foobarInformationen aus dieser Liste ueber einzelne Programme muss man anschliessend nicht lange per Hand suchen, sondern kann sie sich mit
$ 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
...
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
How to shoot yourself in the foot
Submitted by Christian Schneider on So, 2007-09- 9 15:49
Es ist zwar loeblich wenn jemand AIDE einsetzt und dazu auch den passenden Cronjob hat um sich taeglich einen Report zusenden zu lassen, aber es ist sinnbefreit wenn ein
stat /var/aide.db
folgendes ausgibt:File: `/var/aide.db'
Size: 10236075 Blocks: 20032 IO Block: 4096 regular file
Device: 803h/2051d Inode: 1769945 Links: 1
Access: (0666/-rw-rw-rw-) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2007-09-09 16:04:57.000000000 +0200
Modify: 2007-09-09 16:07:14.000000000 +0200
Change: 2007-09-09 16:07:14.000000000 +0200
Last ten comments: