• Zielgruppen
  • Suche
 

System-Check eines kompromittierten Unix-Systems

Es scheint immer ratsam, vom kompromittierten System zunächst ein Komplettbackup anzulegen. Dies kann hilfreich sein, falls bei der Suche Spuren und Daten zerstört werden.

Beginnen Sie Ihre Recherche damit, dass Sie die Logfiles nach Verbindungen von und zu unüblichen Internet-Adressen und nach ungewöhnlichen Systemaktivitäten durchsuchen. Untersuchen Sie z.B. das "last"-Log, das Prozess-Accounting, alle Logs, die vom Syslog geschrieben wurden bzw. weitere Sicherheits-Logs. Werden auch Logs auf andere Systeme geschrieben (Syslog-Server), so untersuchen Sie auch diese. Berücksichtigen Sie jedoch, dass die Informationen aus den Logfiles nur dann zuverlässig sind, wenn diese "Append-Only" geschrieben wurden, d.h. nicht nachträglich modifiziert werden konnten. Viele Hacker verändern diese Dateien, um Ihre Aktivitäten zu verschleiern.

Haben Sie Veränderungen entdeckt, versuchen Sie nun den Ausgangsrechner des Hackers zu ermitteln, indem Sie Informationen mittels der folgenden Kommandos sammeln:

  • who, w, last, lastcomm, netstat, snmpnetstat (oder systemabhängig ähnliche Kommandos)
  • cat /var/log/sulog
  • Router Informationen mit z.B. netstat -rn
  • /var/adm/messages, /var/adm/syslog{.dated} (Viele Hacker senden E-Mails zu Ihren Home-Accounts)
  • cat /var/log/httpd-access.log bzw. cat /var/log/httpd-error.log (WWW Logs und Fehlermeldungen)
  • cat /var/log/xferlog (Zugriffe auf lokalen FTP-Server, falls vorhanden)
  • syslog allgemein (sendet Logs zu anderen Rechnern.)
  • TCP-wrapper-Logs
  • Rufen Sie finger auf für alle lokalen Benutzer und prüfen Sie, woher diese sich zuletzt eingelogged haben.
  • Rufen Sie ps auf, um festzustellen, welche Prozesse gerade laufen.
  • Überprüfen Sie History-Files von shells, wie z.B. .history, .rchist und ähnliche Dateien.

Bitte beachten Sie bei der Weitergabe von Informationen, dass personenbezogene Daten entsprechend den Gesetzen zum Schutz personenbezogener Daten nicht an Unbefugte weitergegeben werden dürfen.

Beachten Sie hierbei, dass Kommandos wie who, w, last und lastcomm auf andere Dateien wie /var/adm/pacct, /usr/adm/wtmp und /etc/utmp zurückgreifen, um Informationen zu liefern. Einige Einbruchs-Tools sorgen durch Austausch dieser Dateien dafür, dass Einbruchsversuche nicht protokolliert oder sogar gelöscht werden. Speichern Sie alle Auffälligkeiten in einem speziellen Directory z.B. /ist.

Zu diesem Zeitpunkt kann es auch sinnvoll sein, die Netzverbindung des Hackers eine Zeit lang über einen Protokollanalysator (Sniffer) mitzuschneiden, um hierdurch weitere Informationen zu sammeln.

2. Der Rechner sollte nun vom Netz genommen werden, um weitere Zugriffe des Hackers zu verhindern. Sollte der Hacker feststellen, daß seine Anwesenheit erkannt wurde, könnte er ansonsten versuchen durch ein Kommando wie "rm –rf /" alle Informationen über seine Zugriffe zu löschen.

Vergleichen Sie die System-Binär-Dateien mit den Originalen. Oft werden von Einbrechern Unix-Programme, wie login, su, telnet, netstat, ifconfig, ls, ps, find, du, df, libc, sync und andere in /etc/inetd.conf referenzierte Binär-Dateien sowie weitere kritische Netzwerk- und Systemprogramme und Shared Object Libraries, wie z.B. /usr/etc/in.* und /lib/libc.so.* (auf SUN), modifiziert. Vergleichen Sie diese Dateien mit "guten" Kopien, wie z.B. denen auf den Original-Distributionsmedien. Legen Sie hierzu ein Unterverzeichnis /util an und speichern Sie dort Original-Hilfs- und Systemprogramme wie ls, find, ifconfig, ps, md5 bzw. md5sum. Vergleichen Sie nun die MD5-Prüfsummen der Orginale mit den im System installierten Programmen.

Seien Sie vorsichtig mit BackUp-Dateien, da diese bereits modifiziert worden sein können, bzw. Trojanische Pferde enthalten können.

Trojanische Pferde können die gleiche Standard-Checksum und den gleichen Zeitstempel wie die Original-Dateien enthalten. Daher ist das Standard-UNIX-Kommando sum nicht ausreichend, diese zu erkennen. Ausreichend ist die Benutzung von cmp, MD5, Tripwire und anderer kryptographischer Checksum -Tools, insofern diese ausreichend gesichert wurden. Ferner kann man beispielsweise den durch MD5 oder Tripwire generierten Output mit PGP signieren.

Eine weitere bekannte Methode ist, allgemein benutzte Programme durch Setzen des SUID-Bits oder SGID-Bits zu modifizieren, um Root-Zugriff zu erlangen. Alle SUID- und SGID-Programme können gefunden werden mittels:

find /all_filesystems -type f –perm –2000 -xdev

–exec ls -lad { }\; find /all_filesystems -type f

–perm –4000 -xdev –exec ls -lad { }\;

Hierbei, wie auch bei den weiter unten folgenden Kommandos, müssen diese für alle lokalen Filesysteme aufgerufen werden. Alternativ kann die Option -xdev weggelassen werden und als Filesystem das Root-Directory benutzt werden. Dann sollten aber keine Filesysteme gemountet sein, da diese ansonsten mit durchsucht werden.

Es könnte weiterhin versucht worden sein, auf Block-, Character- oder Geräte-Dateien zuzugreifen. Mit dem Kommando

find /all_filesystems -type b -o -type c -perm -2000 -xdev

-exec ls -lad { }\; find /all_filesystems

-type b -o -type c -perm -4000 -xdev -exec ls -lad { }\;

kann man diese auflisten und überprüfen, ob die Zugriffsrechte in Ordnung sind. Besonders verdächtig sind Geräte-Dateien, die nicht im Directory /dev liegen.

3. Stellen Sie ebenfalls sicher, dass kein Netzwerk-Monitoring Programm (Sniffer) unauthorisiert auf dem Rechner benutzt wird. Führen Sie hierzu das Kommando ifconfig aus und schauen sie nach, ob in der Ausgabe 'PROMISCOUS' vorkommt. Es besteht dann der dringende Verdacht, daß dieser Rechner zum Sniffern verwendet wird.

Für weitergehende Informationen verweisen wir auf das CERT

4. Überprüfen Sie alle Dateien, die von cron oder at ausgeführt werden, auf vorhandene Backdoor-Einträge. Überprüfen Sie ebenfalls alle direkt oder indirekt von cron oder at aus referenzierten Dateien. Diese dürfen nicht world-writable sein.

5. Sehen Sie in inetd.conf nach, ob neue Dienste aktiviert wurden (TCP und UDP) und überprüfen Sie von einem anderen System aus, welche Ports antworten. Dies kann z.B. für TCP geschehen mit dem Kommando telnet ip-adresse port .

6. Untersuchen Sie /etc/passwd, /etc/shadow bzw. /etc/security/passwd (System-abhängig) auf dem System und überprüfen Sie Modifikationen in dieser Datei, wie z.B. neue Accounts, Accounts ohne Passwort oder UID-Änderungen zu bestehenden Accounts. Überprüfen Sie die System- und Netzwerk-Konfigurations-Dateien auf unberechtigte Einträge. Schauen Sie nach "+" Einträgen und nicht lokalen Rechnernamen in /etc/hosts.equiv, /etc/hosts.lpd und in allen .rhosts Dateien (insbesondere von root, uucp, ftp und anderen System-Accounts). Diese Dateien dürfen nicht world-writable sein. Stellen Sie ferner sicher, daß diese Dateien auch bereits früher existiert haben und nicht erst seit dem Hacker-Einbruch.

7. Untersuchen Sie alle Datei-Strukturen auf .rhosts- und .forward-Dateien und überprüfen Sie deren Inhalt (insbesondere auf speziellen Accounts wie: news, sundiag, sync). Sollte eine .rhost Datei einen Eintrag "+ +" enthalten, so ist weltweiter Zugriff über diesen Account möglich. Entsprechend unseren Empfehlungen sollte der .rhost-Mechanismus überhaupt nicht genutzt werden. Eine im Root-Directory installierte .forward-Datei kann dazu führen, daß kritische Dateien modifiziert werden können. Das folgende Kommando erkennt dies:

find /all_filesystems -name .rhosts -ls -o -name .forward -ls

8. Suchen Sie ebenfalls nach Dateien, die in der kritischen Zeitspanne erstellt oder modifiziert wurden. Hierzu kann beispielsweise das Kommando

find /all_filesystems -ctime -2 -ctime +1 -ls

benutzt werden, das alle Dateien listet, die 1 bis 2 Tage alt sind.

9. Auch die Dateien .login, .logout, .profile, .cshrc sollten untersucht werden (zumindest bzgl. Modifikationsdatum). Achten Sie darauf, daß spezielle Accounts wie news, sundiag, sync etc. keine ausführbare Login-shell besitzen (Also z.B. /bin/false ausführen, nicht aber /bin/sh).

10. Weiter sollten keine Directories mit Dateien existieren, deren Namen die Form '. ' (dot space), '...' (dot dot dot), '.. ' (dot dot space) oder '..^G' (dot dot control-G) haben (Beachte: Blank oder Kontrollcharakter am Ende). Diese existieren oft in den Verzeichnissen /tmp, /var/tmp, /usr/spool/* und anderen öffentlich schreibbaren Directories. Schauen Sie überall in Ihrem System nach solchen unüblichen und versteckten Dateien z.B. mittels

find /all_filesystems -name ".. " -print -xdev | cat -vet find

/all_filesystems -name ".*" -print -xdev | cat -vet find

/all_filesystems -name "..*" -print -xdev | cat -vet

Ebenso sind Dateien mit '.xx' und '.mail' suspekt.

11. Stellen Sie sicher, daß Ihre NFS-Exports nicht weltweit schreibbar sind. NFSwatc, verfügbar über harbor.ecn.purdue.edu:/pub/davy, ein Programm von David Curry, kann alle stattfindenden NFS-Transaktionen loggen. Führen Sie "showmount -e" aus, um festzustellen, ob nur die gewünschten Exports existieren. Es gibt einige Fehler im nfsd, die dazu führen, daß die Access -Listen ignoriert werden, wenn eine bestimmte Größe der Tabellen überschritten wird (z.B. 256 Byte). Überprüfen Sie auch, was Sie importieren, benutzen Sie das nosuid flag bzw. nodev flag, wo immer möglich.

12. Kopieren Sie /etc/passwd an einen sicheren Ort (am besten Offline). Ändern Sie dann alle Root-Passwörter (nachdem Sie sichergestellt haben, daß su und passwd keine vom Hacker abgelegten Trojanischen Versionen sind). Ändern Sie alle (!!) Passworte, indem Sie in /etc/passwd in das Passwort-Feld "*" eintragen. Sollte der Hacker eine Kopie Ihrer Passwort-Datei haben, so wird er früher oder später einige davon entschlüsseln. Ferner könnte er einige Passwörter von Benutzern geändert haben, die sich nur sehr selten einloggen. Überprüfen Sie auf einem NIS-Server auch die Dateien, die zur Bildung der NIS-Maps benutzt werden.

13. Um die Maschine in einen bekannten und gesicherten Zustand zu bringen empfehlen wir das Betriebssystem neu zu installieren.

14. Teilen Sie alle ermittelten Daten über Aktivitäten, dem Sicherheits-Team mit, damit diese an zentraler Stelle gesammelt und ausgewertet werden können.