Monitoring bezpieczeństwa Linux: integracja auditd + OSSEC cz. I

Artykuł poświęcony jest integracji dwóch znanych i sprawdzonych narzędzi opensource do monitoringu bezpieczeństwa: oprogramowania do audytu zmian w systemie Linux (auditd) i Host IDS OSSEC. Celem artykułu jest poznanie ograniczeń i wykorzystanie zalet obu tych narzędzi tak, by działając w tandemie umożliwiły detekcję podejrzanych zachowań na poziomie wywołań systemowych (syscalls).

Stosując porównania do taktyki wojskowej para auditd+OSSEC będzie u nas realizować zadania pary snajperskiej, gdzie obserwatorem będzie auditd, a zadanie ogniowe realizować będzie OSSEC za pomocą modułu Active Response. Zaczynamy zatem trening i polowanie na intruzów…

Po co monitorować wywołania systemowe?

Wywołania systemowe (syscalls) to żądania kierowane do jądra systemu operacyjnego, które powodują wykonanie uprzywilejowanych procedur. Podstawowe syscall’e to:

• open() – odczyt danych
• write() – zapis danych
• open()- otwarcie pliku
• fork() – utworzenie nowego procesu
• exec() – uruchomienienie programu

i wiele innych

Jak widzimy monitorowanie wywołań systemowych związnych z uruchamieniam nowych programów, odczytu i/lub zapisu plików może dostarczyć obrońcom informacji o działaniach intruzów w zaatakowanych systemach  np. za pomocą luki 0-day. Mimo tego, że doszło do włamania to, my jako obrońcy wcale nie jesteśmy jeszcze na straconej pozycji pod warunkiem , że zaimplementowaliśmy odpowiedni system monitoringu oraz procedury, które pozwolą nam na wykrycie i powstrzymanie trwającego ataku. Atakujący po udanym włamaniu będzie najczęście starał się zwiększyć swoje uprawnienia, rozpoznawał zaatakowany system od środka, wykradał dane, uruchamiał złośliwe oprogramowanie. Takie czynności w większości przypadków zostawiają ślady, istotą działań zespołów bezpieczeństwa jest wyłuskiwanie tych śladów i podjęcie tropu.

Do monitoringu powyższych czynności zaproponuję auditd, czyli oprogramowanie które na poziomie jądra Linuxa jest w stanie prowadzić audyt systemu z uwzględniem wywołań systemowych.

Obserwator: auditd

Instalację auditd można przeprowadzić za pomocą menadżera pakietów np.

Debian,Ubuntu

Fedora, CentOS, RHEL (zwykle auditd powinien być zainstlowany)

Pakiet auditd zawiera szereg binarek, które służą do zarządzania demonem auditd i wyszukiwania oraz analizy zarejestrowanych zdarzeń:

• auditctl: narzędzie do bieżącej konfiguracji demona auditd, sprawdzania statusu i uruchomionych reguł
• audispd: daemon to multiplikowania rejestrowanych zdarzeń do innych programów agregujących logi
• aureport: narzędzie do szybkich raportów generowanych na podstawie logu (auditd.log)
• ausearch: narzędzie do wyszukiwania zdarzeń z logu (auditd.log)
• autrace: narzędzie do analizy interakcji programów z jądrem
• aulast: narzędzie o funkcjonalności polecenia last ale wykorzystujące log auditd.log
• aulastlog: narzędzie o funkcjonalności polecenia lastlog ale wykorzystujące log auditd.log
• ausyscall: mapowanie ID wywołania systemowego na nazwę
• auvirt: informacje audytujące dotyczące wirtualnych maszyn

uruchomienie audytu przy każdym starcie systemu (Fedora, CentOS, RHEL)

Wprowadzamy obserwatora do gry:

i sprawdzamy stan usługi

Na początku auditd nie zawiera żadnych reguł, co możemy sprawdzić każdorazowo poprzez użycie przełącznika –l

Czas postawić zadania naszemu obserwatorowi, czyli piszemy reguły. Reguły możemy dopisywać do pliku audit.rules (najcześciej w lokalizacji /etc/audit) lub za pomocą narzędzia auditctl z przełącznikiem -k.

Poniżej umieściłem kilka reguł, które pozwolą m.in. monitorować wszystkie polecenia wykonywane w systemie operacyjnym, zastawić pułapkę na intruzów, którzy chcieliby nie tylko zmodyfikować pliki systemowe ale „tylko” je odczytać, możemy być również bardziej granularni i włączać/wyłączać reguły monitorujące dla użytkowników o określonym UID, programów, plików, katalogów, ID wywołań systemowych.

Przykłady ciekawych, szczegółowych reguł do auditd można znaleźć w serwisie github:

• reguły użytkownika alienone
• reguły auditd w celu zachowania zgodności z wymogami PCI-DSS (Payment Card Industry Data Security Standard)
• reguły auditd w celu zachowania zgodności z wymogami NISPOM-DSS (National Industrial Security Program Operating Manual Data Security Standard)
• reguły auditd w celu zachowania zgodności z wymogami LSPP-DSS (Labeled Security Protection Profile Data Security Standard)
• reguły auditd w celu zachowania zgodności z wymogami NIST i DISA STIG dla RedHat’a

W tym artykule skupimy się na pełnym przeglądzie sytuacji, ponieważ nie chcemy, żeby jakiekolwiek podejrzane zachowanie nam umknęło, dlatego wykorzystamy pierwsze dwie reguły do śledzenia tego, co się dzieje w monitorowanym systemie.

W ten sposób skonfigurowaliśmy wszechstronnego obserwatora, który będzie śledził całą aktywność w systemie i dodatkowo będzie skoncentrowany na jakimkolwiek dostępie do krytycznych plików (tu sztandarowy duet – passwd i shadow). Wygląda na to, że auditd jest narzędziem idealnym i nic mu nie umknie, i chociaż w większości przypadków jest to prawdą to jednak musimy być świadomi jego ograniczeń. Przykładowo, uruchomienie tego narzędzia w systemie wcześniej zainfekowanym dobrze przygotowanym rootkitem działającym na poziomie jądra systemu może spowodować, że złośliwa działalność zostanie ukryta w całości lub częściowo. Przykład ataku na oprogramowanie przechwytujące wywołania systemowe można znaleźć w artykule Exploiting Concurrency Vulnerabilities in System Call Wrappers. Na początku auditd może również przytłoczyć ogromem informacji, które rejestruje w swoim logu, a przeciążenie informacją może być czasem gorsze od jej braku. Wszystko jest kwestią ujarzmienia auditd i jego poprawnego wykorzystania.

Zanim jednak przejdziemy do integracji z HIDS OSSEC kilka przykładów wykorzystania auditd solo, które pozwolą zmniejszyć odrazę na widok wielolinijkowych logów auditd dla pojedynczego zdarzenia.

Auditd przykład 1: przeszukiwanie auditd.log

Analizowane zdarzenie to włamanie do serwera z wykorzystaniem konta nieuprzywilejowanego użytkownika. Intruz próbował skopiować plik shadow, zatem musiał zostać zauważony przez auditd:

w logu znajduje się poniższy wpis dotyczący tego zdarzenia, któremu auditd nadał numer 182858.

Linia PATH opisuje deskryptor pliku, którego dotyczy zdarzenie.

Linia CWD (current working directory) informuje, z jakiej lokalizacji zostało wydane polecenie.

Linia SYSCALL opisuje szczegóły wywołania systemowego:

•  nr wywołania systemowego (syscall=2 – open())
• wynik operacji zakończonej w tym wypadku niepowodzeniem ( success=noexit=-13)
• numer procesu i numer procesu rodzica (ppid=26215 pid=26768)
• numer terminala (tty=pts4)
• polecenie systemowe i lokalizacja binarki (comm=”cp” exe=”/bin/cp”)
• informacje o użytkowniku (auid=1005 uid=1005 gid=1003 euid=1005 suid=1005 fsuid=1005 egid=1003 sgid=1003 fsgid=1003)

Wykonanie tego samego polecenia ale z podniesionymi uprawnieniami za pomocą funkcjonalności sudo

daje następujący wynik w logu audt.log:

Warto zwrócić uwagę, że tym razem odczyt pliku został zakończony powodzeniem  (success=yes), a operacja została przeprowadzona z podniesionymi uprawnieniami na co wskazuje pole euid (effective uid), które teraz ma wartość 0, czyli UID użytkownika root. W polu comm zawarta jest informacja o programie sudo, nie mamy natomiast informacji o argumentach tego polecenia. W tym celu skorzystamy z tego, że auditd monitoruje wszystkie uruchomione polecenia wraz z argumentami za pomocą reguły nazwanej execve i wyszukamy wszystkie zdarzenie związane z poleceniem sudo i regułą monitorującą execve.

czego wynikiem jest takie zdarzenie:

gdzie szczególnie interesująca jest linia EXECVE zawierająca wszystkie argumenty polecenia. Widzimy zatem, że poprzez odpowiednie sformatowanie linii EXECVE z logu audit.log możemy otrzymywać bieżące informacje o tym, jakie polecenia i programy są uruchamiane w monitorowanym systemie (Przykład nr 5).

Auditd przykład 2: analiza źródła malware’u

Po wykryciu podejrzanej aktywności na hoście, auditd jest w stanie ułatwić nam zadanie ustalenia źródła złośliwego oprogramowania. Do tego celu wykorzystujemy pole ppid (parent process id) i sprawdzamy, w jaki sposób zostało uruchomione polecenie kopiowania plików.

Linia SYSCALL zawiera informację, że procesem nadrzędnym jest powłoka systemowa dash, w innym wypadku mógłby to być skrypt lub binarka, jednak w każdym z tych przypadków możemy podążać po nitce do kłębka ustalając, gdzie jest źródło podejrzanych zachowań, aby ostatecznie zweryfikować, czy jest to malware, włamanie czy też autoryzowane działanie adminstratorów. Niejednokrotnie trzeba sprawdzić kilka takich potomnych procesów, by na końcu dotrzeć do zarażonej biblioteki.

Jeśli analizując kolejne procesy krok po kroku dojdziemy do sytuacji, że ich źródłem jest np.któraś binarka systemowa chociażby polecenie less, pakiet auditd zawiera narzędzie autrace, które ma funkcjonalność zbliżoną do strace. Za pomocą autrace możemy przeprowadzić analizę odwołań do plików i bibliotek, z których korzysta dana binarka, co również przybliżyć nas może do źródła malware’u.

Dostajemy podpowiedź, żeby użyć polecenia ausearch -i -p 8312, w tym przykładzie z poszukiwaniem malware’u proponuje trochę użyć:

Uwaga: polecenie autrace poprzedzamy wyczyszczeniem reguł za pomocą auditctl -D.

Auditd przykład 3: zaawansowane wyszukiwanie (ausearch) i tworzenie raportów (aureport)

Poniżej kilka przydatnych przełączników do przeszukiwania logu audit.log

wyszukuje zdarzenie z bieżącego dnia  związane z usuwaniem plików za pomocą polecenia rm, inne ciekawe przedziały czasu, które możemy określić za pomocą przełącznika –ts to now,  recent (ostatnie 10 minut),  today,  yesterday, this-week, this-month, this-year.

wyszukuje aktywność użytkownika o UID 1001

przełącznik -i zamienia wartości numeryczne na nazwy np. UID’y na nazwy użytkowników

przełącznik -k umożliwia wyszukiwanie, czy zostały zarejestrowane zdarzenia, dla których przygotowaliśmy reguły w pliku audit.rules.

W podręczniku do ausearch znajdziemy kolejne przykłady przełączników, które możemy wykorzystać do odpytwania auditd o to, co zaobserwował.

Oprócz precyzyjnych odpowiedzi w postaci wyłuskiwania informacji z logu za pomocą ausearch, pakiet auditd zawiera również binarkę aureport, która służy do tworzenia raportów i podsumowujących audyt systemu w szerszym kontakście czasowym.

Za pomocą aureport możemy wygenerować raport o wszystkich kolejnych uruchomieniach programów wykonywalnych w godzinach 12.00-13.00

Tu raport o wszystkich programach wykonanych w bieżącym dniu z podsumowaniem liczby wywołań tych programów.

Raport o nieudanych logowaniach za pomocą przełącznika -au

Podsumowanie o modyfikacjach kont uzyskamy za pomocą przełącznika -m

Przydatną opcją jest też wygenerowanie raportu o anomaliach za pomocą przełącznika -n.

Co ciekawe oba polecenia ausearch i aureport możemy łączyć potokowo:

Za pomocą powyższego polecenia wykonaliśmy podsumowanie wszystkich programów, które danego dnia uzyskiwały dostęp do pliku /etc/shadow, od razu rzuca się w oczy niepokojące polecenie kopiowania (/bin/cp) tego pliku wykonane 6 razy.

Auditd przykład 4: centralne logowanie

Dobrą praktyką monitorowania jest wykorzystanie centralnego logowania i choć wydaje się to oczywiste to, realia pozostawiają wiele do życzenia. Auditd zawiera plugin audispd, który sprawia, że konfiguracja przesyłania logu audit.log do systemu zdalnie logującego jest całkiem prosta. W tym przykładzie rozpoczniemy od konfiguracji serwera rsyslog:

plik /etc/rsyslog.conf na serwerze:

Serwer syslog będzie nasłuchiwał na porcie 2514 TCP, a log audit.log zostanie umieszczony w lokalizacji /var/log/rsyslog/%HOSTNAME% z zachowaniem formatu auditd, co oznacza, że można korzystać z narzędzi takich jak ausearch czy aureport podając lokalizację pliku za pomocą przełącznika -if, np.

plik /etc/rsyslog.conf u klienta:

Przy konfiguracji syslog trzeba szczególnie uważać w plikach konfiguracyjnych na rozdzielenie selektorów i działań za pomocą tabulacji a nie spacji.

w konfiguracji pluginu audispd u klienta w pliku /etc/audisp/plugins.d/syslog.conf włączamy opcję przesyłania zdarzeń również do sysloga:

Komunikację klient-serwer zawierającą tak wrażliwe dane jak log audytu systemu musimy obowiązkowo zaszyfrować, a na oficjalnej stronie rsyslog.com można znaleźć tutorial konfiguracji TLS dla rsyslog.

Auditd przykład 5: podgląd wszystkich poleceń w czasie rzeczywistym (skrypt w Pythonie formatujący audit.log)

Pomimo, że pierwsze przykłady powinny sprawić, że log audit.log nie przyprawia już o ból głowy, a narzędzia takie jak ausearch i aureport usprawniają wyszukiwanie i analizę to, jednak warto mieć własne narzędzia, które pozwolą wyciągać z logu esencję, czyli w naszym przypadku – wszystkie polecenia uruchamiające programy wykonywalne w czasie rzeczywistym. Do tego celu można zastosować krótki skrypt w Pythonie, który sformatuje log audit.log pod nasze potrzeby.

tailAuditLog.py

Działanie logowania wszystkich komend na poziomie wywołań systemowych najlepiej sprawdzić otwierając równolegle dwa okna terminala:

1. W pierwszym uruchamiamy skrypt poleceniem: python /root/tailAuditLog.py
2. W drugim oknie wydajemy dowolne komendy powłoki, uruchamiamy programy, etc.

Skrypt tailAuditLog.py do monitoringu uruchamianych poleceń w systemie

Wynikiem działania skryptu są kolejne zarejestrowane wywołania systemowe EXECVE, gdzie w pierwszej kolumnie umieszczony został ID zdarzenia, co można wykorzystać do szczegółowego analizy narzędziami pakietu auditd.

Jeśli skonfigurowaliśmy centralne logowanie opisane w przykładzie numer 4 to, skrypt najlepiej uruchomić na serwerze zmieniając w skrypcie lokalizację pliku auditd.log.

Podsumowanie

W pierwszej części artykułu poznaliśmy pierwszego gracza -auditd, którego zadaniem jest obserwacja wywołań systemowych, jakie mają miejsce w monitorowanym systemie. Warto poznać to narzędzie do audytu z uwagi na szeroki wachlarz możliwości logowania zdarzeń związanych zarówno z wywołaniami systemowymi jak z deskryptorami plików. Co więcej, elastyczność budowania reguł pozwala wypełniać wymagania jakie stawiane są przez wiele standardów regulujących szczegółowość audytu (NIST, PCI_DSS, itp.) Mam nadzieję, że przykłady użycia narzędzi ausearch i aureport pozwoliły oswoić się z dużą ilością informacji jaką dostarcza auditd.Auditd widzi dużo i dużo rejestruje, nie zawiera jednak modułu alertującego, ani blokującego niechcianą aktywność.

W drugiej części artykułu przedstawię niezbędną konfigurację OSSEC HIDS do współpracy z auditd, czyli temat będzie dotyczył pisania własnych dekoderów, pisania reguł OSSEC i użycia modułu Active Response, dzięki któremu OSSEC nie jest tylko systemem do wykrywania włamań, ale też do precyzyjnego blokowania intruzów. Poprzez użycie wymienionych narzędzi zwiększamy swój arsenał, co sprawia, że nie jesteśmy bezbronni. Co więcej, pora również przestawić myślenie z wydawałoby się oczywistego „czekania na incydent” na strategię wyjścia do przeciwnika. Zmiana strategii polega na nastawieniu ofensywnym będąc w obronie. Myśląc tak, jak włamywacz, możemy przewidywać jego ruchy i tam zastawiać własne zasadzki. Auditd jest na pewno narzędziem, za pomocą którego możemy to realizować, bo zwiększa radykalnie nasz obraz sytuacji.