Rajmund Radziewicz Snort & ACID - inteligentne węszenie w sieci

Transkrypt

1 1 z :51 Rajmund Radziewicz Snort & ACID - inteligentne węszenie w sieci WPROWADZENIE Systemy wykrywania włamań (IDS - Intrusion Detection System) to zasadniczo dość nowe narzędzia, służące do badania anomalii, wykrywania nieprawidłowości i dodatkowego zabezpieczania określonych segmentów sieci. Stanowią one swoiste uzupełnienie firewalli, z którymi potrafią współpracować - a które często nie wystarczają do zapobiegania szczególnie wyrafinowanym i dobrze przemyślanym atakom na naszą sieć. IDS'y jako systemy służące przede wszystkim do monitorowania ruchu TCP/IP (niektóre pozwalają na ingerowanie w ten ruch) potrafią o wiele więcej niż jedynie filtrować pakiety, które wychodzą i przychodzą do naszego komputera. Jako że posiadają one jednocześnie funkcje wyspecjalizowanych snifferów (sniffing - węszyć) i analizują cały ruch sieciowy według bardzo precyzyjnych reguł - pozwalają np. na wykrywanie niesprawnych urządzeń (np. serwera DNS, rutera) lub atakujących nasz serwer wirusów (co może być groźne w przypadku sieci opartych na systemie MS Windows). Są jak komputerowe systemy wczesnego ostrzegania, które pozwalają wykryć nieporządane działania i niebezpieczne narzędzia, zanim jeszcze dotrą do naszego firewalla. Żeby w pełni zrozumieć zasadę działania systemu IDS, sniffera, czy chociażby firewalla - powinniśmy przypomnieć sobie mechanizm działania protokołów z rodziny TCP/IP odpowiedzialnych za przesyłanie danych w sieci. Jako że o samym TCP/IP powstało wiele opasłych tomów i obszernych dokumentów RFC, pozwole sobie tylko na krótkie wyjaśnienie kilku najistotniejszych kwestii. Zasadniczo TCP/IP jest zbiorem zwartych protokołów, niezależnych od sprzętu czy systemu operacyjnego. To właśnie ten zbiór tworzy dzisiejszy Internet, do którego podłączona jest nasza sieć, czy też serwer. Podstawą jest protokół IP (Internet Protocol). Odpowiada on za przesyłanie danych i jest protokołem transportowym sieci. Najmniejszą jednostkę danych nazywa się czasami datagramem IP. Zawiera informacje o adresie docelowym i źródłowym przesyłanego datagramu. Zajmuje się dzieleniem tego datagramu na mniejsze kawałki przed wysłaniem, oraz sklejaniem go kiedy dotrze już do komputera docelowego. Zajmuje się także wyborem najdogodniejszej trasy podczas wędrówki przez Internet (trasowanie - routing). IP posiada jednak pewną wadę. Jest protokołem bezpołączeniowym, co oznacza że sam nie ustanawia połączenia i nie sprawdza czy odległa maszyna jest gotowa na odebranie przysłanych jej danych. Nie zapewnia też wykrywania błędów podczas transmisji i ich korekty. Protokołem który doskonale uzupełnia IP jest TCP (Transmission Control Protocol). Jest to protokół połączeniowy, który sprawdza czy dane zostały dostarczone bezawaryjnie do adresata. Ustanawia też bezpieczne połączenie z tym adresatem i po przesłaniu danych zamyka połączenie. W dużym uproszczeniu TCP przesyła tak długo dane, aż otrzyma potwierdzenie od komputera docelowego że wszystkie dane zostały

2 2 z :51 przez niego odebrane prawidłowo. Każdy segment takich danych (dla IP dane są datagramami, dla TCP segmentami) posiada swoją sumę kontrolną (tzw. CRC) która jest sprawdzana. Precyzując nieco ten mechanizm - odbywa się to na zasadzie tzw "trójetapowego uzgadniania połączenia". Znajomość mechanizmu tego "uzgadniania" jest bardzo istotna, ponieważ wiele wirusów i eksploitów wykorzystuje go właśnie do tego, żeby przedostać się do naszej sieci i/lub systemu. W momencie wymiany informacji pomiędzy dwiema maszynami w sieci, połączenie to jest uzgadniane i synchronizowane za pomocą specjalnych bitów, dodawanych do przesyłanych datagramów. TCP hosta inicjującego połączenie nie zaczyna od razu wysyłać faktycznych danych, a wysyła kontrolny datagram z bitem SYN ustawionym na 1. Oznacza to chęć synchronizacji połączenia. Po odebraniu takiego pakietu serwer (o ile określony port, na który klient chce się połączyć nie jest zajęty) przydziela odpowiednie bufory TCP oraz potwierdza odbiór odpowiadając bitem SYN+ACK - czyli zgodą na połączenie. Host po otrzymaniu SYN+ACK odpowiada kolejnym SYN, ustawionym tym razem na 0. To oznacza zakończenie uzgadniania połączenia i rozpoczęcie przesyłania danych. Po zakończeniu przesyłania danych, połącznie zamykane jest również w sposób bezpieczny i kilkuetapowy. Serwer wysyła do klienta datagram z ustawionym bitem FIN (oznaczającym chęć zakończenia połączenia), klient odpowiada FIN+ACK, a na sam koniec serwer potwierdza ostateczne "pożegnanie" wysyłając datagram z ustawionym ACK. Jest jeszcze specjalna odmiana protokołu, lżejszego od TCP, który również nie jest nastawiony połączeniowo (wysyła pakiety nie pilnując czy dotrą na pewno na miejsce), pozwala natomiast na znacznie szybsze realizacje połączeń. Pilnuje również integralności pakietów w trakcie transportu. Protokół nazywa się UDP (User Datagram Protocol) i wykorzystywany jest np. w usłudze TFTP (Trivial FTP). TCP/IP opisuje się również często na przykładzie czterowarstwowego modelu. Składa się on z następujących elementów: - warstwy aplikacji - warstwy transportowej - warstwy sieciowej - warstwy fizycznej Żeby nie rozwodzić się zbyt technicznie, można zobrazować taki model na bardzo prostym przykładzie. Załóżmy że pobieramy z serwera WWW stronę internetową. Aplikacja nazywająca się "serwer WWW" wysyła w tym przepadku do aplikacji nazywającej się "przeglądarka" po stronie klienta pakiety zawierające daną stronę (tekst, grafikę itd). Pakiety obsługiwane są na poziomie aplikacji przez protokół HTTP. Ten protokół dodaje do takich pakietów własne nagłówki i przekazuje je do warstwy transportowej. W warstwie transportowej pakiety trafiają do protokołu TCP. Otrzymuje on pakiety sklejone z nagłówkami HTTP. Adresuje je dodając do nich numer portu komputera lokalnego, z którego wychodzą i numer portu komputera docelowego. Numery te umieszcza w swoim własnym nagłówku, który również dokleja i przekazuje całość do warstwy sieciowej. W tej warstwie pakiety przejmuje protokół IP. Dodaje on kolejny (własny) nagłówek, w którym umieszcza adres IP komputera źródłowego i docelowego. Tak oklejone paczuszki IP przekazuje do warstwy najniższej - fizycznej. W tej warstwie (najczęściej jest to warstwa

3 3 z :51 ethernetu) dodawany jest kolejny nagłówek zawierający adresy kart sieciowych (MAC) komputera lokalnego i zdalnego. Z tyloma nagłówkami pakiety wędrują następnie przez Internet. Po dotarciu na miejsce, komputer docelowy rozpoznaje po nagłówku warstwy fizycznej że paczki adresowane są akurat do niego. Usuwa taki nagłówek i przekazuje paczki do wyższych warstw. Tam są one kolejno "rozbierane" z poszczególnych nagłówków, aż trafią do warstwy najwyższej (aplikacji), gdzie przekazane zostaną przeglądarce internetowej. Ewentualne komunikaty o błędach w trakcie wedrówek pakietów zgłasza nam jeszcze inny protokół - ICMP (Internet Control Message Protocol). Zajmuje się on zgłaszaniem wszelkich błędów w trakcie wędrówki datagramów przez sieć. Takie błędy to np. wyłączona maszyna docelowa, nieosiągalna sieć, albo wyczerpanie się licznika "czasu życia pakietu" (TTL - Time to Live. Protokoły TCP/IP wymagają aby każdy router przez który przechodzi pakiet zmniejszał wartość pola TTL o 1. Zapobiega to błąkaniu się się wszelkich zagubionych pakietów zbyt długo po Internecie. Rola systemu IDS polega na śledzieniu ruchu TCP/IP wg określonych reguł, przechwytywaniu wyżej opisanych pakietów i ich analizie. Taka analiza oraz ocena zaistniałej w sieci sytuacji możliwa jest dzięki wykorzystaniu tzw. bazy sygnatur oraz w przypadku niektórych systemów wykrywania włamań - badaniu anomalii na podstawie pobranych wcześniej próbek ruchu sieciowego (stanowiącego następnie punkt odniesienia). Np. specjalny preprocesor snorta - SPADE implementuje właśnie taką funkcjonalność. Baza sygnatur jest zestawem specjalnych regułek, określających jakie działania IDS ma traktować jako niebezpieczne. Przykładowo jeśli pakiety TCP wychodzące z portu 110 (pop3, czyli poczta) zawierają w przenoszonych danych określone ciągi znaków wskazujące na obecność skryptu VBScript (najczęściej wirus w załączniku) - IDS może o tym zaalarmować lub przykładowo wyrzucić taki pakiet z bufora TCP, zanim dotrze do celu. Informuje go o tym specjalna regułka. IDS'y mają więc najczęściej obszerne i często aktualizowane bazy takich regułek (sygnatur). To chyba tyle w ramach wstępu do zagadnienia jakim jest analiza ruchu sieciowego. Oczywiście bardzo pobieżnego wstępu. Warto może jeszcze nadmienić, że systemy wykrywania włamań (anomalii) dzielą się na: - systemy oparte na serwerze - czyli takie które służą do ochrony pojedyńczej maszyny. Analizują logi systemowe, nawiązane aktualnie połączenia sieciowe, często mają także wbudowaną funkcję kontroli integralności plików systemowych - systemy oparte na sieci (NIDS - Network IDS) - to systemy analizujące całą sieć, potrafiące kontrolować połaczenia pomiędzy różnymi maszynami w tej sieci. Wymagają ustawienia interfejsu sieciowego w tzw. tryb "promiscous" (rozwlekły), pozwalający na przechwytywanie wszystkich pakietów w sieci (nie tylko tych, ktore są skierowane do maszyny na której pracuje NIDS). SNORT + ACID Snort, którego symbolem jest węsząca świnka, jest właśnie przykładem jednego z najlepszych i najskuteczniejszych NIDS'ów. Dostępny jest na wiele platform systemowych (w tym również Windows) i udostępniany na zasadach licencji GPL. Potrafi wyszukiwać i dopasowywać do wzorców podejrzane treści w

4 4 z :51 strumieniach pakietów, wykrywać wiele ataków i anomalii, np. takich jak przepełnienia bufora, skanowanie portów, ataki na usługi WWW, FTP, SMB, ataki typu ARP spoofing. Posiada często aktualizowaną bazę sygnatur. Między innymi źródłem regułek dla Snorta jest baza arachnids udostępniana publicznie przez firmę Max Vision Network Security. Nasza świnka potrafi również integrować się z systemami baz danych (jak np. z MySQL) - co pozwala na stosowanie bardzo wygodnych dodatków, takich jak chociażby ACID. Wspomniany ACID (Analysis Console for Intrusion Databases) jest specjalnym modułem Snorta tworzącym interfejs WWW do analizy logów umieszczonych w bazie danych. Jest to rozbudowany system raportujący, na który składa się zestaw skryptów PHP, znacznie ułatwiających przeglądanie alarmów, sortowanie i zaawansowane wyszukiwanie wykrytych ataków. Snort przechwycone przez siebie pakiety przepuszcza przez tzw. preprocesory. To one filtrują strumień TCP/IP szukając na różnych jego warstwach wszelkich nieprawidłowości (wykrywanych na podstawie regułek lub badaniu anomalii na podstawie pobranych próbek ruchu sieciowego). Do standardowo aktywnych zaraz po instalacji preprocesorów należą: http_decode - który przetwarza adresy HTTP i konwertuje na ASCII znaki zakodowane szesnastkowo. Zapobiega to ukrywaniu pewnych danych, które zakodowane mogłby być przekazane za pomocą zapytania do serwera WWW. portscan - wykrywa skanowania portów, w tym skanowania typu NULL, FIN, SYN+FIN frag2 - skleja i buforuje zdefragmentowane pakiety. Często analiza pojedyńczych datagramów nie wykazuje żadnych niebezpieczeństw. Dane wędrują sobie pofragmentowane do portu jednego z komputerów w naszej sieci. Po dotarciu do tego komputera i złożeniu ich przez aplikację - okazuje się że może to być np. niebezpieczny eksploit albo wirus stream4 - bardzo rozbudowany preprocesor służący do śledzenia połączeń, odtwarzania i szczegółówej analizy strumieni TCP. Wykrywa niektóre wysublimowane skanowania portów, testuje sumy kontrolne i poprawność pojedyńczych datagramów. rpc_decode - wykrywa próby podejrzanych odwołań do usługi RPC (zapewnianej przez portmappera). Po przepuszczeniu pakietów przez preprocesory oraz ich analizie na podstawie sygnatur, Snort zarejestrowane zdarzenia zapisuje do plików dziennika. Potrafi stosować zresztą różne odmienne formy tego zapisu: rejestrowanie w binarnym formacie tcpdump, rejestrowanie w pełnej, opisowej postaci, wysyłanie komunikatu na gniazdo uniksowe (np. w celu dalszej obróbki przez inną aplikację), zapisywanie do bazy danych itd. Możemy też zdefiniować własne regułki - na podstawie których Snort będzie np. resetował lub blokował podejrzane połączenia. Zajmiemy się tym zaraz po instalacji i konfiguracji samego NIDS'a i dodatkowego modułu raportującego ACID.

5 5 z :51 Rysunek 1. Składowe systemu NIDS. INSTALACJA I KONFIGURACJA Zaczynamy od instalacji odpowiednich pakietów. To czego potrzebujemy to Snort z domyślnym wsparciem dla MySQL'a oraz ACID: apt-get install snort-mysql acidlab-mysql Po pobraniu pakietów przeprowadzona zostanie wstępna konfiguracja. W przypadku paczki acidlab-mysql zostaniemy m.in zapytani o serwer WWW z jakiego chcemy korzystać (zasadniczo wystarczy zostawić domyślne "Apache"), o nazwę bazy w której przechowywane będą logi (snort_log), nazwę hosta, nazwę i hasło użytkownika, nazwę bazy przeznaczoną na archiwa (snort_archive). W przypadku snort-mysql zostaniemy zapytani o konfigurację tzw. sensora (czyli interfejsu sieciowego na którym nasłuchiwać ma NIDS. Domyślnie jest to eth0). Następnie wpisujemy adres sieci jaką Snort ma monitorować. Jeśli komputer ze Snortem wpięty jest np. do switcha rozdzielającego kilka podsieci - możemy oczywiście wpisać tu kilka adresów rozdzielonych przecinkiem. Rzecz w tym, że przez komputer z systemem wykrywania włamań pakiety adresowane do danej sieci muszą przechodzić. Nowsze switche mają specjalny port zarządzalny, na który przełączany jest cały ruch z pozostałych portów. Do niego właśnie należy wpinać komputer z NIDS'em. Jeśli mamy np. tylko jeden komputer który chcemy monitorować - wystarczy zamiast adresu sieci wpisać adres IP tego komputera.

6 6 z :51 Rysunek 2. Konfiguracja poinstalacyjna pakietu ACID. Po wykonaniu całej wstępnej konfiguracji, musimy utworzyć dwie bazy danych: snort_log i snort_archive na archiwa alarmów. W tym celu uruchamiamy serwer MySQL: # cd /etc/init.d ;./mysql start Następnie: # mysql -u mysql -p Enter password: mysql> create database snort_log; Query OK, 1 row affected (0.01 sec) mysql> create database snort_archive;

7 7 z :51 Query OK, 1 row affected (0.01 sec) mysql> quit Po utworzeniu naszych baz należy wygenerować dla nich odpowiednie tabele. Tym razem nie musimy robić tego 'ręcznie', ponieważ z pakietami snort-mysql i acidlab-mysql mamy dostarczone odpowiednie pliki *.sql. Wystarczy się nimi posłużyć. Najpierw tworzymy tabele wymagane przez ACID'a: # mysql -u root -p snort_log < /usr/share/acidlab/create_acid_tbls_mysql.sql # mysql -u root -p snort_archive < /usr/share/acidlab/create_acid_tbls_mysql.sq Teraz tabele Snorta (jako że są spakowane, najszybciej będzię kiedy posłużymy się zcatem): # zcat /usr/share/doc/snort-mysql/contrib/create_mysql.gz mysql -u root -p snort_log # zcat /usr/share/doc/snort-mysql/contrib/create_mysql.gz mysql -u root -p snort_archive Po tej operacji powinniśmy jeszcze dokonać małej zmiany w głównym pliku konfiguracyjnym Snorta. Jeśli skonfigurowaliśmy system tak, żeby nasłuchiwał tylko na jednym interfejsie (jeden aktywny sensor), będzie to plik /etc/snort/snort.conf. Gdyby sensorów było więcej - pliki będą się kolejno nazywały: snort.eth0.conf, snort.eth1.conf itd. Najważniejsze opcje jakie musimy ustawić w tym pliku - to definicja dwóch zmiennych: $HOME_NET oraz $EXTERNAL_NET. HOME_NET oznacza naszą sieć domową (jeśli mamy tylko jeden komputer, wpiszemy tam IP tego komputera). EXTERNAL_NET to cała strefa zewnętrzna, z której wszelki ruch sieciowy będzie wnikliwie analizowany. Przykładowy wpis może więc wyglądać następująco: var HOME_NET /24 var EXTERNAL_NET!$HOME_NET Wpis /24" przy HOME_NET oznacza sieć o adresie z maską podsieci klasy C. Jest to specjalna notacja oznaczania adresów - CIDR (Classes Internet Domain Routing) domyślnie używana przez Snorta. Dzieje się tak dlatego - że NIDS nie może beztrosko zakładać, że wszystkie adresy w sieci używają standardowych masek podsieci. Poniżej mamy wpis równoważny mniej więcej temu - że wszystko co nie jest naszą siecią domową traktowane będzie jak sieć zewnętrzna, z której potencjalnie może nastąpić jakiś atak. Zamiast takiego wpisu moglibyśmy wstawić tam jakiś konkretny adres, czy też zestaw adresów. W /etc/snort/snort.conf znajdziemy również kilka innych, opcjonalnych zmiennych jak np. var DNS_SERVERS $HOME_NET var SMTP_SERVERS $HOME_NET var HTTP_SERVERS $HOME_NET var SQL_SERVERS $HOME_NET Domyślnie oznaczają one, że wszelkie serwery DNS, poczty, czy też baz danych w naszej sieci - obejmuje

8 8 z :51 zmienna HOME_NET. Gdyby się jednak okazało, że np. nasz lokalny serwer DNS jest w zupełnie innej podsieci, a z wiadomych przyczyn będzie następował nasilony ruch pomiędzy tym serwerem a komputerami w naszej sieci domowej (oznaczonymi przez zmienną HOME_NET) - to warto poinformować o tym Snorta wpisując: var DNS_SERVERS [tu adres IP serwera DNS] W innym przypadku nasz NIDS mógłby taki wzmożony ruch uznać za podejrzany i niepotrzebnie o tym alarmować. Po ustawieniu tych zmiennych możemy uruchomić Snorta poleceniem: cd /etc/init.d ;./snort start Musimy pamiętać, że jeśli chcemy korzystać z dodatkowego modułu raportującego ACID, w tle musi pracować cały czas serwer WWW Apache i serwer baz danych MySQL. Po wystartowaniu Snorta za pomocą skryptu znajdującego się w /etc/init.d uruchomi się on w trybie NIDS, czyli jako sieciowy system wykrywania anomalii. Można go natomiast uruchomić również w dwóch innych trybach - jako sniffer i tzw. "packet logger". W trybie sniffer przechwytuje na bieżąco wszystkie pakiety i wyświetla ich zawartość na ekranie (działa jak typowy sniffer). Żeby uczynić z naszego Snorta zwykłego sniffera, wystarczy polecenie: snort -vd Opcja "-v" powoduje że Snort będzie wyświetlał informacje o nagłówkach TCP/IP/UDP/ICMP, opcja "-d" wymusza wyświetlanie również zawartości tzw. payloadu (czyli właściwych danych przeznaczonych dla warstwy aplikacji). Fragment przykładowej sesji Snorta uruchomionego w trybie "sniffer": root@linux-educd:~# snort -vd Running in packet dump mode Log directory = /var/log/snort Initializing Network Interface eth0 --== Initializing Snort ==-- Initializing Output Plugins! Decoding Ethernet on interface eth0 -*> Snort! <*- --== Initialization Complete ==--

9 9 z :51 Version (Build 30) By Martin Roesch (roesch@sourcefire.com, 01/10-17:49: :2446 -> :53 UDP TTL:64 TOS:0x0 ID:12530 IpLen:20 DgmLen:60 DF Len: C A...www D 70 2D C simp-st.pl... =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 01/10-17:49: :53 -> :2446 UDP TTL:239 TOS:0x0 ID:58362 IpLen:20 DgmLen:165 DF Len: C A...www D 70 2D C simp-st.pl... C0 0C C D9 1C 92 9E C C E ind Jeśli chcemy uruchomić Snorta w trybie "packet logger" wykonujemy polecenie: snort -b -l katalog Opcja "-b" oznacza że aplikacja będzie zrzucać logi w binarnym formacie tcpdump, natomiast "-l" powoduje że logi te zapisywane będą w określonym katalogu. Przed uruchomieniem w ten sposób Snorta wspomniany katalog należy utworzyć. Zapisane w takim formacie logi można następnie poddawać dodatkowej obróbce za pomocą aplikacji Ethereal (który również obsługuje format tcpdumpa). Oczywiście właściwym i najbardziej rozbudowanym trybem jest NIDS i takim też będziemy się dalej posługiwać. Jeśli mamy działającego i uruchomionego Snorta, MySQL'a i Apache'a - wchodzimy na adres: Zobaczymy interfejs ACID'a, pokazujący nam liczbę sensorów, wskaźniki zarejestrowanych alarmów oraz kilka innych opcji. Możemy przeglądać wszystkie dzienniki Snorta, mamy też łatwy dostęp do baz sygnatur, wyszukiwarki itp. Żeby przetestować możliwości naszego świeżo upieczonego systemu wykrywania anomalii, spróbujmy z maszyny znajdującej się poza zdefiniowanym HOME_NET przeskanować porty komputera, na którym uruchomiliśmy NIDS'a. Możemy posłużyć się bardzo funkcjonalnym programem do testowania otwartych portów, wykrywania zdalnego systemu operacyjnego - nmapem. Założmy że chroniony serwer to Wykonujemy standardowe skanowanie, polegające na tym, że nmap wysyła na nasz serwer pakiety TCP z ustawioną flagą SYN, testując w ten sposób otwarte porty (bit SYN, jak już wspominane było na początku artykułu oznacza chęć połączenia na określony port):

10 10 z :51 nmap -ss Po sprawdzeniu w powyższy sposób maszyny ze Snortem, możemy odświeżyć uruchomionego w przeglądarce ACID'a i sprawdzić czy zarejestrował on jakieś podejrzane działania. Okazuje się że nie tylko wykrył skanowanie systemu - ale zidentyfikował je jako "ICMP PING NMAP". Pokazuje również dodatkowe informacje, m.in adres komputera z którego wyszło skanowanie i dokładny czas incydentu. Nawet jeśli spróbujemy użyć specjalnych flag "-sf", w celu częsciowego ukrycia połączeń na określone porty - Snort i tak bezbłędnie je wykrywa. Spróbujmy teraz np. zasymulować działanie robaka CodeRed i wyszukajmy poprzez serwer WWW pliku "scripts/root.exe". Wpisujemy więc na zewnętrznej maszynie: W odpowiedzi dostajemy odpowiednie alarmy: 56: [**] [1:1256:2] WEB-IIS CodeRed v2 root.exe access [**] [Classification: Web Application Attack][Priority: 1]

11 11 z :51 Rysunek 3. Interfejs modułu raportującego. Oczywiście jako że nasza maszyna pracuje pod kontrolą Linuksa - regułkę dotyczącą CodeRed można usunąć z arsenału Snorta (o tym jak to zrobić za chwilę), no chyba że w naszej sieci znajdują się jakieś maszyny z systemem podatnym na takie ataki. Podobnie bezbłędnie reaguje nasz NIDS na dyskretne, rozproszone w czasie skanowanie portów pojedyńczymi pakietami FIN, czy np. próby ataków na skrypty PHP, polegające na wykorzystaniu przesyłania danych za pomocą metody "get". Jeśli nie sprawdza się wówczas danych wejściowych - można pod taka zmienną podczepić np. własny skrypt. Na podobne błędy narażone są skrypty zawierające funkcję include(),

12 12 z :51 w których nie sprawdza się parametrów. Wpisanie więc w przeglądarce: również spowoduje wygenerowanie alarmu. REGUŁKI SNORTA - TWORZENIE SYSTEMU PREWENCYJNEGO Póki co Snort sprawdza się doskonale jako system monitorujący naszą sieć. Pliki z poszczególnymi regułkami, które wykorzystuje, znajdują się w katalogu /etc/snort/rules. Wszystkie mają rozszerzenie *.rules, natomiast w pliku konfiguracyjnym /etc/snort/snort.conf znajduje się sekcja określająca jakie pliki będą przez NIDS'a używane. Fragment tej sekcji może wyglądać jak poniżej: include $RULE_PATH/local.rules include $RULE_PATH/bad-traffic.rules include $RULE_PATH/exploit.rules include $RULE_PATH/scan.rules Jeśli przykładowo nie jesteśmy zainteresowani określoną regułką - wystarczy wykomentować linię z jej nazwą z tego właśnie pliku. Reguły identyfikujące poszczególne ataki określają kilka sposobów reagowania na zaistniałe zdarzenie. Może to być przepuszczenia pakietu (pass), zarejestrowanie incydentu (log), czy ogłoszenie alarmu (alert). Jeśli mamy wkompilowaną obsługę tzw. flexresp ("fexible response" zapewniane jest przez bibliotekę libnet i pozwala na ingerencję w strumień TCP/IP) - możemy także używać bardziej wyrafinowanych parametrów: resp i react. Pozwalają one aktywniej reagować na atak. Za pomocą opcji resp można doprowadzić do zerwania podejrzanego połączenia, natomiast opcja react służy do blokowania dostępu do określonych usług (np. WWW). Pakiet snort-mysql instalowany z repozytoriów Debiana posiada już wkompilowaną obsługę flexresp. Przykładowa regułka którą możemy np. dopisać do /etc/snort/rules/local.rules mogłaby wyglądać następująco: log tcp $EXTERNAL_NET any -> $HOME_NET 110 \ ("msg: Próba połączenia z pop3";) Oznacza to, że wszelkie próby połączeń TCP przychodzące z sieci zewnętrznej (jednokierunkowy operator "->"), z dowolnego portu (any) do sieci zdefiniowanej przez zmienną HOME_NET na port 110, mają być zarejetrowane w logach z komunikatem "Próba połączenia z pop3". Język sygnatur umożliwia również zadeklarowanie reguły, która określa pakiety poruszające się w obie strony, za pomocą dwukierunowego operatora: "<>" zamiast "->". Bardziej aktywne reguły można definiować za pomocą wspomnianych opcji "resp" i "react". Np: alert tcp any any -> $HOME_NET 80 \ (msg: "Uwaga! Próba połączenia z serwerem WWW"; resp: rst_all;)

13 13 z :51 spowoduje, że dowolne połączenia TCP z dowolnego portu na port 80 jakiegoś komputera w naszej sieci będą zapisywane do logów w postaci alarmu "Uwaga! Próba połączenia z serwerem WWW" oraz przerywane za pomocą "rst_all" (nadawca otrzyma pakiet z TCP z ustawioną flagą RST, która przerwie połączenie). W wyniku działania powyższej regułki nikt spoza sieci HOME_NET nie zobaczy naszego serwisu WWW. Można również filtrować pakiety po ich zawartości (opcja "content"), np. alert tcp any any -> $HOME_NET any \ (msg: "Ktoś próbuje odpalić shellkod!"; content:" e8 c0 ff ff ff /bin/sh"; resp: icmp_all) Jak można wywnioskować z bardzo prostej składni - wszelkie pakiety z dowolnego portu skierowane do naszej sieci na dowolny port docelowy, zawierające podejrzany fragment kodu (w tym wypadku może być to shellkod próbujący wykonać przepełnienie stosu), zostaną "poczęstowane" informacją że zarówno sieć, port jak i host są nieosiągalne (opcja icmp_all). Inne przydatne opcje "active response" to: rst_snd - wysłanie pakietu TCP RST do nadawcy rst_rcv - wysłanie pakietu TCP RST do odbiorcy icmp_net - wysłanie pkaietu ICMP_NET_UNREACH do nadawcy icmp_host - wysłanie pakietu ICMP_HOST_UNREACH do nadawcy icmp_port - wysłanie pakietu ICMP_PORT_UNREACH do nadawcy Opcje icmp_all i rst_all są sumą wszystkich powyższych. Wszelkie logi zaistaniałych zdarzeń widoczne w postaci estetycznych tabelek ACID'a, możemy również przeglądać zaglądając bezpośrednio do dzienników Snorta. Spis wszystkich alarmów znajduje się w pliku /var/log/snort/alert. Pliki /var/log/snort/*log* zawierają dzienniki w binarnym formacie programu tcpdump. Spróbujmy przenalizować jeden z alarmów znajdujący się w pliku alert: [**] [1:469:3] ICMP PING NMAP [**] [Classification: Attempted Information Leak] [Priority: 2] 01/10-14:55: > ICMP TTL:40 TOS:0x0 ID:57742 IpLen:20 DgmLen:28 Type:8 Code:0 ID:63871 Seq:55619 ECHO [Xref => Pierwsza linia to: [**] [1:469:3] ICMP PING NMAP [**] Na samym jej początku mamy trzy liczby oddzielone od siebie dwukropkiem. Liczba "1" to tzw. identyfikator generatora. Jedynka w tym wypadku oznacza samego Snorta (mogą być również poszczególne podsystemy NIDS'a i wówczas wartość ta będzie inna). Liczba 469 to identyfikator konkretnej sygnatury o nazwie "ICMP

14 14 z :51 PING NMAP" występującej w jednej z baz sygnatur. Kolejna linia to: [Classification: Attempted Information Leak] [Priority: 2] Mówi nam ona, że alarm jest zaklasyfikowany do szerszej kategorii o priorytecie 2 (im niższa znajdzie się tutaj wartość, tym poważniejszy wydarzył się incydent). Następnie: 01/10-14:55: > Ten wpis mówi o dokładnej dacie zarejestrowanego połączenia i podaje adresy źródłowy i docelowy datagramów TCP. No i ostatnia linijka: [Xref => oznacza łącze do bazy sygnatur Snorta. W tym wypadku jest to baza znajdująca się na W przypadku jakiegoś innego zdarzenia mogłaby pojawić się tu równie dobrze baza arachnids. PODSUMOWANIE - CZYLI STUDIUM DROBNEGO OSZUSTWA Pamiętajmy o tym że żaden, nawet najlepiej zaprojektowany system NIDS nie zastąpi administratora. To on ostatecznie decyduje, które ze zgłoszonych alarmów są rzeczywiście poważne - a które wynikają z pewnych nieścisłości konfiguracyjnych lub sposobu działania określonych aplikacji sieciowych. Pamiętajmy również że NIDS nie będzie nigdy nieomylny. Jeśli ktoś bardzo się postara może "obejść" pewne jego mechanizmy. Nie należy więc zbyt restrykcyjnie i dosłownie podchodzić do wszystkich zgłaszanych alarmów. Dla przykładu wyobraźmy sobie pewną sytuację, w której ktoś skanuje porty naszego serwera. Snort komunikuje nas o tym - podając również adres komputera, z którego następiło skanowanie. Jak wiemy, adres źródłowy i docelowy wszystkich przesyłanych w sieci pakietów zapisany jest w nagłówku IP. Wystarczy teraz że ów ktoś (np. za pomocą nmapa) sfałszuje adres źródłowy w nagłówku i wyśle pakiety TCP, np. z ustawionym bitem FIN na kilka portów naszego komputera: nmap -S e eth0 -P0 -sf -v ip_naszego_komputera Po tej operacji Snort zakomunikuje - że ktoś z adresu (w tym przypadku jest to skanował nam porty ;-) Czy pomyłka NIDS'a oznacza że coś z nim jest nie tak? Raczej nie. Nasz system nie sniffuje przecież wszystkich połączeń w Internecie. Jeśli paczka ze sfałszowanym adresem wyszła z komputera "ciekawskiego" i dotarła przez sieć do naszego serwera - system wykrywania anomalii nie może przecież prześledzić całej jej trasy. Tego typu drobiazgi należy mieć po prostu na uwadze kiedy analizujemy logi naszej "inteligentnej świnii".

15 15 z :51 Na zakończenie warto jeszcze dodać że Snort jest narzędziem, które zasadniczo nie odbiega od swoich komercyjnych i bardzo drogich odpowiedników. Obecnie wiele firm - jak np. SourceFire założona przez twórcę opisywanego systemu, Martina Roescha - zajmuje się świadczeniem komercyjnych usług zwiazanych ze Snortem oraz sprzedażą specjalistycznych urządzeń (sprzętowych NIDS'ów), stanowiących rozbudowane sensory oparte o Snorta, podłączane w różnych punktach sieci. Powstaje cała masa aplikacji zwiększająca jego funkcjonalność. Przykładowo pakiet Snortsam łączący Snorta z Checkpoint Firewall-1 lub Cisco Pix. Wystarczy zajrzeć zresztą na i wpisać w wyszukiwarce "snort" - żeby przekonać się ile dodatkowych narzędzi, modułów i rozszerzeń powstaje dla tego popularnego NIDS'a. Prawdziwą jego "siłę przebicia" stanowi przede wszystkim otwarta architektura i duża liczba developerów skupiona wokół projektu. To że wspierany jest on dodatkowo przez wyspecjalizowane firmy zajmujące się bezpieczeństwem - należy chyba uznać za duży plus. - strona domowa systemu Snort - moduł raportujący ACID - biblioteka libnet - SourceFire powrót