Tworzenie i testowanie własnych sygnatur IPS w Sophos Firewall

Własna sygnatura IPS jest przydatna, gdy Sophos nie dostarcza odpowiedniej sygnatury dla jasno określonego wzorca sieciowego lub aplikacyjnego. Może wykrywać znany ciąg tekstu jawnego, nietypową cechę protokołu albo precyzyjną kombinację portu, kierunku i payloadu.

Sama sygnatura jeszcze niczego nie chroni. Musi zostać użyta w IPS policy, ta policy musi być przypisana do faktycznie dopasowanej reguły firewalla, a strumień danych musi być widoczny dla IPS. Zbyt szeroki wzorzec może blokować prawidłowy ruch, a zbyt wąski nie wygeneruje trafienia.

Nową sygnaturę należy najpierw testować z Allow packet i loggingiem na małej ścieżce pilotażowej. Drop packet, Drop session, Reset i Bypass session zmieniają ruch produkcyjny i powinny być używane dopiero po powtarzalnym teście pozytywnym i negatywnym.

Kontrolowany pilotaż w sześciu krokach

1. Opisać przypadek wykrycia za pomocą protokołu, kierunku, portu i jednoznacznego wzorca.
2. W Intrusion prevention > Custom IPS signatures utworzyć precyzyjną sygnaturę z Allow packet.
3. Dodać sygnaturę do osobnej reguły w usuwalnej IPS policy.
4. Przypisać tę IPS policy wyłącznie do przewidzianej reguły pilotażowej firewalla i włączyć logging.
5. Wygenerować jeden pasujący i jeden celowo niepasujący test, a następnie porównać Log Viewer, ips.log i dopasowanie reguły.
6. Ustawić docelową akcję dopiero po stabilnym odbiorze; przy nieoczekiwanych trafieniach usunąć przypisanie policy lub sygnaturę.

Zapisany wpis albo poprawna weryfikacja składni nie są jeszcze dowodem działania. Sukces oznacza, że test pozytywny trafia dokładnie w oczekiwaną Custom Signature i regułę firewalla, test negatywny nie generuje trafienia, a aplikacja produkcyjna działa jak wcześniej.

Kiedy własna sygnatura jest właściwym wyborem

Custom Signatures sprawdzają się przy stabilnej cesze widocznej na poziomie pakietu lub strumienia. Może to być własna wartość protokołu, wyraźny wskaźnik exploita lub tymczasowa ochrona znanej wewnętrznie podatności. Oczekiwana ścieżka danych i planowana reakcja muszą być określone przed zapisaniem sygnatury.

W przypadku zmiennych adresów IP lub domen zwykle lepiej sprawdzają się hosty, usługi i grupy, threat feeds albo precyzyjne reguły firewalla. Własna sygnatura nie zastępuje także zarządzania poprawkami ani dobrze utrzymywanej reguły producenta. Tworzenie stałej sygnatury dla pojedynczego zdarzenia w logu rzadko jest proporcjonalne.

Zaszyfrowany payload stanowi istotną granicę. IPS może wykryć wzorzec content w payloadzie HTTPS tylko wtedy, gdy treść została faktycznie odszyfrowana i jest widoczna dla silnika w wybranej ścieżce przetwarzania. Bez odpowiedniej TLS Inspection zwykle dostępne są tylko cechy niezaszyfrowane lub widoczne w inny sposób.

Najpierw sprawdzić licencję i cykl życia

Własnych sygnatur nie można konfigurować, jeśli wygasła wersja próbna IPS lub IPS Protection jest wyłączone w Intrusion prevention > IPS policies. Sophos zaleca ponowne włączenie IPS w ciągu 30 dni, jeżeli istniejące Custom Signatures mają zostać zachowane. Backup lub eksport powinny więc należeć do planu rollbacku przed zmianami licencji, IPS lub większymi zmianami policy.

Następnie IPS musi być aktywny globalnie, a reguła firewalla przetwarzająca ruch wymaga IPS policy. Pełną konfigurację bazową opisuje Konfigurowanie i bezpieczne testowanie IPS w Sophos Firewall. Własna sygnatura rozszerza tę ścieżkę danych, nie jest równoległym mechanizmem ochrony.

Świadomie zawęzić składnię reguły

Formularz rozdziela Protocol i Custom rule. Reguła łączy poszczególne słowa kluczowe, ich wartości i średniki. Wymaganie zgodności kilku niezależnych cech zwykle ogranicza przypadkowe trafienia. Jednocześnie sygnatura nie może być tak szczegółowa, aby niewielka zmiana protokołu pozbawiła ją skuteczności.

W całkowicie kontrolowanym teście tekstu jawnego można wybrać protokół TCP i zastosować na przykład taki precyzyjny wzorzec payloadu:

content:"AVANET-IPS-PILOT"; nocase;

AVANET-IPS-PILOT to celowo wyróżniająca się wartość dokumentacyjna. Odpowiednia pilotażowa reguła firewalla jest dodatkowo ograniczona do usługi testowej, na przykład portu TCP 8080. Token, kierunek i port należy zastąpić wartościami występującymi w rzeczywistym strumieniu widocznym dla IPS. Ten przykład nie jest uniwersalną sygnaturą ataku i nie powinien być bez zmian przypisywany do szerokich reguł produkcyjnych.

Payload i okno wyszukiwania

content szuka sekwencji znaków lub bajtów; wartości binarne zapisuje się między znakami pionowej kreski. nocase ignoruje wielkość liter przy dopasowaniu content, a rawbytes pracuje na danych surowych. depth i offset ograniczają wyszukiwanie bezwzględnie w payloadzie, natomiast distance i within działają względem poprzedniego trafienia. uricontent, isdataat i pcre obsługują bardziej specjalistyczne przypadki URI, położenia i wyrażeń regularnych.

Wąskie okno wyszukiwania ogranicza przypadkowe trafienia i obciążenie obliczeniowe. Szczególnie pcre, duże okna i kilka szerokich wzorców content należy wprowadzać wyłącznie z realistycznymi pakietami i przy obserwowanym obciążeniu. Jeśli depth jest krótsze niż szukany wzorzec content, sygnatura nigdy nie zadziała.

Nagłówki, strumienie i wartości strukturalne

Źródło, cel i port można zawęzić za pomocą srcaddr, dstaddr, srcport i dstport. Dla nagłówków IP dostępne są między innymi ttl, tos, id, ipopts, fragoffset, fragbits, dsize, ip_proto i samip. Cechy TCP opisują flags, flow, seq, ack i window; itype, icode, icmp_id i icmp_seq dotyczą ICMP. rpc, byte_test i byte_jump są przeznaczone dla protokołów strukturalnych lub binarnych.

Pełna dokumentacja składni własnych sygnatur IPS w SFOS 22 pozostaje wiążąca dla złożonych reguł. Nie należy bez weryfikacji przejmować nieudokumentowanych słów kluczowych Snort ani reguł skopiowanych z innych silników.

Utworzyć sygnaturę i przypisać ją do policy

W Intrusion prevention > Custom IPS signatures > Add określa się Name, Protocol, Custom rule, Severity i Recommended action. Nazwa taka jak PILOT-TCP-8080-AVANET-TOKEN pokazuje cel i granicę testu. Severity opisuje własną ocenę ryzyka; nie dowodzi złośliwości wzorca.

W pierwszym teście Recommended action pozostaje ustawione na Allow packet. Pozostałe akcje mają znacznie silniejsze skutki:

• Drop packet odrzuca tylko pasujący pakiet.
• Drop session kończy sesję po trafieniu.
• Reset kończy sesję TCP i wysyła reset do źródła.
• Bypass session zezwala na ruch i nie skanuje dalszej części sesji.

Podczas zapisywania SFOS rekonfiguruje silnik IPS. Według Sophos odbywa się to bez przerwy, jeśli dostępna jest wystarczająca ilość wolnej pamięci RAM. Przy małej ilości wolnej pamięci silnik może się zrestartować i spowodować krótką przerwę. Nawet pozornie niewielka zmiana sygnatury powinna zatem odbywać się w obserwowanym oknie.

Następnie wykonywany jest często pomijany drugi krok: w Intrusion prevention > IPS policies otworzyć usuwalną policy przeznaczoną do pilotażu, dodać regułę, wybrać Custom Signature i umieścić konkretną regułę nad regułami szerszymi. Później przypisać tę policy w Rules and policies > Firewall rules do faktycznie dopasowanej reguły pilotażowej.

Wykonać test pozytywny i negatywny

Test pozytywny wysyła uzgodniony wzorzec przez przewidziany port i we właściwym kierunku. Równocześnie w Log Viewer rejestrowane są Firewall Rule ID, IPS policy, nazwa sygnatury, źródło, cel, akcja i czas. ips.log zawiera dodatkowe szczegóły silnika; Systematyczne testowanie reguły firewalla wyjaśnia związek między regułą, Packet Capture i modułem bezpieczeństwa.

Następnie wykonuje się co najmniej jeden test negatywny: tę samą usługę bez tokena, inny port lub inny kierunek. Sygnatura nie może wtedy zadziałać. W przypadku wzorca content ważne są również normalne żądania aplikacji, ponieważ krótkie lub ogólne ciągi mogą występować w całkowicie prawidłowych payloadach.

Dopiero po stabilnych wynikach obu testów ustawia się planowaną akcję blokującą i ponownie ją sprawdza. Sygnatura blokująca jest odebrana tylko wtedy, gdy zatrzymuje dokładnie przypadek pozytywny, przypadek negatywny działa dalej, a efektu nie powoduje żadna inna reguła firewalla lub IPS.

Sprawdzić liczbę sygnatur

Liczbę można znaleźć w WebAdmin bez używania powłoki. W Intrusion prevention > IPS policies otworzyć usuwalną policy i dodać nową regułę policy. Po wybraniu Select all SFOS pokazuje sumę nad Action. Lista jest widoczna tylko podczas dodawania reguły do usuwalnej policy; następnie można zamknąć okno bez zapisywania.

Sophos dokumentuje również dwa zapytania tylko do odczytu w Advanced Shell:

psql -U nobody -d signature -p 5434 -c "select count (*) from tblidprules;"
psql -U nobody -d corporate -c "select count (*) from tblidpcustomsignature;"

Pierwsze polecenie liczy sygnatury domyślne, a drugie Custom Signatures. Te zapytania do bazy danych niczego nie zmieniają, ale nadal powinny być częścią udokumentowanej sesji wsparcia lub diagnostyki. Liczba nie dowodzi jakości ani działania i może się zmieniać wraz z aktualizacjami wzorców.

Gdy sygnatura nie działa zgodnie z oczekiwaniami

Nie ma trafienia

Najpierw należy sprawdzić, czy IPS jest aktywny, ruch trafia w oczekiwaną regułę firewalla z właściwą IPS policy, a Custom Signature rzeczywiście znajduje się w ocenianej regule policy. Następnie sprawdza się protokół, kierunek, port, szyfrowanie i rzeczywisty payload. Ciąg widoczny w przeglądarce nie musi występować bez zmian w pakiecie sieciowym.

Precyzyjnie filtrowany Packet Capture pomaga potwierdzić widoczną treść i kierunek. Jeśli wzorca już tam nie ma, zmiana reguły IPS go nie utworzy. Jeżeli pakiety są widoczne, należy sprawdzić offset, depth, distance, within, stan strumienia i kolejność reguł policy.

Pasuje zbyt wiele połączeń

Sygnatura pozostaje na Allow packet, dopóki źródło, cel, port, kierunek lub okno wyszukiwania nie zostaną bardziej zawężone. Ogólne słowa, krótkie sekwencje binarne i nieograniczone wyrażenia regularne są typowymi przyczynami. Szeroka reguła firewalla dodatkowo utrudnia kontrolę efektu.

Jeśli po zapisaniu firewall pokazuje wzrost użycia zasobów lub restart IPS, należy zabezpieczyć czas, model, firmware, wolne zasoby i ips.log. Wielokrotne zapisywanie różnych wariantów nie jest wtedy czystym testem; najpierw trzeba wyjaśnić przyczynę i okno serwisowe.

Bezpiecznie wycofać zmianę

Przy nieoczekiwanych trafieniach najpierw usuwa się własną regułę z policy pilotażowej albo przywraca poprzednią IPS policy w regule firewalla. Następnie sprawdza się nowe sesje testem pozytywnym i negatywnym. Custom Signature usuwa się dopiero wtedy, gdy nie ma żadnego innego zastosowania.

Przed usunięciem należy udokumentować policy, regułę firewalla i aplikację, które jej używały. Logi, testowana wersja reguły i przyczyna rollbacku należą do dokumentacji zmiany. Globalne wyłączenie IPS albo usunięcie całej policy produkcyjnej nie jest odpowiednim rollbackiem dla jednej wadliwej sygnatury.

FAQ