1 Rootkit detection techniques used by the OSSEC HIDS
2 by Daniel B. Cid, daniel.cid@gmail.com
4 Zaczynając od wersji 0.4, OSSEC HIDS dokonuje wykrywania rootkitów na
5 każdym systemnie na którym jest zainstalowany agent. Mechanizm
6 wykrywania rootkitów (rootcheck) jest wykonywany co X minut
7 (wyspecyfikowane przez użytkownika - domyśnie co dwie godziny) w celu
8 wykrycia zinstalowanych rootkitów. Używany razem z analizatorem logów
9 oraz mechanizmem sprawdzania integralności, staje się bardzo wydajnym
10 systemem monitorowania (OSSEC HIDS dokonuje analizy logów i sprawdzania
11 integralności od wersji 0.1).
13 Inną właściwością dołączoną do wersji 0.4 jest automatyczne rozsyłanie
14 sygnatur wykrywania rootkitów do wszystkich agentów przez serwer.
15 Redukuje to ilość obowiązków administratora. Serwer z agentami utrzymuje
16 kontakt co 10 minut. Dodatkowo jeśli serwer zostanie zaktualizowany
17 nowymi sygnaturami, przekazuje je wszystkim skonfigurowanym agentom.
18 Aby uzyskać więcej informacji zajżyj do dokumentacji zarządzania.
21 Kroki wykonywane przez rootcheck w celu wykrycia rootkitów:
23 1- Czyta plik rootkit_files.txt, który zawiera sporą baze danych o
24 rootkitach i używanych przez nie plików. Próbuje wykonać: stats,
25 fopen i opendir na każdym z takich plików. Używa wszystkich tych
26 wywołań systemowych, ponieważ istnieją rootkity pracujące na poziomie
27 jądra, które ukrywają pliki przed niektórymi wywołaniami. Im więcej
28 użyjemy wywołań, tym lepsza będzie detekcja. Metoda jest podobna do
29 reguły anty-virusa, potrzebuje nieustanntgo uaktualniania. Szanse
30 detekcji rootkita którego nie ma (false-positive) są małe, za to już
31 szanse nie wykrycie rootkita (false-negative) rosną wraz z
32 modyfikacjami rootkitów.
34 2- Czyta plik rootkit_trojans.txt który zawiera baze danych sygnatur
35 plików modyfikowanych na trojany przez rootkity. Technika modyfikacji
36 binariów na wersje z trojanami jest powszechnie używana przez
37 większość dostępnych rootkitów. Nastepująca metoda nie wykrywa
38 rootkitów poziomu jądra ani żadnych jeszcze nie znanych.
40 3- Skanuje katalog /dev wyszukując anomali. /dev powinien tylko zawierać
41 pliki urządzeń oraz skrypt Makedev. Duża część rootkitów używa
42 katalogu /dev w celu ukrycia plików. Ta metoda może wykryć nieznane
45 4- Skanuje cały system plików szukając niespotykanych plików oraz
46 tych z podejrzanymi uprawnieiami. Pliki użytkownika root z
47 możliwością zapisu dla innych są bardzo niebezpieczne, dlatego
48 rootkit wyszukuje takie. Pliki z ustawionym suid oraz ukryte katalogi
51 5- Szuja ukrytych procesów. Używa getsid() oraz kill() do sprawdzenia
52 czy dany pid jest używany. Jeśli dany pid jest używany, a "ps" nie
53 widzi go, wskazuje to na obecność rootkita poziomu jądra lub
54 zmodyfikowaną wersję "ps". Weryfikuje także wyniki kill i getsid,
55 które powinny być identyczne.
57 6- Wyszukuje ukrytych portów. Używa bind() do sprawdzenia każdego portu
58 tcp i udp w systemie. Jeśli nie możemy wykonać bind na danym porcie
59 (czyli jest używany), a "netstat" go nie pokazuje, to prawdopodobnie
60 mamy zainstalowanego rootkita.
62 7- Skanuje wszystkie interfejsy w systemnie i wyszukuje te z włączonym
63 trybem "promisc". Jeśli interfejs jest w trybie "promisc", "ifconfig"
64 tego powinien pokazać to, jeśli nie prawdopodobnie mamy
65 zainstalowanego rootkita.