Snort: klasyczny system wykrywania włamań w praktyce

Snort to dojrzałe, potężne narzędzie do przechwytywania i analizy ruchu sieciowego. Jego znajomość jest bardzo przydatna dla każdego specjalisty ds. bezpieczeństwa.
Snort to narzędzie służące do przechwytywania i analizy pakietów, mogące również pełnić funkcję lekkiego systemu wykrywania włamań (IDS) i zapobiegania im (IPS). Jego pierwsza wersja pojawiła się ponad dwadzieścia lat temu. Od tamtej pory program jest stale rozwijany; od 2013 jest własnością Cisco. Ponieważ jest udostępniony na warunkach licencji open source, można go znaleźć w różnych projektach związanych z analizą ruchu sieciowego, np. w otwartych SIEM-ach, gdzie zwykle pełni funkcję czujnika. Program może działać w trzech głównych trybach. Pierwszym z nich jest tryb sniffera, w którym wszystkie przechwycone pakiety zostają wyświetlone na ekranie. W trybie tym niewiele różni się od zwykłego Tcpdumpa. Drugim jest tryb rejestracji pakietów, w którym Snort zamiast wyświetlać pakiety, rejestruje je na dysku. Wreszcie trzeci tryb służy do analizy ruchu sieciowego i umożliwia podjęcie odpowiednich działań w oparciu o podane reguły. Tryb sniffera Uruchamianie Snorta w trybie sniffera (domyślnym) na systemie produkcyjnym nie jest często praktykowane ze względu na dużą liczbę pakietów. Co więcej, użycie przełącznika -v, który zwiększy liczbę wyświetlanych informacji na temat pakietów, spowoduje, że zaczniemy gubić pakiety. Może się jednak zdarzyć, że zechcemy sprawdzić, jakie pakiety przechodzą przez dany interfejs, np. eth2. W tym przypadku możemy użyć polecenia:

snort -i eth2 -dev

Opcja -d powoduje wyświetlenie danych warstwy aplikacji, zaś -e – warstwy łącza danych. Tryb rejestratora pakietów Rejestracja pakietów na dysku umożliwia ich natychmiastową lub późniejszą analizę. Aby go włączyć, wystarczy podać Snortowi argument -l nazwa_katalogu, np.:

snort -l /var/log/snort

Przy czym podany katalog musi istnieć, w przeciwnym razie Snort wyświetli komunikat o błędzie i zakończy działanie. Po chwili w podanym katalogu pojawi się plik o nazwie snort.log.identyfikator zawierający pakiety w formacie Pcap. Możemy go zatem odczytać Tcpdumpem:

tcpdump -r /var/log/snort

Nic jednak nie stoi na przeszkodzie, by móc odczytać go również Snortem:

snort -dev -r /var/log/snort

 
Możemy też wyświetlić jedynie pakiety określonego typu (TCP, UDP, ICMP):

snort -dev -r /var/log/snort udp

W celach testowych zamiast Pcapa możemy użyć formatu ASCII (opcja -K ascii). W katalogu przekazanym opcją -l zostaną wtedy utworzone podkatalogi odpowiadające nazwom hostów, a w nich pliki z danymi dotyczącymi pakietów. Ponieważ bardzo szybko katalog zostanie zapełniony ogromną liczbą podkatalogów, jest to mało praktyczny tryb rejestracji na systemach produkcyjnych. Tryb NIDS Tradycyjna klasyfikacja systemów wykrywania włamań (IDS) to systemy oparte na hoście (HIDS) i sieciowe (NIDS). Systemy HIDS szukają wzorców i anomalii w funkcjonowaniu danego hosta, natomiast NIDS skupiają się na analizie ruchu sieciowego. Sercem Snorta jest system reguł, które sterują działaniem programu. Aby włączyć tryb NIDS w Snorcie, przekazujemy mu argument -c snort.conf, gdzie snort.conf to pełna ścieżka dostępu do pliku konfiguracyjnego zawierającego referencje do reguł Snorta. Program będzie nadal przechwytywał cały ruch sieciowy, sprawdzając jednocześnie, czy pakiety pasują do podanych reguł, i na tej podstawie podejmie odpowiednie działanie. Tego rodzaju konfiguracja jest zwykle domyślna w większości systemów linuksowych. W Windows oprócz instalatora Snorta będzie nam potrzebna biblioteka WinPcap; przydatny jest też serwer Sysylog. Aby odczytać pliki dziennika zapisane przez Snorta, używamy dostarczonego w pakiecie narzędzia u2spewfoo, ponieważ domyślnie Snort zapisuje pliki w binarnym formacie unified2 (którego elementy można dostosować do potrzeb danego środowiska w pliku konfiguracyjnym). Pojedynczy wpis odczytany za pomocą u2spewfoo widzimy na Listingu 1.

Listing 1: Pojedyncze zdarzenie zarejestrowane w pliku /var/log/snort.log

(Event)

        sensor id: 0    event id: 378   event second: 1585569478        event microsecond: 459515

        sig id: 486     gen id: 1       revision: 4      classification: 29

        priority: 3     ip source: 215.154.167.5        ip destination: 131.14.127.17

        src port: 3     dest port: 10   protocol: 1     impact_flag: 0  blocked: 0

        mpls label: 0   vland id: 0     policy id: 0

Packet

        sensor id: 0    event id: 378   event second: 1585569478

        packet second: 1585569478       packet microsecond: 459515

        linktype: 1     packet_length: 82

[    0] 54 04 A6 A6 8F 51 F4 CC 55 4B 52 18 08 00 45 00  T....Q..UKR...E.

[   16] 00 44 19 C3 00 00 37 01 D9 D4 C3 36 A7 3A B0 09  .D....7....6.:..

[   32] 75 A7 03 0A 8D 32 00 00 00 00 45 00 00 28 E7 68  u....2....E..(.h

[   48] 40 00 3B 06 C8 45 B0 09 75 A7 C3 36 A7 3A 27 5B  @.;..E..u..6.:’[

[   64] DD 5A 00 00 00 00 E7 DB A4 07 50 14 00 00 8F 15  .Z........P.....

[   80] 00 00                                            ..

Snorta w trybie NIDS uruchamiamy zwykle w trybie demona (z opcją -D). W większości popularnych dystrybucji znajdziemy wstępnie przygotowany plik konfiguracyjny, który trzeba będzie dostosować do wymagań danej instalacji. Tryb NIDS zawiera trzy tryby poboczne: pasywny (passive), aktywny (inline) i testowy (inline-test). Tryb aktywny umożliwia zrywanie połączeń – zostają załadowane i uaktywnione te reguły, które umożliwiają przerwanie połączenia odpowiadającego danemu wzorcowi. Tryb ten włączamy opcją -Q Snorta lub opcją policy_mode:inline w pliku konfiguracyjnym snort.conf. Z kolei tryb pasywny (policy_mode:tap) nie umożliwia zrywania połączeń. Do testów używamy trybu testowego (opcja --enable-inline-test w wierszu poleceń ipolicy_mode:inline_test). Plik konfiguracyjny Ponieważ Snort jest aktywnie rozwijany od wielu lat, do dyspozycji mamy ogromną liczbę opcji konfiguracyjnych. Wraz z programem dystrybuowany jest przykładowy plik konfiguracyjny, który należy dostosować do własnych potrzeb w dziewięciu etapach, począwszy od zdefiniowania zmiennych sieciowych używanych w głównej konfiguracji, a skończywszy na konfiguracji zestawów reguł. Plik zawiera wiele komentarzy, które znacznie ułatwiają pracę; szczegółowe informacje na temat poszczególnych sekcji znajdziemy w dokumentacji projektu. Reguły Snorta Jak wspomnieliśmy, całe zachowanie Snorta definiujemy za pomocą zestawów reguł. Przykładową regułę zamieściliśmy na Listingu 2. Reguła ta może wydawać się skomplikowana, w istocie jednak jest stosunkowo prosta – składa się z szeregu elementów, które zostały szczegółowo opisane w dokumentacji. Przyjrzyjmy się kilku z nich. Słowo kluczowe alert wskazuje na działanie wykonywane przez daną regułę i w tym przypadku oznacza, że powinno zostać wygenerowanie powiadomienie za pomocą wybranej metody powiadamiania, zaś dany pakiet powinien zostać zarejestrowany. W trybie pasywnym do dyspozycji mamy jeszcze dwa inne działania: log, czyli samo zarejestrowanie pakietu, oraz pass – zignorowanie go. W trybie aktywnym możliwe są trzy dodatkowe działania: drop, czyli zablokowanie i zarejestrowanie pakietu, reject, czyli zablokowanie i zarejestrowanie pakietu połączone z wysłaniem resetu TCP (TCP, ICMP) lub komunikatu o niedostępnym porcie (UDP), oraz sdrop, czyli zablokowanie pakietu bez rejestrowania go. Kolejne słowo kluczowe, tcp, wskazuje na protokół. Obecnie Snort obsługuje jedynie cztery protokoły: TCP, IP, UDP oraz ICMP. Następnie mamy adres IP i port, po których następuje operator kierunku (czyli -> w przypadku ruchu w jednym kierunku i <> w przypadku ruchu w obu kierunkach) a następnie kolejny adres IP i port. Adres IP może być przedstawiony w notacji CIDR. Słowo kluczowe any oznacza dowolny port, można też użyć zakresu portów, np. porty do 1024 włącznie zapiszemy jako :1024. Przy adresach IP i portach możemy korzystać z operatora negacji !. Zwróćmy uwagę, że istnieje tylko jeden operator ruchu jednokierunkowego (->, nie <-), by zwiększyć czytelność reguł. Dalej następuje element zasadniczy, czyli opcje reguł. Opcje reguł są oddzielone od siebie średnikami, zaś poszczególne ich argumenty – dwukropkami. Zatem dwie pierwsze opcje reguł w przykładzie powyżej to msg iflow. Opcja msg zawiera komunikat, który zostanie zarejestrowany wraz z pakietem, zaś flow określa kierunek transmisji. Automatyzacja W większości organizacji ręczne wpisywanie reguł Snorta nie jest praktykowane ze względu na niską efektywność takiego rozwiązania: po pierwsze, trzeba się o danym zagrożeniu dowiedzieć, po drugie, móc je przetestować, po czwarte, napisać regułę, która wykryje dane zagrożenie, nie powodując fałszywych alarmów. Przy ogromnej liczbie pojawiających się codziennie ataków takie podejście jest z góry skazane na porażkę. Threat Intelligence (TI) oznacza w praktyce, że wykorzystywane są reguły stworzone przez dedykowane zespoły. W przypadku Snorta do dyspozycji mamy szereg zestawów reguł, przy czym najbardziej przydatne znajdziemy na witrynie projektu. Do dyspozycji mamy dwa rodzaje reguł: płatne i bezpłatne. Bezpłatne udostępniane są miesiąc po płatnych, co zasadniczo redukuje ich przydatność jako elementu nawet najbardziej podstawowego IDS-a – włamywacz ma co najmniej miesiąc, na wypróbowanie danego ataku, a Snort nawet go nie zarejestruje. Wersja płatna zestawów reguł kosztuje 400 USD rocznie za czujnik. Istnieje też kosztująca 30 USD wersja do użytku osobistego i zastosowań edukacyjnych (nie jest zatem dostępna dla organizacji pozarządowych). Bez względu na to, na który rodzaj reguł się zdecydujemy, powinniśmy pobrać kod Oink (oinkcode), który pełni funkcję kodu dostępu do reguł. Same reguły pobieramy skryptem PulledPork [3]. Egzamin SSFSNORT Jeśli jesteśmy zainteresowani zabezpieczaniem sieci z wykorzystaniem Snorta, możemy zapisać się na kurs Securing Cisco Networks with Open Source Snort [1] i przystąpić do egzaminu SSFSNORT [2]. Zdanie egzaminu nie upoważnia jednak do otrzymania certyfikatu Cisco.
Podsumowanie Snort jest dojrzałym narzędziem do przechwytywania i klasyfikacji pakietów, który może pełnić funkcję systemu wykrywania włamań lub zapobiegania im. Snort jest wykorzystywany w wielu większych projektach związanych z bezpieczeństwem sieci, pełniąc rolę czujnika. Można go też używać samodzielnie, jednak najbardziej skuteczny będzie po wykupieniu subskrypcji reguł.

Listing 2: Przykładowa reguła Snorta wykrywająca atak na Chrome.

alert tcp $EXTERNAL_NET any -> $SMTP_SERVERS 25 (msg:”BROWSER-CHROME Google Chrome V8 engine memory corruption attempt”; flow:to_server,established; file_data; content:”Object.preventExtensions(„; fast_pattern:only; content:”Object.seal(„; content:”Object.seal(„; within:60; distance:50; content:”: Object|7D|”; within:50; content:”.__proto__”; within:55; metadata:policy max-detect-ips drop, policy security-ips drop, service smtp; reference:url,blog.exodusintel.com/2019/09/09/patch-gapping-chrome/; classtype:attempted-user; sid:52349; rev:1;)

Poznanie składni r eguł Snorta może być bardzo przydatne podczas prac nad architekturą sieci. Stworzenie własnych reguł bywa niezbędne w przypadku sieci o złożonej architekturze bądź korzystających z niestandardowych rozwiązań. Snort może nas np. poinformować o próbie dostępu do segmentu sieci, z którym żadne hosty nie powinny się komunikować. Niniejszy artykuł pochodzi z nowego magazynu „Cyberbezpieczeństwo. Przewidywanie zagrożeń. Ochrona sieci i systemów. Prawo w praktyce”. Numer próbny magazynu można otrzymać na stronie https://cyberbezpieczenstwo.wip.pl/ Info [1] Kurs Securing Cisco Networks with Open Source Snort: https://www.cisco.com/c/us/training-events/training-certifications/training/training-services/courses/securing-cisco-networks-with-open-source-snort-ssfsnort-v2-0.html [2] Egzamin SSFSNORT: https://www.globalknowledge.com/us-en/course/90187/ssfsnort-securing-cisco-networks-with-open-source-snort/ [3] PulledPork: https://github.com/shirkdog/pulledpork

Zaloguj się, aby dodać komentarz

Nie masz konta? Zarejestruj się »

Zobacz także

Skuteczne narzędzia do wykrywania uszkodzonych podzespołów

pobierz

Wykrywanie i usuwanie niechcianych programów

pobierz

Polecane artykuły

Array ( [docId] => 50142 )

Array ( [docId] => 50142 )