Samhain – podstawy

Samhain to jeden z najlepszych programów sprawdzających integralność systemu plików. Dzięki ciekawym rozszerzeniom może pracować w architekturze klient serwer oraz wspomagać systemy wykrywania intruzów (IDSy).

Instalacja i deinstalacja

Program dostępny jest w kilku dystrybucjach w postaci pakietów, jednak najlepiej zainstalować go ze źródeł. Wynika to z faktu iż ma wiele rozszerzeń, czasem wykluczających się, na które musimy zdecydować już w czasie jego kompilacji. ?ródła możemy ściągnąć jedynie ze strony producenta, gdyż program używa silniej kryptografii nie w każdym kraju dozwolonej. Sama procedura kompilacji jest prosta i nie odbiega od standardu: ./configure, make, make install. Jeżeli będziemy chcieli dołączyć dodatkową funkcjonalność (np. logowanie komunikatów do bazy danych MySQL) oczywiście dodamy odpowiednią opcję do polecenia configure np. ./configure with-database=mysql (zostanie to dokładnie wskazane w odpowiednich miejscach artykułu).

Przyjemną rzeczą jest to iż twórcy programu przewidzieli opcje do odinstalowania oprogramowania. Dokonamy tego w katalogu źródeł przy pomocy polecenia ./samhain-install.sh uninstall

Jeżeli zdecydujesz się używać programu na stałe możesz skorzystać z gotowego skryptu startowego. W kilku najbardziej popularnych dystrybucjach (Suse, Debian, Mandrake) działa na pewno, powinien także w pozostałych. Można go zainstalować wydając polecenie: make install-boot.

Klasa standard, czyli pierwsze użycie

W wersji podstawowej (bez żadnych opcji przy kompilacji) program sprawdza jedynie integralność systemu plików na komputerze, na którym działa i raportuje wyniki wpisem do pliku logów oraz mailem do zdefiniowanej osoby. Po kompilacji i instalacji wydajemy polecenie samhain -t init by zainicjować bazę danych (tylko raz). Sprawdzenie systemu wykonamy dzięki poleceniu samhain -t check (automatycznie, jeżeli nie zmieniliśmy tego, przechodzi w tryb pracy demona). Gdy uaktualnimy system, zainstalujemy nowy program albo dokonany zmiany w plikach konfiguracyjnych należy użyć polecania samhain -t update. Spowoduje to uaktualnienie bazy danych, polityki dostępu do plików oraz innych ustawień. Po pierwszym uruchomieniu okaże się iż program zgłasza dużo błędów, należy więc przyjrzeć się plikowi konfiguracyjnemu czyli /etc/samhainrc.

Budowa pliku konfiguracyjnego

Plik konfiguracyjny podzielony jest na bloki. Początek każdego bloku jest określony jego nazwą ujętą w nawiasy kwadratowe. Koniec bloku to po prostu początek następnego. Zasadniczo można podzielić je na trzy grupy: opisujące zasady monitorowania plików, konfigurujące cechy programu oraz konfigurujące specjalne rozszerzenia (np. kontrole przed nieautoryzowanymi modułami jądra).

Do pierwszej grupy należą:

  • Attributes (dla tych plików sprawdzane są jedynie zmiany w prawach dostępu oraz właściciel),

  • Logfiles (ignorowane są zmiany w sygnaturze, rozmiarze pliku oraz czasie dostępu)

  • GrowingLogFiles (ignorowane są zmiany w sygnaturze, zwiększonym rozmiarze pliku oraz czasie dostępu),

  • Ignorenone (nic nie jest ignorowane, nawet próba oddczytania, przydatne przy plikach – pułapkach),

  • ReadOnly (ignorowany jest tylko czas dostępu),

Do każdego z tych bloków można przypisać pojedyncze pliki albo całe katalogi nawet z podkatalogami. Jeżeli do sekcji chcemy przypisać plik poprzedzamy jego nazwę słowem kluczowym file i znakiem równa się. Podobnie jest w przypadku katalogów tylko że inne jest słowo kluczowe: dir. Jeżeli chcemy aby program kontrolował np. do trzeciego katalogu w głąb umieszczamy liczbę przed nazwą i oddzielamy ją slashem np. dir=3/etc. Zobaczmy to na przykładzie fragmentu definicji bloku ReadOnly

[ReadOnly]

dir=3/etc
dir=/usr/X11R6/lib/X11/xmcd/bin
file=/usr/lib/pt_chown
dir=/opt/gnome/bin

Drugą grupę bloków stanowią te kontrolujące zachowanie programu. Pierwszy to EventSeverity określający jak poważne są zdarzenia zdefiniowane wcześniej. Możliwe poziomy to: crit, warn, info, none (nazwy same mówią za siebie). Przykładowo jeżeli chcemy aby modyfikacje plików tylko do odczytu były uznawane za wydarzenia o priorytecie krytycznym (a tak powinno być) to wpis dla tej polityki powinien wyglądać następująco (i tak faktycznie jest):

SeverityReadOnly=crit

Kolejna istotna sekcja to log. Definiujemy w niej jak i co ma być raportowane, czyli jakim kanałem komunikacji program poinformuje o zdarzeniach o określonym poziomie ważności. Jeżeli wybierzemy jakiś poziom wiadomości to wszystkie o wyższym od niego priorytecie też będą wysyłane (nie tyczy się to oczywiście none). Do wyboru mamy: MailSeverity (co wysyłać mailem do zdefiniowanego dalej użytkownika),PrintSeverity (co wyświetlać w czasie pracy programu), LogServerity (co zapisywać do pliku logów), SyslogServerity (co raportować do sysloga) oraz ExportServerity (co wysyłać szyfrowanym połączeniem do serwera logów).

Domyślna konfiguracja to:

MailSeverity=crit
PrintSeverity=info
LogSeverity=warn
SyslogSeverity=none
ExportSeverity=none

Określa ona iż mailem są wysyłane informacje o zdarzeniach krytycznych (np. uruchomienie programu), na konsoli widzimy wszystkie informacje z pracy programu a do pliku logów docierają tylko co ważniejsze zdarzenia, natomiast żadna informacja nie jest logowana do sysloga ani wysyłana na serwer logów.

Pozostałe bloki (czyli z grupy trzeciej) są przydatne gdy korzystamy z dodatkowych możliwości programu. Przyjrzymy się im w dalszej części artykułu, teraz skupmy się na korzystaniu z programu.

poczta i samhain

Program przy starcie wysyła informację (podpisaną sygnaturą) iż został uruchomiony (pierwszego maila nie jesteśmy w stanie sprawdzić czy jest prawdziwy). Następny mail zawiera już klucz sesji (pozwalający sprawdzić prawdziwość następnych maili). Dalej dostajemy komunikaty z działania programu (wyniki monitoringu) a przy zakończeniu programu ostatnią wiadomość iż kończy pracę.

Każda wiadomość jest podpisana sygnaturą. Zawiera ona kodowy ciąg znaków (unikalny dla każdej wiadomości), numer listu oraz identyfikator sesji.

Logi

Logi znajdują się standardowo w pliku /var/log/samhainrc. Każdy wpis rozpoczyna się sekcją soft, następnie mamy linie dotyczące komunikatów programu. Każda linia rozpoczyna się od poziomu ważności wiadomości (przez co możemy sobie łatwo zrobić skrypt określający ilość nowych, pojawiających się wiadomości o określonym stopniu ważności), następnie typu wiadomości, komunikatu oraz

[SOF]
ALERT  :  [2003-06-22T09:22:10+0200] msg=, program=, userid=<0>, path=, hash=, path=, hash=
AD3FFB3FD8492A0DA421CD84CF21CF9D4E4589B365E759DF[2003-06-22T09:22:10+0200]
CRIT   :  [2003-06-22T09:22:12+0200] msg=, path=
AA280E44F5DA0D9D2974ED21F412ACDA0E94E79769047A8F
CRIT   :  [2003-06-22T09:22:12+0200] msg=, path=
BDBC41644AE9E7001B29A7E22AC9AC70924F0A90207A55EE
CRIT   :  [2003-06-22T09:22:12+0200] msg=, path=
560F6EA0D1FEEB3CBB96FD200CC67B2F087F0EACD1705F92
ALERT  :  [2003-06-22T09:24:26+0200] msg=, program=, status=
7139D4C8514DB932A8454216762478B8926A0BBBC0DB5DA7

Dokonania integralności plików dokonamy przy pomocy polecenia samhain -L plik_logów.

[root@localhost log]# samhain -L /var/log/samhain_log
New audit trail ([2003-06-22T09:22:10+0200]), enter key|keyfile: New audit trail, enter key: 950915C65C12E6FC6CF6B8FBEB7655B5698247CF8489B86D[2003-06-22T09:22:10+0200]
PASS:  line=   52 ALERT  :  [2003-06-22T09:22:10+0200] msg=, program=, userid=<0>, path=, hash=, path=, hash=
PASS:  line=   54 CRIT   :  [2003-06-22T09:22:12+0200] msg=, path=
PASS:  line=   56 CRIT   :  [2003-06-22T09:22:12+0200] msg=, path=
PASS:  line=   58 CRIT   :  [2003-06-22T09:22:12+0200] msg=, path=
PASS:  line=   60 ALERT  :  [2003-06-22T09:24:26+0200] msg=, program=, status=

[root@localhost log]# samhain -M /var/spool/mail/admin
Message 000000  Trail 1056265964::127.0.0.1
(unchecked)
Message 000001  Trail 1056265964::127.0.0.1
(passed)
Message 000002  Trail 1056265964::127.0.0.1
(FAILED)
Message 000003  Trail 1056265964::127.0.0.1
(passed)
Message 000004  Trail 1056265964::127.0.0.1
(passed)
Message 000005  Trail 1056265964::127.0.0.1
(passed)
Message 000000  Trail 1056266530::127.0.0.1
(unchecked)
Message 000001  Trail 1056266530::127.0.0.1
(passed)
Message 000002  Trail 1056266530::127.0.0.1
(FAILED)
Message 000003  Trail 1056266530::127.0.0.1
(FAILED)
Message 000000  Trail 1056267207::127.0.0.1
(unchecked)
Message 000001  Trail 1056267207::127.0.0.1
(passed)
Message 000002  Trail 1056267207::127.0.0.1
(FAILED)

Podstawowe rozszerzenia programu

Jak już wcześniej pisałem, program może monitorować logowania użytkowników, ostrzegać o ładowaniu nieautoryzowanych modułów jądra oraz kontrolować występowanie programów z ustawionymi bitami suig/sgid, działaniu w architekturze klient – serwer czy logowań do bazy danych. Przyjrzyjmy się dokładniej tym możliwościom.

Kontrola użytkowników

Jeżeli skompilujemy program z opcją –enable-login-watch pozwoli monitorować to logowania się użytkowników. W tym przypadku sprawdza on plik wtmp i na jego podstawie generuje wpis do logów. Wpis ten ma postać (przykład):

WARN   :  [2003-04-15T11:48:33+0200] msg=, name=, tty=, host=<>, ip=<0.0.0.0>, time=<[2003-04-15T11:48:17+0200]>
5D062D229B3A697C40D7CF5681CF0C030121F33A52903A8F

Aby uzyskać ten efekt należy oczywiście także skonfigurować odpowiednią część pliku konfiguracyjnego. Pierwsza sprawa to włączenie trybu śledzenia logowań użytkowników (LoginCheckActive=1). Następnie ustawiamy poziomu ważności wiadomości dla zdarzenia polegającego na: zalogowaniu się użytkownika (SeverityLogin), wielokrotnym, jednoczesnym logowaniu się (SeverityLoginMulti) oraz jego wylogowaniu (SeverityLogout). Przypominam iż możliwe poziomy to: crit, warn, info, none. Należy również okerślić okres w sekundach, co który odbędzie się kontrola (LoginCheckInterval=5).

Przykładowa konfiguracja to:

[Utmp]
LoginCheckActive=1
SeverityLogin=info
SeverityLoginMulti=warn
SeverityLogout=info
LoginCheckInterval=5

Wykrywanie SUID i SGID

Jak wiadomo, programy z ustawionym bitem SUID lub SGID są jednym z największych niebezpieczeństw dla systemu. Z tego powodu Samhain ma możliwość kontrolowania takich programów (znajduje je i monitoruje). Aby uaktywnić tą funkcję należy przy kompilacji dodać parametr –enable-suidcheck. Należy również ustawić parametry w pliku konfiguracyjnym. Najpierw włączamy tą funkcję w programie (SuidCheckActive=1), następnie ustawiamy okres w sekundach po którym wykonywane jest sprawdzenie (SuidCheckInterval=86400). Jeżeli potrzebujemy, możemy również wyłączyć jeden, określony, katalog z sprawdzania (SuidCheckExclude=katalog). W celu nie dławienia systemu ustalić można ilość sprawdzanych plików w sekundzie testu (SuidCheckFps=ilosc_plikow).

Przykładowe ustawienia:

[SuidCheck]
SuidCheckActive=1
SuidCheckInterval=86400
SuidCheckExclude=/net/localhost
SuidCheckFps=250

Bezpieczeństwo programu

Program w dużym stopniu dba o swoje bezpieczeństwo. Po pierwsze sprawdza czy ścieżka dostępu do pliku konfiguracyjnego jest bezpieczna. Następnie sprawdza sumę kontrolną plików konfiguracyjnych albo ich sygnaturę. Podobnie jest robione w przypadku bazy danych o plikach. Jeżeli te warunki zostaną spełnione program uruchamia się, w przeciwnym przypadku zgłasza błąd. Do ochrony istotnych danych używana jest bardzo skuteczna funkcja haszująca o nazwie TIGER określona przez Ross Anderson i Eli Bihan. Nie musimy się także obawiać skompromitowania serwera poczty, gdyż program posiada wbudowany system SMTP dzięki czemu jest niezależny od działającego na komputerze macierzystym.

Bezpieczeństwo programu możemy zwiększyć uruchamiając go w trybie demona już w momencie włączenia komputera, gdyż pomiędzy dwoma uruchomieniami ktoś może zmienić jego binaria lub go nawet usunąć. Możemy także dodatkowo zainstalować łatę na jądro o nazwie grsecurity, która uniemożliwi zwykłym użytkownikom przeglądanie listy nie swoich procesów.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *