doc/pl/rootcheck.txt

   1 Rootkit detection techniques used by the OSSEC HIDS
   2 by Daniel B. Cid, daniel.cid@gmail.com
   3
   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).
  12
  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.
  19
  20
  21 Kroki wykonywane przez rootcheck w celu wykrycia rootkitów:
  22
  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.
  33
  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.
  39
  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
  43    dotąd rootkity.
  44
  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
  49    również są sprawdane.
  50
  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.
  56
  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.
  61
  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.
  66
  67 EOF