Ten post pomoże Ci napisać skuteczne reguły Snorta, które znacząco poprawią Twoje bezpieczeństwo. Zaczniemy od tego, jak zbudowana jest reguła, a następnie przeanalizujemy najlepsze praktyki na przykładach, aby wychwycić jak najwięcej złośliwych działań przy użyciu jak najmniejszej liczby reguł.
Snort jest systemem open-source do wykrywania włamań do sieci (NIDS), który zapewnia analizę pakietów w czasie rzeczywistym i jest częścią rozwiązania Coralogix STA. Jeśli jesteś klientem Coralogix STA, sprawdź również mój wcześniejszy wpis o tym, jak edytować reguły Snorta w STA.
Anatomia reguł Snorta
Zanim zagłębimy się w różne strategie pisania najlepszych reguł Snorta, zacznijmy od analizy przykładowej reguły Snorta:
alert: mówi Snortowi, aby zgłosił to zachowanie jako alert (jest obowiązkowe w regułach tworzonych dla STA).
tcp: oznacza, że ta reguła będzie stosowana tylko do ruchu w TCP.
any: w tym kontekście oznacza „z dowolnego portu źródłowego”, następnie jest strzałka ’->’, która oznacza „połączenie do” (nie ma operatora '<-’, ale można po prostu odwrócić argumenty wokół operatora. Możesz użyć operatora '<>’ aby wskazać, że kierunek połączenia jest nieistotny dla tej reguły), następnie zakres IP, który wskazuje docelowy adres IP, a następnie port. Zakres portów można określić za pomocą dwukropka, np. 0:1024, co oznacza 0-1024. W nawiasie okrągłym znajdują się dyrektywy pozwalające ustawić komunikat alarmowy, metadane reguły, jak również dodatkowe kontrole.
msg: jest dyrektywą, która po prostu ustawia komunikat, który zostanie wysłany (do Coralogix w przypadku STA) w przypadku wykrycia pasującego ruchu.
flow: jest dyrektywą, która wskazuje, czy treść, którą zaraz zdefiniujemy jako naszą sygnaturę musi pojawić się w komunikacji do serwera („to_server”) czy do klienta („to_client”). Może to być bardzo przydatne, jeśli np. chcemy wykryć odpowiedź serwera, która wskazuje, że został on złamany.
established: jest dyrektywą, która spowoduje, że Snort ograniczy wyszukiwanie pakietów pasujących do tej sygnatury tylko do pakietów będących częścią nawiązanych połączeń. Jest to przydatne, aby zminimalizować obciążenie Snorta.
uricontent: to dyrektywa, która nakazuje Snortowi szukać określonego tekstu w znormalizowanej zawartości HTTP URI. W tym przykładzie, szukamy adresu url, który jest dokładnie tekstem „/root.exe”.
nocase: jest dyrektywą, która wskazuje, że chcemy, aby Snort przeprowadził wyszukiwanie bez uwzględniania wielkości liter.
classtype: jest dyrektywą, która jest atrybutem metadanych wskazującym, jaki typ aktywności ta reguła wykrywa.
reference: jest dyrektywą, która jest atrybutem metadanych, który odsyła do innego systemu, aby uzyskać więcej informacji. W naszym przykładzie, wartość url,<https://….> odsyła do adresu URL w Internecie.
sid: jest dyrektywą, która jest atrybutem metadanych wskazującym identyfikator podpisu. Jeśli tworzysz własną sygnaturę (nawet jeśli tylko zastępujesz wbudowaną regułę), użyj wartości powyżej 9,000,000, aby zapobiec kolizji z inną istniejącą regułą.
rev: jest dyrektywą, która wskazuje wersję reguły.
Jest jeszcze wiele do nauczenia się o regułach Snorta, które wspierają parsowanie RegEx, parsowanie specyficzne dla protokołu (tak jak uricontent dla HTTP), szukanie danych binarnych (nietekstowych) przy użyciu wartości heksadecymalnych bajtów, i wiele więcej. Jeśli chcesz dowiedzieć się więcej, możesz zacząć tutaj.
Najlepsze praktyki pisania skutecznych reguł Snorta
- Ukierunkowanie na lukę, nie na exploit – Unikaj pisania reguł wykrywających konkretny zestaw exploitów, ponieważ istnieje niezliczona ilość exploitów na tę samą lukę i możemy być pewni, że nowe są pisane w czasie, gdy to czytasz. Na przykład, wiele z wczesnych sygnatur wykrywających ataki typu buffer overrun wyglądało tak:
alert tcp $EXTERNAL_NET any -> $HOME_NET 80 (content:"AAAAAAAAAAAAAA", msg:"Buffer overrun detected.")
Powodem tego jest oczywiście to, że aby przeprowadzić udany atak typu buffer overrun, atakujący musi wypełnić bufor pewnej zmiennej i dodać swój złośliwy payload na końcu tak, aby stał się on wykonywalny. Znaki, które wybierze do wypełnienia bufora są zupełnie nieistotne i rzeczywiście, po pojawieniu się takich sygnatur, wiele zestawów narzędzi do ataku po prostu użyło innej litery lub liter do wypełnienia bufora i całkowicie uniknęło wykrycia przez tego typu sygnatury. Znacznie lepszym sposobem byłaby próba wykrycia tego rodzaju ataków poprzez wykrywanie nieprawidłowego wprowadzania danych do pól na podstawie ich typu i długości.
- Twoja osobliwość jest Twoim najlepszym atutem, więc wykorzystaj ją – Każda organizacja ma rzeczy, które czynią ją wyjątkową. Wiele z nich może być całkiem przydatnych, gdy próbujesz wyłapać złośliwe działania w Twojej organizacji – zarówno zewnętrzne, jak i wewnętrzne. Wykorzystując tę głęboką wiedzę wewnętrzną na swoją korzyść, zasadniczo przekształcisz problem z technologicznego na czysto wywiadowczy, zmuszając atakujących do bardziej dogłębnego zrozumienia Twojej organizacji, aby móc skutecznie ukryć swoje ślady. Te rzeczy mogą mieć charakter technologiczny lub opierać się na szczególnych nawykach pracy i wewnętrznych wytycznych Twojej organizacji. Oto kilka przykładów:
- Typowe godziny pracy: Niektóre organizacje, w których pracowałem, nie pozwalały pracownikom na pracę w domu w ogóle, a większość pracowników opuściłaby już biuro przed 19:00. Dla podobnych organizacji sensowne byłoby ustawienie alertu, który powiadamiałby o połączeniach z biura po określonej godzinie. Atakujący, który zainstalowałby złośliwe oprogramowanie w Twojej organizacji musiałby znać to zachowanie i dostroić swoje złośliwe oprogramowanie tak, aby komunikowało się ze swoimi serwerami Command & Control dokładnie w tym samym czasie, taka komunikacja pozostałaby niezauważona.
- Typowa przeglądarka: Załóżmy, że Twoja organizacja zdecydowała się używać przeglądarki Brave jako swojej głównej przeglądarki i jest ona instalowana na każdym nowym laptopie firmowym automatycznie, a Ty usunąłeś skróty pulpitu do przeglądarki IE/Edge ze wszystkich swoich laptopów firmowych. W takim przypadku połączenie z organizacji, zarówno na adres wewnętrzny jak i zewnętrzny, które korzysta z innej przeglądarki np. IE/Edge powinno być skonfigurowane tak, aby wywołać alarm.
- Zakresy IP oparte na rolach: Jeśli możliwe jest przypisanie różnych zakresów IP dla różnych serwerów w zależności od ich roli, na przykład, aby wszystkie serwery DB na 192.168.0.0/24, serwery WWW na 192.168.1.0/24, itp. wtedy byłoby możliwe, a nawet łatwe do skonfigurowania sprytnych reguł opartych na oczekiwanym zachowaniu serwerów w zależności od ich roli. Na przykład, serwery baz danych zazwyczaj nie łączą się z innymi serwerami samodzielnie, drukarki nie próbują łączyć się z kontrolerami domeny, itp.
- Nietypowe próby połączeń: Wiele organizacji używa publicznego udziału na serwerze plików, aby pomóc swoim użytkownikom udostępniać pliki między nimi i używać drukarek sieciowych, aby umożliwić swoim użytkownikom drukowanie bezpośrednio z ich komputerów. Oznacza to, że komputery klienckie nie powinny łączyć się ze sobą, nawet jeśli (mądrze) zdecydowałeś się zablokować taki dostęp w zaporze lub na przełączniku, sama próba połączenia z jednego klienta do innego komputera klienckiego powinna wzbudzić alarm i zostać dokładnie zbadana.
- Nietypowe porty: Niektóre organizacje używają specjalnej biblioteki do optymalizacji komunikacji między usługami tak, że cała komunikacja HTTP między serwerami używa innego portu niż powszechnie stosowane (takie jak 80, 443, 8080, itp.). W tym przypadku, dobrym pomysłem jest stworzenie reguły, która będzie wyzwalana przez każdą komunikację na tych normalnie powszechnych portach.
- Honeytokens – Na polu bitwy, jakim jest Internet, gdzie każdy może być po prostu każdym, oszustwo, działa dobrze dla obrońców tak samo dobrze jak dla atakujących, jeśli nie lepiej. Sztuczki takie jak zmiana nazwy wbudowanego konta administratora na inną, mniej atrakcyjną nazwę i stworzenie nowego konta o nazwie Administrator, którego nigdy nie użyjesz i stworzenie reguły Snort do wykrywania, czy ta nazwa użytkownika, e-mail lub hasło są kiedykolwiek używane w sieci. Byłoby prawie niemożliwe, aby napastnicy zauważyli, że Snort wykrył ich próby użycia fałszywego użytkownika administratora. Innym przykładem może być tworzenie w bazie danych fałszywych produktów, klientów, użytkowników i kart kredytowych, a następnie dopasowywanie reguł Snorta do wykrywania ich w ruchu sieciowym.
Mamy nadzieję, że te informacje okazały się pomocne. Aby uzyskać więcej informacji na temat Coralogix STA, sprawdź najnowsze funkcje, które ostatnio udostępniliśmy.