Definicja sygnatury (na przykładzie Snort)

W poprzednim artykule pokazałem przykład ataku typu UNION SELECT, czyli metody pozwalającej atakującemu na dołączenie wyników dodatkowych zapytań SQL do oryginalnego zapytania. Atakujący może próbować wysłać do naszej bazy na przykład takie szkodliwe zapytanie:

Atakujący wykonując takie zapytanie ma nadzieję, że baza danych zwróci zarówno produkty jak i dane użytkowników, co atakujący zobaczy na stronie.

Systemy IPS mogą mieć sygnaturę następującej postaci, która dzięki mechanizmowi regex pozwoli na wychwycenie potencjalnego ataku:

Przygotowanie samego filtru dla regex to jednak nie wszystko co jest potrzebne, aby sygnatury działały prawidłowo. Nowoczesne IPSy bazują na bardziej złożonej analityce. W praktyce sygnatura taka, w systemie takim jak Snort mogłaby wyglądać następująco:

Wyjaśnijmy znaczenie poszczególnych parametrów tej sygnatury:

• alert – sposób reakcji na wyzwolenie sygnatury. W tym przypadku to „alert + log”, może być też „drop” aby zablokować
• http $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS – ruch z Internetu do serwerów wewnętrznych za pomocą protokołu HTTP
• msg – wiadomość logowana gdy sygnatura zostanie wyzwolona
• flow:established,to_server – filtruj tylko ruchy w już ustanowionym połączeniu, w kierunku serwera
• content:”UNION” – pierwszy filtr – szukaj słowa UNION w HTTP URI
• nocase – nie zwracaj uwagi na wielkość liter
• http_uri – szukaj w polu URI (nie w headers czy body)
• content:”SELECT” – drugi filtr – szukaj słowa SELECT
• http_uri – znowu wskazanie by szukać w URI
• pcre – zastosuj regularne wyrażenie
• classtype – kategoria zagrożenia
• sid – unikatowy identyfikator reguły
• rev – wersja reguły

Dlaczego aż tyle pól jest w definicji sygnatury? Część z nich jak rev czy sid mają znaczenie organizacyjne. Classtype i msg dają nam możliwość odpowiedniej klasyfikacji i notyfikacji. Natomiast optymalizacja systemu typu IPS polega na tym, że nie każdy pakiet podlega takiej samej analizie. Gdybyśmy chcieli analizować pod kątem każdego ataku każdy z przetwarzany przez IPS pakietów to urządzenia te musiałyby być o bardzo wysokiej mocy (czyli bardzo drogie i „prądożerne”), a jednocześnie wprowadzały by one odczuwalne duże opóźnienia w transmisji danych. Wiele aplikacji wręcz nie toleruje dobrze wzrastających opóźnień. Dlatego ważne jest, aby sygnatury były dostosowane do tego w jakim kierunku występuje flow danych i potencjalne zagrożenie oraz do pewnego kontekstu w ramach którego może się ono objawiać. Odpowiedni dobór sygnatur dla naszego środowiska, czy to sieci korporacyjnej czy centrum przetwarzania danych, jest w gestii zarówno administratora sieci jak i administratora bezpieczeństwa.

W naszej przykładowej sygnaturze działają trzy filtry. Pierwszy z nich przetwarza tylko reguły odpowiadające charakterystyce danego połączenia – jeśli pakiet pochodzi z ruchu do portu 80 (HTTP), ignorowane są reguły dla FTP (port 21). Reguły mogą być filtrowane wg portu, kierunku (czy to żądanie przychodzące czy wychodzące), lub kierunku komunikacji (client-to-server lub server-to-client). Drugi filtr stosuje szybkie porównywanie słów kluczowych. W podanym przykładzie szukamy też najpierw słów kluczowych charakterystycznych dla danego ataku. W naszym przypadku to słowa „UNION” i „SELECT”. Zależności od wyrafinowania ataku tych słów kluczowych może być więcej. W Snort używany jest algorytm Aho-Corasick, który pozwala znaleźć wiele słów jednocześnie. W środku przeglądanego ruchu szukane są charakterystyczne łańcuchy znaków – jeśli ich nie ma, pakiet jest od razu przepuszczony bez dalszej analizy pod kątem danej sygnatury. Trzeci filtr to pełne wyrażenia regularne. Jeśli pakiet zawiera słowa kluczowe, IPS wykonuje złożone wyrażenia regularne, aby potwierdzić, że to rzeczywiście atak.

Wykrywanie anomalii

Systemy IPS starają się, lepiej lub gorzej, uczyć jak wygląda ruch w chronionej sieci. W tym celu ustalają referencyjną linię normalnej aktywności w naszej sieci. Typowo IPS uczy się przez kilka godzin do dni, monitorując zwyczajne użytkowanie sieci. Następnie każdy pakiet jest porównywany z liniami bazowymi. Jeśli parametry statystyczne (liczba pakietów na sekundę, rozmiar pakietu, porty) znacznie odbiegają od normy, system zgłasza anomalię.

Wykrycie anomalii nie powinno jednak automatycznie stanowić przesłanek do zablokowania danego ruchu. Takie odgórne i nadgorliwe podejście może na przykład zablokować wykonywanie się kopii zapasowych systemów czy stacji roboczych. Jest to operacja która jest wykonywana jedynie co jakiś czas i może zostać przez źle dostrojone systemy uznana za atak.

Analiza protokołów stanowych

Każdy protokół ma określone stany (i nie mówię tu o stanach sesji TCP w tym przypadku). Przykładowo w FTP, sesja powinna przejść przez fazy:

1. Logowanie (wysłanie USER i PASS)
2. Autoryzacja (otrzymanie 230 OK)
3. Wykonywanie komend (CWD, LIST, RETR)

IPS zna te stany, rozumie jakie są zasady działania poszczególnych protokołów. Jeśli użytkownik przyśle komendę RETR (pobierz plik) bez wcześniejszego zalogowania, IPS rozpoznaje naruszenie protokołu. Analiza stanowych protokołów jest zarazem bardziej dokładna niż sygnatury (mniej fałszywych alarmów) i bardziej ogólna – chroni przed wieloma wariantami ataku skierowanego na fazy protokołu.

Kontekstowość, ML i analiza behawioralna

Cisco Firepower zbiera informacje o całym środowisku sieciowym – jakie systemy operacyjne działają, jakie urządzenia, jakie aplikacje. Tworzy mapy sieci i profile hostów. Gdy IPS wykryje zagrożenie, może powiedzieć, czy zagrażało webserwerowi czy krytycznym bazom danych. Przykładowo – tradycyjny IPS blokuje SSH brute force attempt. NGIPS zamiast tego sprawdza, czy SSH powinno w ogóle działać na tym hoście. Jeśli wiadomo, że to serwer webowy (port 80 i 443), to SSH na porcie 22 jest anomalią. NGIPS może być bardziej agresywny w blokowaniu.

NGIPS stosuje deep learning do modelowania normalnego zachowania ruchu. Systemy neuronowe (LSTM – Long Short-Term Memory) uczą się na danych historycznych, jakie sekwencje pakietów są normalne, a jakie anomalne. To więcej niż standardowe mechanizmy wykrywania anomalii. Spójrzmy na poniższy przykład: Normalne połączenie do bazy danych zawiera zapytania w trybie tekstowym (SELECT, INSERT). Jeśli nagle w ramach połączenie klient wysyła binarny payload podejrzanie przypominający shellcode, system to rozpozna – nawet jeśli nie ma sygnatury dla tego konkretnego exploitu,

NGIPS może rozpoznać zaawansowane ataki takie jak ruch w sieci botnet typu command-and-control – system widzi małe pakiety wysyłane w regularnych interwałach (charakterystyczne dla botów), co wskazuje na potencjalną infekcję.

Sandbox i evasion detection

Nowoczesne systemy NGIPS zawierają sandbox – lokalny lub chmurowy dostarczany przez producenta. Jest to środowisko do testowania podejrzanych plików w izolacji. Zanim plik dotrze do odbiorcy, NGIPS „detonuje” go w sandboxie i obserwuje zachowanie. Jeśli plik tworzy nowe procesy, modyfikuje rejestry systemowe lub nawiązuje połączenia do znanych C2 serwerów to klasyfikowany jest jako zagrożenie typu malware, nawet jeśli żaden system antywirusowy go jeszcze nie zna.