Hostowe systemy wykrywania intruzów (HIDS)

Jeśli nasze być albo nie być zależy od ekstremalnie wysokiego bezpieczeństwa, możemy schować komputery w bunkrze i unikać połączeń z siecią zewnętrzną. Zwykle jednak, dopóki nie mamy nic wspólnego z bronią jądrową, każda działalność wymaga takiego dostępu, za cenę nieustannego obserwowania, czy ktoś nie próbuje przeniknąć do naszej sieci.

Do ochrony sieci specjaliści IT wykorzystują różne narzędzia – od zapór sieciowych po zaawansowane systemy wykrywania włamań (patrz: akapit „NIDS, IPS, HIDS”), na przykład – nieco zapomniane – hostowe systemy wykrywania intruzów (ang. Host-Based Intrustion Detection System, HIDS) wykonujące testy na komputerze hosta w celu wykrycia śladów po włamaniach.

HIDS-y działają w oparciu o założenie, że każdy intruz zostawia po sobie ślady, znane w kryminalistyce jako zasada wzajemnej wymiany, zgodnie z którą, każda interakcja powoduje zmianę. Cała sztuka polega na wykryciu zmiany i wyciągnięciu z niej odpowiednich wniosków [1].

Niegdyś HIDS-y stanowiły pierwszą linię obrony; obecnie firmy wybierają większe i bardziej kompleksowe rozwiązania. Proste narzędzie spełniające jednak konkretne zadanie to często właściwy dodatek do zestawu narzędzi administratora. Do wykrywania śladów włamań, typowe HIDS-y wykorzystują śledzenie zmian w systemie plików, analizę plików dziennika albo wykrywanie złośliwego oprogramowania.

Artykuł opisuje kilka popularnych narzędzi HIDS, reprezentujących każde z tych podejść. Omawia też łączące te techniki rozwiązania typu „wszystko w jednym”.

NIDS, IPS, HIDS

Gdy do domu dostaje się włamywacz, uruchamia się głośny alarm. W świecie komputerów sieciowy system wykrywania włamań (NIDS) alarmuje nas po cichu i pomaga wykryć lub przechwycić intruza.

Systemy zapobiegania włamaniom (ang. Intrusion Prevention System, IPS) to inna grupa narzędzi, które automatycznie podnoszą most, zanim intruz zdąży przejść na drugą stronę – blokują dostęp lub przejmują kontrolę. A obserwując postępowanie hakerów, możemy uczyć podnoszenia bezpieczeństwa systemów.

Po włamaniu do lokalu jest za późno, by się przyglądać splądrowanym szafom i rozbitym szybom, ale w świecie wirtualnym właśnie to wykonują hostowe systemy wykrywania intruzów. Nie są one zbyt popularne w dzisiejszych sieciach, a to dlatego, że współcześni hakerzy rzadko zostawiają po sobie widoczne ślady. Bez HIDS-a możemy nigdy się nie dowiedzieć, że mamy w systemie nieproszonych gości. Proste narzędzie wykrywające zmiany zaprowadzone przez intruza sugeruje również, gdzie szukać złośliwego oprogramowania.

Zmiany w systemie plików

Hakerzy czerpią niezwykłą przyjemność z ataków za pośrednictwem przepełnienia bufora. Gdy znajdą się w środku, praca staje się dużo bardziej monotonna. Intruz zaczyna od zainstalowania rootkita, który zapewnia mu łatwy dostęp. Aby go skonfigurować, zapisuje program na systemie i uruchamia go, co możemy zauważyć, uruchamiając ps; otwarte porty sieciowe pozwala wyświetlić netstat. Intruz musi zapobiec pojawianiu się programu w danych wyjściowych typowych narzędzi administracyjnych. Zwykle zastępuje pliki wykonywalne standardowych narzędzi administracyjnych takich, jak ps i netstat, ich sfałszowanymi wersjami. Bardziej nowoczesne – na przykład rootkity ingerujące w jądro systemu – instalują osobny moduł jądra, który blokuje widoczność ich procesów.

Możemy wykrywać narzędzia linuksowe podmienione przez intruzów na podstawie czasu modyfikacji i utworzenia, rozmiaru plików lub zmienionych i-węzłów. W praktyce, nie korzystając ze zautomatyzowanego systemu bezpieczeństwa, nigdy nie zauważymy tych zmian, ponieważ ich ręczne namierzanie jest zbyt czasochłonne.

Klasyczne HIDS-y, jak Tripwire [2], Aide [3] czy nowszy Afick [4] – wykrywają te zmiany automatycznie. Wykorzystują w swoich plikach konfiguracyjnych bardzo podobną składnię. Napisany w Perlu Afick jest kompatybilny z Tripwireʼem. Wszystkie przygotowują listy plików krytycznych wraz z datami modyfikacji i utworzenia, rozmiarami, numerami i-węzłów i uprawnieniami. Porównywanie tych parametrów z wynikami późniejszych testów pomaga wykrywać ataki.

Wprawni hakerzy tworzą jednak złośliwe oprogramowanie tak, aby rozmiary plików były identyczne; ustawiają przy użyciu touch te same czasy dostępu, zachowują uprawnienia do plików i dodają zmodyfikowane pliki do tych samych i-węzłów (cat newps > ps). HIDS-y jednak sprawdzają nie tylko widoczne dane, ale także wartości skrótu plików.

Aide umożliwia nawet stosowanie wielu procesów haszujących równolegle, które jeszcze bardziej zmniejszają prawdopodobieństwo kolizji – na przykład dla MD5 wynosi ono mniej niż 2⁶⁴, a dla SHA-256 – mniej niż 2¹²⁸. Prawdopodobieństwo kolizji w obu jest więc niższe od 2¹⁹² – to około 1,5×10⁵⁸.

Aide stanowi dobry przykład HIDS-a, który wykrywa zmiany w plikach. Na systemach opartych na Debianie instalujemy go za pomocą:

apt-get install aide

Konfigurację możemy dostosować do swoich potrzeb. W tym celu edytujemy plik /etc/aide.conf, a w niektórych przypadkach także /etc/aide/aide.conf, aby Aide miał na oku wszystkie istotne programy i pliki konfiguracyjne.

W pliku aide.conf są również nasze definicje makr. Przestudiowanie ich oszczędzi nam wiele pracy przy pisaniu reguł. Aide wykrywa nowo utworzone pliki – na przykład będące wynikiem zrzutu rdzenia, powodowanego czasami przepełnieniem bufora (wyłączonego na większości nowych dystrybucji Linuksa).

Konfiguracja domyślna obejmuje zestawy reguł: dla plików dziennika i pozwalające określić status systemu. Zawiera też dobry opis, jak stworzyć własny zestaw reguł.

Do aktualizacji konfiguracji Aide używa update-aide.conf; aby przeprowadzić test składni, możemy wpisać aide -D. Polecenie:

aideinit -y -f

inicjalizuje bazę danych. Następnie Aide oblicza wartości skrótu – podczas testów redakcyjnych trwało to na maszynie wirtualnej około dziesięciu minut. Ponieważ zadanie crona jest instalowane automatycznie podczas instalacji narzędzia, sprawdza zmiany i wysyła je mailem do konta root. Aide może też zapisać dane wyjściowe pod dowolnym adresem URL (wpis aide.conf report_url).

Aide na tyle naśladuje poprzedników, że pozwala z łatwością przenieść tę konfigurację do Tripwireʼa.

Piki logów

Do codziennych zadań administratora należy sprawdzanie plików dziennika. Któryś z procesów niespodziewanie się zakończył? Został uruchomiony ponownie – przez program nadzorujący lub hakera starającego się ukryć po sobie ślady? A może widać inne ślady włamania? Regularne sprawdzanie systemu pozwoli nam wykrywać problemy. Na szczęście istnieją narzędzia wspomagające nas w walce z naszym lenistwem; analizują pliki dziennika, filtrują potencjalnie krytyczne wiadomości i wysyłają wyniki.

Do analizy przydaje się Logsentry [5] (dawniej Logcheck) – prosty, ale kompletny system wykrywania intruzów złożony w całości ze skryptów powłoki i plików konfiguracyjnych, oszczędza nam zastanawiania się nad poprawnością poleceń grep do wykrywania ataków na podstawie analizy plików dziennika. Logsentry pobieramy i instalujemy go przy użyciu:

tar -xzf logcheck-1.3.17.tar.gz
cd logcheck-1.3.17
make linux

Warto utworzyć zadanie crona do regularnego sprawdzania logów, pisząc z uprawnieniami administracyjnymi root:

crontab -e

aby otworzyć do edycji tabelę programu cron (crontab). Wiersz:

0 * * * * /usr/local/etc/logcheck.sh

wyzwala co godzinę skrypt testowy logcheck.sh. Jeśli chcemy sprawdzić więcej niż trzy pliki dziennika, modyfikujemy wiersz 172 logcheck.sh za pomocą wpisu z przykładu. Logcheck definiuje swoje reguły w wielu plikach konfiguracyjnych w /etc/logcheck.

Wszystko w logcheck.hacking pojawia się u góry wiadomości wysyłanej do użytkownika root. Nieco niżej znajduje się logcheck.violations; do wiadomości trafia wszystko, co niewykluczone przez ignore – w tym Unusual system events. Bardzo ważne, abyśmy się upewnili, że wpis logcheck.ignore nie zostaje pusty, w przeciwnym razie narzędzie wszystko zignoruje.

Logsentry i podobne programy pozwalają nam oszczędzić nieco pracy, ale to w zasadzie wszystko. Chcąc regularnie sprawdzać pliki dziennika, powinniśmy napisać prosty skrypt filtrujący niekrytyczne wiadomości. Logsentry działa dokładnie na odwrót. Po skonfigurowaniu powinniśmy dokładnie wiedzieć, jak wyglądają wiadomości krytyczne. Narzędzie filtruje tylko znanych, a nie potencjalnych podejrzanych.

Ponadto sprawdzanie plików dziennika nie jest do końca wiarygodne. Wprawny intruz czyści je po sobie, Logsentry nic więc nie wykryje. Prawdopodobnie intruzowi wystarczy czasu, aby posprzątać. Zasadniczo narzędzie wykrywające intruzów poprzez sprawdzanie plików dziennika pozostaje zaledwie użyteczne, jeśli jest uruchamiane z innymi systemami.

Wykrywanie złośliwego oprogramowania

Po wykazaniu zainfekowania systemu poprzez analizę plików dziennika powinniśmy poszukać złośliwego kodu. To zadanie dla skanerów malware, dostępnych również na Linuksa, jak na przykład Clam AV [6]. Trudno ustalić granicę między skanerami złośliwego oprogramowania i HIDS-ami; większość skanerów antywirusów wykrywa ataki na podstawie sygnatur i heurystyki.

Programy takie, jak Chkrootkit [7] i (napisany w Perlu) Rkhunter [8] wykorzystują bardziej szczegółowe podejście, ale ich ostatnie aktualizacje są z 2014 roku. Oba możemy zainstalować, wpisując z uprawnieniami administracyjnymi root:

apt-get install chkrootkit
apt-get install rkhunter

Chkrootkit to skrypt powłoki, który wykrywa rootkity na podstawie różnych parametrów; pozwala się uruchomić bez żadnych parametrów. Między innymi używa strings do wykrywania podejrzanych ciągów, sprawdza lastlog, aby zobaczyć, czy usuwane były wpisy oraz dane wyjściowe z ps, i wyszukuje brakujące informacje w /proc/ (Rysunek 1).

Podejście wykorzystywane przez Rkhuntera jest bardziej zaawansowane. Nazwa pliku konfiguracyjnego to /etc/rkhunter.conf (podczas testów redakcyjnych instalacja Rkhutera na Ubuntu sprawiała drobne problemy; patrz: akapit „Łatka dla Ubuntu”).

Aby zainicjalizować Rkhuntera i sprawdzić system pod kątek rootkitów i podejrzanych plików, piszemy:

rkhunter --propupd
rkhunter --check

Rysunek 1 pokazuje, co Rkhunter uważa za potencjalny atak. Zarówno Chkrootkita, jak i Rkhutera możemy uruchamiać codziennie przy użyciu zadania crona, włączając te narzędzia do naszego HIDS-a.

Łatka dla Ubuntu

Podczas testów redakcyjnych instalacja Rkhutera na Ubuntu sprawiała drobne problemy. Program wymagał lwp-request, mimo że nie był on zainstalowany. Udało się to zmienić:

cpan Mock::LWP::Request

Perl jednak zapisał narzędzie w /usr/local/bin/lwp-request, co oznacza konieczność ręcznego edytowania ścieżki /usr/bin/ w pliku konfiguracyjnym.

Wszystko w jednym

Zamiast kilku osobnych narzędzi możemy użyć takiego, które łączy wszystkie funkcje, jak Samgain [9] i Ossec [10]. Oba mają tryb agenta, w którym na zdalnych systemach uruchamiane są czujniki przekazujące dane do komputera centralnego w celu poddania ich analizie.

Możemy też uruchomić równolegle wiele HIDS-ów, gdyż nie wchodzą sobie w drogę. Na przykładTripwire, Aide, Afick, Samhain i Ossec mogą działać obok siebie na tym samym komputerze i monitorować się nawzajem. Powinniśmy jednak zachować ostrożność – aktualizacje pojawiające się w tym samym czasie mogą łatwo spowodować wywoływanie przez system poleceń w nieskończoność.

Szczegółowe instrukcje dla Samhaina [11] i Osseca [12] są w Sieci. Używanie tych narzędzi nie jest specjalnie trudne, jeśli wiemy, jak działają poszczególne komponenty.

Każdy dodatkowy wiersz kodu podnosi ryzyko krytycznych błędów. Na przykład opublikowane w czerwcu 2015 roku wersje Osseca od 2.7 do 2.8.1 zawierały problem umożliwiający eskalację przywilejów (CVS-2015-3222) [13]. Poprawka ukazała się w wersji 2.8.2. Niezależnie od narzędzia i wersji w ramach zarządzania HIDS-em powinniśmy śledzić publikowane poprawki bezpieczeństwa – nie chcemy przecież, aby narzędzia bezpieczeństwa powodowały nowe luki.

Na tropie złodzieja

Istnieją różne rodzaje hostowych systemów wykrywania intruzów z różnymi funkcjami, które często wzajemnie się uzupełniają. Dostępne są też gotowe pakiety łączące wszystkie wymagane funkcje. Dzienniki HIDS-ów dają nam w razie ataku ważne informacje i pozwalają zrozumieć działania intruza, załatać dziury, a w niektórych przypadkach nawet wymierzyć sprawiedliwość.

Wiele narzędzi osiąga kres możliwości, gdy intruz ma uprawnienia administracyjne root i dość czasu, aby wyłączyć mechanizmy bezpieczeństwa i posprzątać pozostawione ślady. Ponieważ HIDS-y wykrywają wyłącznie skutki prób ataku, powinny stanowić jeden z wielu elementów architektury bezpieczeństwa, za dopełnienie mając system wykrywania intruzów, zapory sieciowe, restrykcyjne uprawnienia użytkowników, regularne audyty bezpieczeństwa systemów i podnoszenie świadomości użytkowników.

Info

1. Zasada Locarda: https://en.wikipedia.org/wiki/Locard%27s_exchange_principle
2. Tripwire: http://sourceforge.net/projects/tripwire/
3. Aide: http://aide.sourceforge.net
4. Afick: http://afick.sourceforge.net
5. Logsentry: http://sourceforge.net/projects/sentrytools/files/logcheck%201.x/logcheck-1.1.1/
6. Clam AV: http://www.clamav.net/index.html
7. Chkrootkit: http://www.chkrootkit.org
8. Rkhunter: http://rkhunter.sourceforge.net
9. Samhain: http://www.la-samhna.de/samhain/
10. Ossec: http://www.ossec.net
11. Instrukcja Samhaina: http://www.la-samhna.de/samhain/MANUAL-2_4.pdf
12. Instrukcja Osseca: http://ossec-docs.readthedocs.org/en/latest/manual/installation/index.html
13. CVS-2015-3222: http://www.openwall.com/lists/oss-security/2015/06/11/1

— Tobias Eggendorfer