Tworzenie i testowanie własnych sygnatur IPS w Sophos Firewall

Własna sygnatura IPS ma sens, gdy Sophos nie dostarcza odpowiedniej sygnatury dla jasno opisanego wzorca sieciowego lub aplikacyjnego. Może ona na przykład wykrywać znany ciąg tekstowy przesyłany bez szyfrowania, nietypową cechę protokołu albo precyzyjne połączenie portu, kierunku i zawartości pakietu.

Sama sygnatura jeszcze niczego nie chroni. Musi być używana w polityce IPS, ta polityka musi być przypisana do reguły zapory, która faktycznie obsługuje dany ruch, a strumień danych musi być widoczny dla IPS. Zbyt szeroki wzorzec może blokować legalny ruch, a zbyt wąski nie będzie generować trafień.

Nową sygnaturę należy najpierw przetestować w pilotażowej regule IPS z ustawieniem Action: Allow packet. Nawet jeśli Recommended action jest już ustawione na Allow packet, decyduje akcja reguły polityki IPS. Drop packet, Drop session, Reset lub Bypass session zmieniają ruch produkcyjny i powinny zostać wdrożone dopiero po powtarzalnym teście pozytywnym i negatywnym.

Kontrolowany pilotaż w sześciu krokach

1. Opisz przypadek wykrywania, określając protokół, kierunek, port i jednoznaczny wzorzec.
2. W Intrusion prevention > Custom IPS signatures utwórz sygnaturę z precyzyjnie zawężoną regułą i ustawieniem Recommended action: Allow packet.
3. Dodaj sygnaturę do osobnej reguły w polityce IPS, którą można usunąć, i wybierz w niej Action: Allow packet.
4. Przypisz tę politykę IPS wyłącznie do przewidzianej pilotażowej reguły zapory i włącz w niej Log firewall traffic.
5. Wygeneruj test pasujący do wzorca oraz test celowo niepasujący i porównaj Log Viewer, ips.log oraz dopasowanie reguły.
6. Zmień akcję reguły polityki IPS dopiero po uzyskaniu stabilnych wyników odbioru; w przypadku nieoczekiwanych trafień przywróć poprzednie przypisanie polityki.

Zapisany wpis ani pomyślna kontrola składni nie są jeszcze dowodem poprawnego działania. Sukces oznacza, że test pozytywny trafia dokładnie w oczekiwaną niestandardową sygnaturę i regułę zapory, test negatywny nie generuje trafień, a aplikacja produkcyjna zachowuje się tak samo jak wcześniej.

Kiedy warto użyć własnej sygnatury

Niestandardowe sygnatury nadają się do wykrywania stabilnej cechy widocznej na poziomie pakietu lub strumienia. Może to być wartość w protokole własnościowym, jednoznaczny wskaźnik exploita albo tymczasowa ochrona przed podatnością znaną wewnątrz organizacji. Oczekiwana ścieżka danych i pożądana reakcja muszą zostać ustalone przed rozpoczęciem pisania.

W przypadku zmieniających się adresów IP lub domen zwykle lepiej sprawdzają się hosty, usługi i grupy, źródła Threat Feed lub precyzyjnie zawężone reguły zapory. Niestandardowa sygnatura nie zastępuje też ani zarządzania poprawkami, ani poprawnej reguły producenta. W przypadku pojedynczego trafienia w logu trwałe opracowywanie własnego rozwiązania rzadko jest uzasadnione.

Istotnym ograniczeniem są zaszyfrowane dane użytkowe. IPS może wykryć wzorzec content w zawartości HTTPS tylko wtedy, gdy treść jest rzeczywiście odszyfrowywana w wybranej ścieżce przetwarzania i widoczna dla silnika. Bez odpowiedniej inspekcji TLS zwykle pozostają jedynie cechy niezaszyfrowane lub widoczne w inny sposób.

Sprawdź wcześniej licencję i cykl życia

Do włączenia IPS potrzebna jest aktywna subskrypcja Network Protection lub ważna licencja próbna oraz dostęp administratora do sygnatur, polityk i reguł zapory. Przed pilotażem należy udokumentować bieżące przypisanie polityki, identyfikator reguły i kopię zapasową na potrzeby przywrócenia poprzedniego stanu. Wspomniane poniżej 30 dni liczy się od wygaśnięcia licencji lub ręcznego wyłączenia IPS, a nie dopiero od następnej próby konfiguracji.

Własnych sygnatur nie można konfigurować, jeśli wersja próbna IPS wygasła lub IPS Protection jest wyłączone w Intrusion prevention > IPS policies. Sophos zaleca ponowne włączenie IPS w ciągu 30 dni, jeśli istniejące niestandardowe sygnatury mają zostać zachowane. Dlatego przed zmianami licencji, IPS lub większymi zmianami polityk kopia zapasowa albo eksport powinny stanowić część planu przywrócenia poprzedniego stanu.

Następnie IPS musi być aktywne globalnie, a reguła zapory przetwarzająca ruch wymaga polityki IPS. Pełną konfigurację podstawową opisano w artykule Konfiguracja i bezpieczne testowanie IPS w Sophos Firewall. Niestandardowa sygnatura jest uzupełnieniem tej ścieżki danych, a nie równoległym mechanizmem ochrony.

Jasno określ zakres składni reguł

Ograniczenia dokumentacji dla SFOS 22/23: Pomoc dotycząca składni zawiera przykłady o niespójnym formatowaniu: distance: 4.within:4; nie jest wiarygodnym wzorcem do skopiowania; przy byte_jump opis wymienia operandy porównania, których nie ma w schemacie składni. Niejasne są również opisy zarezerwowanych bitów TCP. Tych fragmentów nie należy interpretować jako dodatkowych możliwości silnika. Omówione poniżej fragmenty pozostają przykładami z dokumentacji, a nie regułami przetestowanymi na zaporze. Jeśli reguła zostanie odrzucona lub wydaje się niejasna, należy zachować dokładny numer kompilacji, regułę i komunikat błędu oraz wyjaśnić sprawę z pomocą techniczną Sophos; do tego czasu nie należy dopuszczać akcji blokującej w środowisku produkcyjnym.

Formularz rozdziela Protocol i Custom rule. W regule łączy się poszczególne słowa kluczowe z ich wartościami i średnikiem. Im więcej niezależnych cech musi jednocześnie pasować, tym mniejsze jest zazwyczaj ryzyko przypadkowych trafień. Jednocześnie sygnatura nie może być tak szczegółowa, aby nieszkodliwa zmiana protokołu pozbawiła ją skuteczności.

Do wyłącznie kontrolowanego testu z tekstem jawnym można użyć protokołu TCP i na przykład następującego, precyzyjnie zawężonego wzorca zawartości:

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

AVANET-IPS-PILOT to celowo charakterystyczna wartość użyta w dokumentacji. Powiązana pilotażowa reguła zapory jest dodatkowo ograniczana 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 danych widocznym dla IPS. Ten przykład nie jest uniwersalną sygnaturą ataku i nie należy stosować go bez zmian w szerokich regułach produkcyjnych.

Zawartość pakietu i okno wyszukiwania

content wyszukuje ciąg znaków lub bajtów; wartości binarne zapisuje się między znakami pionowej kreski. nocase ignoruje wielkość liter przy dopasowaniu treści, a rawbytes działa na danych surowych. depth i offset ograniczają wyszukiwanie bezwzględnie w obrębie zawartości pakietu, natomiast distance i within działają względem poprzedniego trafienia. uricontent, isdataat i pcre obsługują bardziej szczegółowe wyrażenia dotyczące URI, pozycji i wyrażeń regularnych.

Wąski zakres wyszukiwania ogranicza przypadkowe trafienia i nakład obliczeniowy. Zwłaszcza pcre, duże okna lub kilka szerokich wzorców treści należy wdrażać wyłącznie przy użyciu realistycznych pakietów i z monitorowaniem obciążenia. Jeśli depth jest mniejsze niż wyszukiwany wzorzec treści, sygnatura nigdy nie wygeneruje trafienia.

Modyfikatory nocase, rawbytes, depth, offset, distance i within należą do content; nie są niezależnymi regułami wykrywania. Bez depth wyszukiwanie przebiega od offset do końca zawartości pakietu. Bez within również wyszukiwanie drugiego wzorca treści pozostaje otwarte od distance do końca. Dlatego sam punkt początkowy nie wystarcza do utrzymania wąskiego okna wyszukiwania. uricontent przeszukuje znormalizowane URI żądania, a nie dowolne dane użytkowe. isdataat sprawdza, czy na podanej pozycji znajdują się dane; z relative pozycja ta odnosi się do końca poprzedniego dopasowania treści.

Nagłówki, strumień 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 opisuje się za pomocą flags, flow, seq, ack i window; itype, icode, icmp_id i icmp_seq dotyczą ICMP. rpc, byte_test i byte_jump są przeznaczone do protokołów strukturalnych lub binarnych.

flow dotyczy wyłącznie TCP. to_server i from_client są przy tym równoważne, podobnie jak to_client i from_server. bi_direction rozszerza wykrywanie na oba kierunki; przy powiązaniu z portem test negatywny musi więc uwzględniać również ruch powrotny. Wyboru między no_stream a only_stream nie należy mylić z kontrolą rozmiaru pakietu: dsize sprawdza rozmiar zawartości pakietu i nie generuje trafień dla pakietów odtworzonych ze strumienia. Połączenie z only_stream jest zatem nieodpowiednie. Przy braku trafienia należy najpierw zdecydować, czy cecha ma być wyszukiwana w pojedynczym pakiecie, czy w odtworzonym strumieniu, zamiast zmieniać wyłącznie rozmiar lub wzorzec treści.

Dla złożonych reguł obowiązuje opisana powyżej składnia niestandardowych sygnatur IPS obsługiwana przez SFOS 22. Nie należy bez sprawdzenia stosować nieudokumentowanych słów kluczowych Snort ani reguł skopiowanych z innych silników.

Operandy: adres, port, URI i pozycja danych

Poniższe fragmenty należy wprowadzać w Custom rule, a nie w powłoce. Stanowią one materiał referencyjny dla SFOS 22/23, a nie gotowe, przetestowane sygnatury ataków. Łączy się wyłącznie warunki pasujące do danego przypadku wykrywania; Protocol, polityka pilotażowa i Allow packet pozostają częścią opisanego powyżej testu. Nawiasy kwadratowe we wzorcach składni oznaczają części opcjonalne i nie należy ich wpisywać.

• srcaddr:192.0.2.10; dstaddr:198.51.100.20; porównuje źródłowy i docelowy adres IP z pojedynczymi adresami. Adresy dokumentacyjne należy zastąpić zaobserwowanymi adresami testowymi; nie można z tego wywnioskować obsługi podsieci ani list adresów.

• srcport:40000; dstport:8080; porównuje port źródłowy i docelowy z liczbami. Port docelowy oznacza tutaj usługę testową. Zmienny port źródłowy klienta należy ustalać na sztywno tylko wtedy, gdy rzeczywiście stanowi część przypadku wykrywania; w przeciwnym razie nowe połączenia nie spełnią tego warunku.

• uricontent:"/ips-pilot"; wyszukuje ścieżkę, którą można zastąpić, w znormalizowanym URI żądania. Możliwe są też mieszane wzorce tekstowo-binarne. Porównanie musi odpowiadać znormalizowanej wartości URI, a nie jedynie zapisowi w pasku adresu przeglądarki.

• content:"AVANET-IPS-PILOT"; isdataat:50,relative; dodatkowo wymaga danych na pozycji 50 względem końca tego dopasowania treści. Bez relative pozycja w zawartości pakietu jest bezwzględna. Liczbę dobiera się według rzeczywistej struktury protokołu; sprawdza ona dostępność danych, a nie ich treść.

• content:"ABC"; content:"DEF"; distance:1; within:10; używa dwóch wzorców, które można zastąpić, ze względnym oknem wyszukiwania. distance określa odległość od końca pierwszego trafienia, a within ogranicza kolejne wyszukiwanie. Dla okien bezwzględnych offset i depth również otrzymują wartości liczbowe, na przykład offset:4; depth:20; przy powiązanym content. Liczby te dobiera się na podstawie rzeczywistego położenia i długości wzorca; nie są to domyślne wartości protokołu.

Wyrażenia regularne z pcre

Podstawowe postacie to pcre:"/REGEX/"; i pcre:"m/REGEX/";. Znak ! przed otwierającym cudzysłowem neguje wyrażenie, na przykład pcre:!"/AVANET-IPS-PILOT/i";. Jest to warunek braku dopasowania i bez dodatkowego zawężenia może działać bardzo szeroko. REGEX lub token pilotażowy należy zastąpić wymaganym wzorcem. Opcje umieszcza się po zamykającym /, na przykład pcre:"/AVANET-IPS-PILOT/i";.

• i ignoruje wielkość liter; s sprawia, że . obejmuje również znaki końca wiersza.
• m sprawia, że ^ i $ dopasowują również początki i końce wierszy w buforze. x ignoruje niechronione białe znaki we wzorcu, z wyjątkiem klas znaków.
• A zakotwicza dopasowanie na początku bufora. E wiąże $ wyłącznie z rzeczywistym końcem, a nie z pozycją przed końcowym znakiem końca wiersza.
• G odwraca domyślną zachłanność kwantyfikatorów; następujący po nich ? ponownie ją odwraca.
• R rozpoczyna wyszukiwanie względem końca ostatniego dopasowania wzorca. U używa zdekodowanych buforów URI, a B nie używa zdekodowanych buforów.

Dlatego przed pilotażem należy ustalić, w którym buforze i od jakiej pozycji wzorzec ma obowiązywać. Poprawne wyrażenie regularne działające na danych surowych nie musi generować trafienia w zdekodowanym URI.

Odczytywanie pól binarnych: byte_test i byte_jump

byte_test odczytuje pole i sprawdza jego wartość liczbową. Schemat ma postać byte_test:COUNT,[!]OPERATOR,VALUE,OFFSET[,relative][,big|little][,NUMBER_TYPE,string];. COUNT to liczba odczytywanych bajtów, a OFFSET to pozycja początkowa w zawartości pakietu; z relative początek jest określany względem ostatniego dopasowania wzorca. VALUE jest wartością porównania. Udokumentowane są <, >, =, ! i &: odpowiednio mniejsze, większe, równe, różne oraz bitowe AND. Znak ! przed operatorem porównania neguje jego wynik. big lub little określa kolejność bajtów. Z string odczytywane są cyfry tekstowe zamiast binarnego pola liczbowego; hex, dec i oct dotyczą wyłącznie tego trybu tekstowego.

Przykład pola binarnego: byte_test:2,=,16,0,big; odczytuje dwa bajty od pozycji 0 w zawartości pakietu w kolejności Big Endian i porównuje z 16. Liczba bajtów, pozycja, kolejność bajtów i wartość porównania muszą wynikać z protokołu, a nie z tego przykładu. Przypadkowa wartość liczbowa nie jest dowodem ataku.

byte_jump natomiast odczytuje długość i przesuwa pozycję dla kolejnych sprawdzeń. Schemat ma postać byte_jump:COUNT,OFFSET[,relative][,multiplier FACTOR][,big|little][,string][,hex|dec|oct][,align][,from_beginning];. Pierwsze dwa operandy określają szerokość pola i pozycję odczytu; relative odnosi przesunięcie do ostatniego dopasowania wzorca. multiplier mnoży odczytaną wartość w celu wyznaczenia długości skoku. align zaokrągla ją w górę do następnej granicy 32-bitowej. Z from_beginning długość skoku jest stosowana od początku zawartości pakietu zamiast od bieżącej pozycji. string i podstawy systemów liczbowych pełnią tę samą funkcję co w byte_test.

byte_jump:2,0,big; jest więc fragmentem dla dwubajtowego pola długości na początku zawartości pakietu z jawnie wybraną kolejnością bajtów. Nie jest to porównanie rozmiaru; operator porównania i wartość porównania nie są operandami byte_jump. Dla obu słów kluczowych dotyczących bajtów należy jawnie wybrać big lub little w przypadku binarnych pól wielobajtowych: nie należy polegać na domyślnej kolejności bajtów wywnioskowanej z dokumentacji. Najpierw należy prześledzić pole i cel skoku w rzeczywistej zawartości testowej, a następnie sprawdzić przypadek pozytywny i negatywny dla kolejnego warunku. Nieprawidłowa długość może przesunąć pozycję wyszukiwania poza pożądany wzorzec.

Pola IP, opcje i fragmenty

• ttl:64;, ttl:>64; i ttl:<64; porównują IP Time to Live dokładnie albo sprawdzają, czy wartość jest większa lub mniejsza. tos:16; porównuje pole TOS, a id:1234; pole IP-ID. Te przykładowe liczby nie są zalecanymi wartościami wykrywania; dobiera się je na podstawie faktycznie poszukiwanej cechy nagłówka.
• ipopts:rr; sprawdza obecność opcji IP. Dozwolone wartości to rr (Record Route), eol (End of List), nop (No Operation), ts (Timestamp), sec (Security), lsrr (Loose Source Routing), ssrr (Strict Source Routing), satid (Stream Identifier) i any (dowolna opcja IP). any wymaga więc obecności opcji, a nie po prostu dowolnego pakietu IP.
• fragoffset:0; porównuje przesunięcie fragmentu w nagłówku IP z liczbą dziesiętną. To pole nie jest przesunięciem wyszukiwania treści w zawartości pakietu.
• fragbits sprawdza M (More Fragments), D (Don’t Fragment) i R (Reserved). Poprzedzający znak + dopuszcza inne bity oprócz podanych, * wymaga co najmniej jednego z podanych bitów, a ! wymaga, aby podane bity nie były ustawione. W ten sposób fragbits:+M; sprawdza ustawienie More Fragments bez wykluczania innych bitów.
• dsize:300;, dsize:>300;, dsize:<300; i dsize:300<>400; opisują dokładny rozmiar zawartości pakietu, porównanie z większą lub mniejszą wartością albo zakres. Liczby odnoszą się do danych użytkowych pakietu, a nie do całego połączenia. Nadal obowiązują opisane powyżej ograniczenia dotyczące odtworzonych strumieni.
• ip_proto:6;, ip_proto:!6;, ip_proto:>6; i ip_proto:<6; porównują liczbowy identyfikator protokołu w nagłówku IP, a nie port TCP/UDP. samip; nie ma wartości i wymaga identycznego źródłowego i docelowego adresu IP.

Pola TCP i wybór strumienia

flags sprawdza flagi TCP: S oznacza SYN, A ACK, F FIN, R RST, U URG, a P PSH. Bez modyfikatora na przykład flags:S; sprawdza, czy ustawiona jest dokładnie flaga SYN. Poprzedzający znak +, * lub ! ma znaczenie wyjaśnione powyżej przy fragbits. flags:+S; dopuszcza zatem dodatkowe flagi. Pomoc pokazuje opcjonalną drugą grupę flag po przecinku, ale nie wyjaśnia jej semantyki porównania. Dlatego flags:S,A; nie należy traktować jako potwierdzonego polecenia ignorowania ACK; przed użyciem należy wyjaśnić to zachowanie dla zainstalowanej kompilacji. Szczególne przypadki dotyczące zarezerwowanych bitów TCP i „braku ustawionych flag” celowo nie zostały tutaj dopuszczone jako składnia do skopiowania; wymagają reguły potwierdzonej dla danej wersji i nie wolno ich wywodzić z niejasnego opisu.

Dla flow dostępne są już omówione kierunki oraz established, no_stream i only_stream. flow:established; wymaga ustanowionego połączenia TCP. flow:no_stream; wyklucza pakiety odtworzone ze strumienia, a flow:only_stream; ogranicza wykrywanie do takich pakietów. Te fragmenty objaśniają poszczególne wybory i nie są zachętą do jednoczesnego stosowania obu opcji strumienia. bi_direction pozostaje opisanym powyżej rozszerzeniem na ruch w obu kierunkach.

seq:1234;, ack:1234; i window:4096; porównują odpowiednio numer sekwencyjny TCP, numer potwierdzenia i rozmiar okna z liczbą. Dokładne wartości numeru sekwencyjnego lub ACK zmieniają się między połączeniami i mają sens tylko wtedy, gdy właśnie ta wartość stanowi część przypadku wykrywania. Okno TCP nie jest oknem wyszukiwania w zawartości pakietu.

ICMP i RPC

itype:8; i icode:0; porównują typ i kod ICMP. Oba obsługują również <, > i zakresy takie jak itype:3<>5;; typ i kod to różne pola. icmp_id:1234; i icmp_seq:1; dokładnie porównują identyfikator ICMP i wartość sekwencji. Wartości dobiera się na podstawie pożądanego przypadku ICMP i nie należy utożsamiać ich z numerami sekwencyjnymi TCP.

rpc:100000,2,*; sprawdza w żądaniach SUNRPC-CALL numer aplikacji 100000, wersję 2 i dowolną procedurę. Schemat to rpc:APPLICATION,VERSION,PROCEDURE;; * jest dozwolone dla wersji i procedury, ale nie dla numeru aplikacji. Liczby należy zastąpić poszukiwaną aplikacją, wersją i procedurą. Symbol wieloznaczny nie zwalnia z analizy protokołu: celowo pozostawia dany element nieokreślony i w ten sposób rozszerza wykrywanie.

Utwórz sygnaturę i przypisz ją do polityki

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 uwidacznia cel i zakres testu. Severity opisuje własną ocenę ryzyka; nie dowodzi, że wzorzec jest złośliwy.

Przy pierwszym uruchomieniu Recommended action pozostaje ustawione na Allow packet. Ważne: akcja reguły polityki IPS zastępuje to zalecenie. Dlatego również reguła pilotażowa musi używać Allow packet. Pozostałe akcje mają znacznie poważniejsze 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 sprawdza dalej pozostałej części sesji.

W przypadku akcji opartych na sesji SFOS sprawdza tylko do pierwszego pasującego pakietu. Przed przejściem z Allow packet na taką akcję trzeba więc potwierdzić, że właśnie to pierwsze trafienie dotyczy zamierzonej sesji.

Podczas zapisywania SFOS ponownie konfiguruje silnik IPS. Jeśli dostępna jest wystarczająca ilość wolnej pamięci RAM, odbywa się to bez przerwy. Przy małej ilości wolnej pamięci RAM silnik może uruchomić się ponownie i spowodować krótkotrwałą przerwę. Dlatego nawet zmiany pozornie niewielkiej sygnatury należy wykonywać w monitorowanym oknie czasowym. Po zapisaniu należy sprawdzić stan IPS i ips.log pod kątem ponownego uruchomienia lub błędów, zanim pilotaż będzie kontynuowany.

Po tej wstępnej kontroli zapisz sygnaturę za pomocą Save i ponownie otwórz jej wpis: Protocol, Custom rule, Severity i Recommended action muszą odpowiadać zaplanowanym wartościom. Podczas pilotażu pozostaw Firewall Acceleration i PKI Acceleration bez zmian; każde włączenie lub wyłączenie powoduje ponowne uruchomienie IPS i zaburza porównanie. Kontrola stref, Trusted MAC, pary IP-MAC i wyjątki DoS to osobne mechanizmy opisane w artykule Ochrona przed DoS i spoofingiem, a nie właściwości niestandardowej sygnatury.

Następnie należy wykonać często pomijany drugi etap: w Intrusion prevention > IPS policies otwórz politykę przeznaczoną do pilotażu, którą można usunąć, dodaj regułę, wybierz Custom signature, zaznacz sygnaturę i umieść szczegółową regułę nad regułami o szerszym zakresie. SFOS ocenia reguły polityki IPS od góry do dołu. Zapisz regułę polityki za pomocą Save, a następnie zapisz również całą politykę IPS za pomocą Save. Ponownie otwórz politykę i sprawdź zapisany wybór sygnatury oraz akcję. Następnie przypisz tę politykę w Rules and policies > Firewall rules > [reguła pilotażowa] > Detect and prevent exploits (IPS) do pilotażowej reguły, która faktycznie obsługuje ruch; zapisz także regułę zapory i sprawdź ją przy użyciu nowej sesji.

Zarządzanie tym samym obiektem sygnatury przez XML API

Automatyzacja pilotażu operuje na obiekcie XML IPSCustomSignature, a nie na regule polityki IPS. Dokumentacja referencyjna SFOS 22/23 określa operacje jako Add Custom Signature, Update custom signature i Delete Custom Signature. Dostęp, jawną operację zapisu, kopię zapasową, ocenę odpowiedzi i zatrzymanie przy niewyjaśnionej zawartości żądania omówiono centralnie w artykule Bezpieczne korzystanie z XML API. Przed zapisem trzeba potwierdzić definicję obiektu i operację w API help zainstalowanej kompilacji; nie podano tutaj dodatkowego, wykonywalnego żądania zapisu.

W przykładzie obiektu Name, Protocol, CustomRule, Severity i RecommendedAction znajdują się wewnątrz IPSCustomSignature. Name oznacza sygnaturę, a nie politykę lub regułę zapory. Tabela parametrów wymaga w tym miejscu skalarnego ciągu znaków o długości najwyżej 15 znaków; również Delete wymaga tej dokładnej nazwy. Dlatego do automatyzacji API należy wybrać krótką, jednoznaczną nazwę, taką jak IPS-PILOT-8080. Dłuższa przykładowa nazwa dla WebAdmin podana powyżej nie jest wzorcem do skopiowania do API. Przed Update lub Delete należy odczytać faktycznie zapisaną tożsamość i wszystkie użycia w politykach, zamiast wnioskować o obiekcie docelowym na podstawie SID lub wpisu o podobnej nazwie.

Tabela oznacza każdą z pięciu pozycji dla Add/Update jako obowiązkową i skalarną. Protocol dopuszcza TCP, UDP, ICMP lub ALL; Severity dopuszcza Critical, Major, Moderate, Minor lub Warning. CustomRule zawiera definicję sygnatury jako ciąg znaków. Etykieta tabeli Custom Rule ze spacją nie jest zapisem XML CustomRule. Dodatkowa wskazówka o rozdzielaniu liter kropką nie wyjaśnia ani ogólnej konwersji reguł, ani stosowania znaków ucieczki w XML. Dlatego nie należy mechanicznie zmieniać opisanej powyżej składni przez dodawanie kropek, lecz sprawdzić treść reguły i poprawne kodowanie XML dla danej kompilacji. Przykład producenta używa jedynie SignatureDefinition jako symbolu zastępczego; nie tworzy to gotowej do użycia sygnatury ani sygnatury o potwierdzonej zdolności wykrywania złośliwego ruchu.

Nie myl zalecenia z akcją: Przykład XML używa zapisu RecommendedAction, natomiast tabela parametrów nazywa ten sam obszar Action. Jako wartości tekstowe wymienia Allow Packet, Drop Packet, Drop Session, Reset i Bypass Session, a dodatkowo 3. Nie jest to potwierdzone dopuszczenie zastąpienia RecommendedAction tagiem XML Action. Dla 3 nie wyjaśniono znaczenia ani przypisania do akcji tekstowej; nie należy zgadywać tej wartości ani używać jej jako skrótu dla określonej akcji. Należy odczytać faktycznie zapisane zalecenie i nadal osobno sprawdzać akcję reguły polityki IPS. Utworzony obiekt API nie zastępuje ani przypisania polityki, ani testu pozytywnego i negatywnego.

Porównuj odpowiedzi API z operacją i zapisanym stanem

Poniższe wiersze są udokumentowane w dokumentacji referencyjnej obiektów SFOS 22/23. Nazwy Message.* pozostają nierozstrzygniętymi symbolami dokumentacyjnymi: nie są ani gwarantowanymi komunikatami w czasie działania, ani przetłumaczonymi tekstami błędów, ani ostatecznie potwierdzonymi przyczynami. Również liczby są kodami statusu XML, a nie kodami statusu HTTP. Należy zachować razem operację, kod i rzeczywistą odpowiedź; wierszy specyficznych dla obiektu nie należy zastępować ogólną interpretacją kodu z centralnego artykułu o API.

Dla Add Custom Signature dokumentacja referencyjna wymienia:

• 200 — Message.CustomSigAddSuccess
• 500 — Message.CustomSigAddFailed
• 502 — Message.CustomSigRecordExists
• 504 — Message.CustomSigInvalidSignatureRule
• 505 — Message.IPSpolicyEngineRestartFail
• 506 — Message.CustomSignatureIpsOff

Dla Update custom signature wymienia:

• 200 — Message.CustomSigUpdateSuccess
• 500 — Message.CustomSigUpdateFailed
• 502 — Message.CustomSigRecordExists
• 504 — Message.CustomSigCustomSignatureCheck1
• 505 — Message.IPSpolicyEngineRestartFail
• 506 — Message.CustomSignatureIpsOff

Właśnie przy 504 symbol odróżnia Add od Update; Message.CustomSigCustomSignatureCheck1 nie należy reinterpretować jako rzekomo jednoznacznego komunikatu o błędzie składni. Przed ponownym Add/Update należy ponownie otworzyć wpis w WebAdmin lub sprawdzić go za pomocą zapytania odczytu potwierdzonego dla danej kompilacji: czy Name, Protocol, Custom rule, Severity i Recommended action odpowiadają pożądanemu stanowi? Przy 502 należy porównać istniejącą i pożądaną tożsamość, a nie automatycznie nadpisywać obiektu lub tworzyć go pod drugą nazwą. Przy 504 należy dodatkowo porównać dokładną regułę z dokumentacją kompilacji. Przy 505 należy wspólnie sprawdzić zapisany stan, stan IPS i ips.log; z symbolu nie wynika ani pewne przywrócenie poprzedniego stanu, ani zgoda na ponowne uruchomienie silnika. Przy 506 należy skontrolować stan IPS i licencji zgodnie z sekcją dotyczącą cyklu życia, ale nie przełączać IPS na próbę. Również po 200 trzeba sprawdzić zapisane wartości, powiązanie z polityką i ścieżkę danych; 500 nie dowodzi, że nie nastąpiła żadna częściowa zmiana.

Dla Delete Custom Signature udokumentowano następujące odrębne wiersze:

• 200 — Message.CustomSigDeleteSuccess
• 500 — Message.CustomSigDeleteFailed
• 503 — Message.CustomSignatureInUse
• 506 — Message.CustomSignatureIpsOff

Delete należy dopuścić dopiero po opisanym poniżej przywróceniu poprzedniego stanu i pełnej kontroli użycia. Przy 503 należy zbadać odwołania polityk do rzeczywistego obiektu, a nie usuwać w całości polityki produkcyjnej. Przy 506 należy wyjaśnić stan IPS i licencji, zamiast globalnie wyłączać IPS na potrzeby próby usunięcia. Po odpowiedzi należy odczytać i potwierdzić brak dokładnej nazwy oraz oczekiwany stan zależnych polityk; przy 500 lub niejasnej odpowiedzi nie należy ponawiać usuwania w ciemno. Jeśli zapisany stan, odpowiedź lub zakres odpowiedzialności pozostają niejasne, należy zatrzymać automatyzację i wyjaśnić z pomocą techniczną Sophos zanonimizowaną odpowiedź, wersję reguły, kompilację i logi. Nie twierdzi się tutaj, że jakiekolwiek zachowanie w czasie działania zostało przetestowane na zaporze.

Przeprowadź test pozytywny i negatywny

Test pozytywny wysyła uzgodniony wzorzec przez przewidziany port i w oczekiwanym kierunku. W Log Viewer, w prawym górnym rogu WebAdmin, należy wybrać moduł IPS i filtrować według czasu testu, Source i Destination. Sygnatura lub SID, akcja i czas muszą odpowiadać testowi. ips.log dostarcza dodatkowych szczegółów dotyczących silnika. Packet Capture w Diagnostics > Packet capture pokazuje dodatkowo Firewall Rule ID i IPS Policy ID. Powiązanie między regułą, Packet Capture i modułem bezpieczeństwa wyjaśnia artykuł Systematyczne testowanie reguły zapory.

Po fazie pilotażowej skuteczność można dodatkowo ocenić w Reports > Network & threats > Intrusion attacks. Raport jest przydatny do porównywania okresów, ale nie zastępuje przeprowadzanego na bieżąco testu pozytywnego i negatywnego w Log Viewer. XGS 87/87w i XGS 88/88w nie obsługują raportowania lokalnego na urządzeniu; na tych modelach należy wykonywać opisane bieżące kontrole w Log Viewer.

Następnie należy wykonać co najmniej jeden test negatywny: ta sama usługa bez tokenu, inny port lub inny kierunek. Sygnatura nie może przy tym generować trafienia. Przy wzorcu treści ważne są również zwykłe żądania aplikacji, ponieważ krótkie lub ogólne ciągi mogą występować w całkowicie legalnej zawartości pakietów.

Dopiero gdy oba testy dają stabilne wyniki, należy ustawić planowaną akcję blokującą i ponownie ją sprawdzić. Sygnaturę blokującą można uznać za odebraną tylko wtedy, gdy zatrzymywany jest dokładnie przypadek pozytywny, przypadek negatywny nadal działa, a efektu nie powoduje inna reguła zapory lub IPS.

Sprawdź liczbę sygnatur

Liczbę można ustalić w WebAdmin bez użycia powłoki. W Intrusion prevention > IPS policies należy otworzyć politykę, którą można usunąć, i utworzyć nową regułę polityki. Po użyciu Select all SFOS pokazuje łączną liczbę nad Action. Lista jest widoczna tylko podczas dodawania reguły do polityki, którą można usunąć; okno dialogowe można następnie zamknąć bez zapisywania.

Sophos dokumentuje dodatkowo dwa zapytania odczytu w 5. Device management > 3. 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 zlicza sygnatury standardowe, a drugie niestandardowe. Te zapytania do bazy danych niczego nie zmieniają, ale powinny być wykonywane w ramach udokumentowanej sesji wsparcia lub diagnostyki. Liczba nie jest dowodem jakości ani poprawnego działania i może zmieniać się wraz z aktualizacjami wzorców.

Dla każdego zapytania oczekiwany jest pojedynczy wiersz wyniku pod count, po którym następuje (1 row). Przykładowe wartości Sophos 28623 i 1 pochodzą z przykładu dla SFOS 19.0.1 i nie są wartościami docelowymi dla SFOS 22/23. W przypadku błędów bazy danych, połączenia lub uprawnień nie należy zmieniać tabel ani usług: należy skorzystać z kontroli w WebAdmin i zachować dokładny wynik oraz numer kompilacji dla pomocy technicznej.

Gdy sygnatura nie działa zgodnie z oczekiwaniami

Brak trafienia

Najpierw należy sprawdzić, czy IPS jest aktywne, czy ruch trafia do oczekiwanej reguły zapory z właściwą polityką IPS i czy niestandardowa sygnatura rzeczywiście znajduje się w ocenianej regule polityki. Następnie sprawdza się protokół, kierunek, port, szyfrowanie i rzeczywistą zawartość pakietu. Ciąg widoczny w przeglądarce nie musi występować bez zmian w pakiecie sieciowym.

Pomocne jest przechwytywanie pakietów z precyzyjnym filtrem, pokazujące kierunek, port i treść widoczną w danym punkcie przechwytywania. Brak wzorca tekstu jawnego w zaszyfrowanym przechwyceniu nie dowodzi jednak, że nie ma go w odszyfrowanym buforze IPS. Dlatego punkt przechwytywania, odszyfrowywanie i rekonstrukcję strumienia należy sprawdzać łącznie. W kontrolowanym teście z tekstem jawnym musi być możliwe prześledzenie faktycznie przesłanego wzorca; następnie sprawdza się offset, depth, distance, within, stan strumienia i kolejność reguł polityki.

Zbyt wiele połączeń generuje trafienia

Sygnatura pozostaje ustawiona na Allow packet, dopóki Source, Destination, port, kierunek lub okno wyszukiwania nie zostaną zawężone. Typowymi przyczynami są ogólne słowa, krótkie ciągi binarne i nieograniczone wyrażenia regularne. Szeroka reguła zapory dodatkowo utrudnia kontrolę skutków.

Jeśli po zapisaniu zapora wykazuje wzrost wykorzystania zasobów lub ponowne uruchomienie IPS, należy zachować czas zdarzenia, model, firmware, informacje o wolnych zasobach i ips.log. Wielokrotne zapisywanie różnych wariantów nie jest wtedy prawidłowym testem; najpierw należy wyjaśnić przyczynę i ustalić okno serwisowe.

Bezpieczne przywrócenie poprzedniego stanu

W przypadku nieoczekiwanych trafień należy najpierw usunąć niestandardową regułę z polityki pilotażowej lub przywrócić poprzednią politykę IPS w regule zapory. Następnie należy sprawdzić nowe sesje za pomocą testu pozytywnego i negatywnego. Niestandardową sygnaturę usuwa się dopiero wtedy, gdy nie ma ona żadnego innego zastosowania.

Przed usunięciem należy udokumentować, która polityka, reguła zapory i aplikacja korzystały z sygnatury. Logi, przetestowana wersja reguły i powód przywrócenia poprzedniego stanu powinny znaleźć się w dokumentacji zmiany. Globalne wyłączenie IPS lub usunięcie całej polityki produkcyjnej nie jest odpowiednim sposobem wycofania pojedynczej błędnej sygnatury.

FAQ