Konfiguracja i bezpieczne testowanie IPS na Sophos Firewall
Intrusion Prevention System (IPS) sprawdza ruch pod kątem znanych wzorców ataków, exploitów i nietypowych cech protokołów. Aby IPS rzeczywiście chronił, musi być włączony globalnie, a do reguły zapory obsługującej ruch musi być przypisana odpowiednia polityka IPS.
Nie należy bez wyjątku stosować najbardziej restrykcyjnej polityki IPS we wszystkich regułach. Polityka dopasowana do ścieżki danych, wdrożenie pilotażowe i kompletne logi zapobiegają niepotrzebnym awariom bez pochopnego ograniczania ochrony.
Włączanie IPS i przypisywanie go do reguły zapory
Wymagania
Przed rozpoczęciem konfiguracji należy spełnić następujące warunki:
- aktywna subskrypcja Network Protection lub licencja próbna
- dostępne sygnatury IPS i działające aktualizacje wzorców
- znana reguła zapory, która rzeczywiście obsługuje sprawdzany ruch
- włączone logowanie reguły i procedura obsługi fałszywych alarmów
IPS Protection jest domyślnie wyłączony. Na zaporze z dostępem do Internetu sygnatury IPS są aktualizowane tylko przy ważnej licencji i włączonym IPS. Udokumentowany wyjątek stanowią licencjonowane zapory Air Gap: mogą one otrzymywać sygnatury IPS w przewidzianym procesie aktualizacji również przy wyłączonym IPS. Szczegóły opisano w artykule Licencjonowanie Air Gap i aktualizacje wzorców.
Po wygaśnięciu Network Protection przełącznik IPS może nadal wyglądać na aktywny, mimo że zapora nie wymusza już ochrony IPS. Po ręcznym wyłączeniu IPS sygnatury online nie są aktualizowane, a polityk i własnych sygnatur nie można już konfigurować. Po 30 dniach zapora usuwa sygnatury i reguły IPS.
Po wygaśnięciu licencji próbnej IPS wyłącza się automatycznie. Przez kolejne 30 dni nie wymusza ochrony, nie pobiera sygnatur i nie pozwala konfigurować polityk; następnie sygnatury i reguły są usuwane. Aby zachować konfigurację, trzeba ją wcześniej wyeksportować lub utworzyć kopię zapasową.
Globalne włączanie IPS
- Otwórz Protect > Intrusion prevention > IPS policies. W zależności od widoku ścieżka może być skrócona do Intrusion prevention > IPS policies.
- Włącz IPS Protection.
- Sprawdź stan licencji i aktualizacje wzorców.
- Poczekaj, aż sygnatury będą dostępne.
- Sprawdź istniejące polityki domyślne.
- Jeśli potrzebna jest własna polityka, sklonuj odpowiednią politykę domyślną za pomocą Add.
Po włączeniu nie należy sprawdzać wyłącznie stanu przełącznika. Aktualny stan wzorców i pierwsze zdarzenie w logu znacznie lepiej pokazują, czy cały łańcuch ochrony faktycznie działa.
Włączenie lub wyłączenie Firewall Acceleration albo PKI Acceleration powoduje ponowne uruchomienie IPS lub DPI Engine. Takie zmiany należy wykonywać w oknie serwisowym, a nie w trakcie bieżącej analizy błędu.
Włączanie IPS w regule zapory
- Otwórz Rules and policies > Firewall rules.
- Edytuj regułę, która rzeczywiście pasuje do ruchu.
- W sekcji Other security features włącz opcję Detect and prevent exploits (IPS).
- Wybierz politykę IPS odpowiednią do ruchu.
- Włącz logowanie reguły, zapisz zmiany i przeprowadź test z rzeczywistym ruchem.
Samo włączenie globalne nie wystarcza. Jeśli ruch najpierw trafi do innej reguły bez polityki IPS, późniejsza reguła nie zapewni ochrony. W takim przypadku pomoże artykuł Reguła Sophos Firewall nie pasuje: sprawdzanie przyczyn.
W przypadku publikowanych serwerów oznacza to, że DNAT, ściśle ograniczona reguła zapory, polityka IPS, logowanie i zarządzanie poprawkami muszą być ze sobą spójne. W segmentach wewnętrznych trzeba również sprawdzić, czy ruch w ogóle przechodzi przez zaporę i oczekiwaną regułę.
Wybór odpowiedniej polityki IPS
Politykę dobiera się do źródła, celu i aplikacji:
- Klienci do Internetu: zastosuj politykę dla klientów lub LAN-to-WAN i uzgodnij ją z Web Protection, Application Control oraz, w razie potrzeby, TLS Inspection. W pilotażu należy uwzględnić przeglądarki, usługi aktualizacji i aplikacje branżowe; w przypadku podejrzanych plików do pobrania Zero-Day Protection uzupełnia kontrolę sygnatur.
- Internet do serwera przez DNAT: politykę dla serwera lub serwera WWW należy ściśle dopasować do systemu docelowego i opublikowanych portów. Ochrona dotyczy faktycznie oferowanych usług, a nie każdej technologii serwerowej. Kontekst NAT i reguł opisano w artykule Publikowanie serwera przez DNAT; znane złośliwe adresy IP, domeny lub adresy URL można dodatkowo blokować za pomocą Threat Feeds.
- Site-to-Site VPN lub Remote Access VPN: wybierz politykę na podstawie systemu źródłowego i docelowego. Aplikacje produkcyjne, MTU/MSS, opóźnienie i przepustowość trzeba testować na rzeczywistej trasie VPN.
- VoIP: testuj SIP/RTP z odpowiednią polityką i planem wycofania zmian. Agresywna polityka klienta lub serwera może zakłócać sygnalizację albo przepływ multimediów.
- Sieci zarządzania, kopii zapasowych i infrastruktury: chroń je restrykcyjnie, nie przerywając wymaganych połączeń administracyjnych, monitorujących ani połączeń kopii zapasowych. Ściśle zdefiniowane reguły są tutaj zwykle cenniejsze niż wyjątkowo szeroki wybór sygnatur.
Na granicach segmentów, takich jak klient–serwer lub VPN–serwer, IPS utrudnia również ruch boczny po przejęciu systemu. Stanowi jednak tylko uzupełnienie prawidłowych reguł zapory. Za proste wzorce spoofingu i zalewania odpowiadają osobne ustawienia ochrony przed spoofingiem i DoS.
Tworzenie własnej polityki na podstawie szablonu
Za pomocą Add można sklonować politykę domyślną, a następnie precyzyjnie ją dostosować. Jest to bardziej przejrzyste niż swobodny zestaw sygnatur i zachowuje rozsądny poziom ochrony podstawowej. Nazwa powinna wskazywać przeznaczenie i ścieżkę danych, na przykład IPS-Pilot-LAN lub IPS-DNAT-Webserver.
Reguły polityki są przetwarzane od góry do dołu. Szeroka reguła obejmująca wszystkie sygnatury serwerowe może więc przesłonić znajdującą się niżej regułę specjalną dla pojedynczego SID. Konkretne dostosowania należy umieszczać nad bardziej ogólnymi regułami; następnie odpowiednie zdarzenie w logu musi potwierdzić zastosowanie oczekiwanej akcji.
Filtrowanie i ocena sygnatur
Sygnatury można filtrować według Category, Severity, Platform i Target. Można też tworzyć własne sygnatury IPS, ale powinny one służyć wyłącznie do jasno opisanego przypadku wykrycia i podlegać późniejszemu przeglądowi. W logach, zgłoszeniach i wyjątkach kluczowe są następujące informacje:
- SID: unikalny identyfikator sygnatury
- Category: obszar techniczny, na przykład DNS, przeglądarka lub złośliwe oprogramowanie
- Severity: poziom ważności
- Platform: platforma, której dotyczy sygnatura, na przykład Windows lub Linux
- Target: sygnatura klienta lub serwera
- Recommended action: działanie zalecane przez Sophos
Sophos przypisuje Critical do CVSS od 9 do 10, Major od 7 do poniżej 9, Moderate od 4 do poniżej 7, a Minor od 1 do poniżej 4 lub do sygnatur nadrzędnych. Warning oznacza alarm dotyczący nietypowego ruchu. Sam poziom ważności nie przesądza jednak o ocenie: sygnaturę Major na wystawionym serwerze ocenia się inaczej niż trafienie Warning w sieci testowej. System docelowy, dostępność z sieci, stan poprawek i faktycznie wykonana akcja zawsze muszą stanowić część oceny.
Działania IPS
Reguła polityki może zastąpić działanie zalecane przez Sophos:
- Recommended: rozsądny punkt wyjścia dla reguł produkcyjnych; stosowane jest odpowiednie zalecenie Sophos
- Allow packet: rejestruje trafienie, ale zezwala na pakiet; nadaje się do pilotażu, lecz nie zapobiega wykrytemu atakowi
- Drop packet: odrzuca tylko pakiet, którego dotyczy zdarzenie; aplikacja może działać dalej albo zwracać błędy
- Drop session: kończy całą sesję po trafieniu; silniejsza reakcja na potwierdzone ryzyko ataku
- Reset: aktywnie resetuje sesję TCP; użytkownik lub aplikacja widzi nagłe przerwanie
- Disable: wyłącza sygnaturę; ochrona przed dokładnie tym typem wykrycia przestaje działać
- Bypass session: pomija kontrolę pozostałej części sesji; ruch może przy tym trafić do FastPath lub Offload i zostać wyłączony z kontroli w większym zakresie, niż zamierzano
Działania dotyczące pakietów są stosowane do pojedynczych pakietów. Działania dotyczące sesji kontrolują ruch do pierwszego trafienia, a następnie obejmują całe połączenie. Każde odstępstwo od Recommended wymaga więc notatki zawierającej sygnaturę, politykę, regułę zapory, przyczynę, właściciela i datę przeglądu.
Wzorce PQC od SFOS 22.0 MR2
SFOS 22.0 MR2 wykrywa czyste i hybrydowe negocjacje ML-KEM, w tym ML-KEM-512, -768, -1024 oraz X25519 z ML-KEM-768. Nowe wzorce PQC są domyślnie ustawione na Disabled, ponieważ PQC nie jest automatycznie podejrzany. Aby je analizować, należy najpierw przetestować własną politykę pilotażową z działaniem Allow packet i logowaniem, a dopiero po analizie zastosować Drop session lub Reset. Więcej informacji zawiera artykuł Sophos Firewall v22 MR2: kontrola PQC.
Kontrolowane wdrażanie i testowanie
- Wybierz regułę pilotażową: zacznij od znanej testowej sieci klientów lub pojedynczej reguły DNAT. Oczekiwany ruch i osoba odpowiedzialna muszą być znane przed rozpoczęciem testu.
- Testuj rzeczywiste aplikacje: sprawdź logowanie, przesyłanie plików, aktualizacje, API i długotrwałe sesje. Krótki test ping nie dowodzi stabilnego działania aplikacji z włączonym IPS.
- Analizuj trafienia: w
Log viewersprawdź źródło, cel, usługę, regułę zapory, sygnaturę, SID, Severity, działanie i czas. Poniższe narzędzia dostarczają kontekstu technicznego. - Rozszerzaj etapami: kolejne reguły obejmuj dopiero po stabilnych testach. VoIP, ERP, protokoły przemysłowe, VPN i starsze aplikacje wymagają okna testowego i planu wycofania zmian.
W analizie pomagają Usługi i logi, wspólne użycie Log Viewer i Packet Capture oraz analiza odrzuconych pakietów.
Narzędzia odpowiadają na różne pytania:
ips.log: bardziej szczegółowe informacje o decyzjach IPS, DPI i Application Control- Packet Capture: przepływ i kierunek pakietów, Firewall Rule ID, NAT ID oraz IPS Policy ID
- Test reguły: która reguła zapory faktycznie obsługuje ruch
- Syslog lub Central Reporting: dłuższe przechowywanie i korelacja
Jeśli aktywnych jest kilka modułów ochrony, trzeba porównać czas zdarzeń w logach zapory, IPS, Web, Application Control i SSL/TLS Inspection. Reguła zapory może zezwalać na ruch, który następnie zostanie zablokowany przez kolejny moduł.
Porównywanie wydajności
W zależności od modelu, ruchu, sygnatur, TLS Inspection, Application Control, VPN i rozmiaru pakietów IPS zużywa różną ilość zasobów. Dlatego przed włączeniem i po włączeniu należy zarejestrować następujące wartości przy porównywalnym obciążeniu:
- obciążenie procesora i pamięci
- przepustowość na interfejsach, których dotyczy zmiana
- opóźnienia i retransmisje w krytycznych aplikacjach
- wolumen IPS/DPI oraz Syslog
- komunikaty użytkowników i aplikacji
Krótkie wyłączenie IPS nie dowodzi jeszcze przyczyny. Powtarzalne porównania można przeprowadzić dzięki prawidłowo interpretowanym metrykom wydajności zapory i kontrolowanemu testowi iPerf.
Obsługa fałszywych alarmów i wyjątków
Jeśli prawidłowy ruch jest blokowany, nie wolno odruchowo wyłączać IPS globalnie. Trafienie może być fałszywym alarmem, nieoczekiwaną aplikacją albo rzeczywistą próbą wykorzystania luki. Najpierw należy zebrać:
- identyfikator i nazwę sygnatury
- źródło, cel, usługę i pasującą regułę zapory
- czas, częstotliwość i aplikację, której dotyczy problem
- stan poprawek systemu docelowego
- odpowiedni fragment logu lub Packet Capture
Pomocne są konkretne pytania: czy błąd występuje tylko dla jednego hosta lub portu? Czy można go odtworzyć? Czy znika po zainstalowaniu poprawki? Czy ten sam SID wielokrotnie wskazuje ten sam cel? Dopiero te fakty uzasadniają zmianę polityki.
Następnie należy możliwie ściśle ograniczyć zmianę:
- dostosuj pojedynczą sygnaturę zamiast całej kategorii
- zastosuj własną politykę IPS tylko w regule zapory, której dotyczy problem
- sprawdź kolejność reguł polityki
- ściślej ogranicz źródło, cel i usługę w regule zapory
- udokumentuj przyczynę, właściciela i datę przeglądu
- po zmianie sprawdź, czy obejmuje ona wyłącznie oczekiwany ruch
Tymczasowy wyjątek jest zwykle lepszy niż trwałe wyłączenie. Po aktualizacji aplikacji, firmware lub systemu trzeba go ponownie sprawdzić. Jeśli wiele sygnatur zakłóca działanie tej samej aplikacji, własna polityka lub lepsza segmentacja stanowi właściwsze rozwiązanie niż duży wyjątek globalny.
Rozwiązywanie problemów i eksploatacja
IPS nie działa
Sprawdź w następującej kolejności:
- Czy subskrypcja Network Protection lub licencja próbna jest ważna?
- Czy IPS Protection jest włączony globalnie?
- Czy wzorce IPS są aktualne? W klastrze HA są aktualizowane na urządzeniu Primary i automatycznie synchronizowane z Auxiliary.
- Czy ruch trafia do oczekiwanej reguły zapory z polityką IPS i logowaniem?
- Czy szeroka reguła polityki przesłania bardziej szczegółową regułę?
- Czy polityka zawiera nieuzasadnione działania, takie jak Allow packet, Disable lub Bypass session?
- Czy polityka odpowiada ruchowi klienta, serwera, VPN lub VoIP?
- Czy przy użyciu rzeczywistego ruchu sprawdzono, że Log Viewer i
ips.logpokazują odpowiednie zdarzenia?
Wyjątki bez właściciela lub daty przeglądu uznaje się za otwarte i należy je uwzględnić w najbliższym przeglądzie operacyjnym.
Usługa IPS ma stan DEAD
W SFOS 22.0 GA i nowszych wersjach w rzadkich przypadkach może brakować wymaganych danych konfiguracyjnych polityki Web. Usługa polityki Web nie uruchamia się wtedy, IPS nie może zainicjować swojej polityki i pozostaje w stanie DEAD; nie działają również aktualizacje wzorców. W klastrze HA problem może niezależnie dotyczyć każdego węzła.
W CLI ścieżka 5 Device Management > 3 Advanced Shell prowadzi do wymaganej powłoki. Następujące polecenie tylko do odczytu wyświetla wszystkie wiersze usług zawierające ips w nazwie:
service -S | grep -i ips
Istotny jest wyłącznie wiersz, w którym pierwsza nazwa usługi brzmi dokładnie ips; nie chodzi o ipsec-monitor. W klastrze HA każdy węzeł, którego dotyczy problem, należy sprawdzić osobno.
Jeśli usługa ma stan DEAD, należy zabezpieczyć informacje o wersji SFOS, czasie zdarzenia i węźle, pełne dane stanu oraz pliki ips.log i sig_upgrade.log, a następnie skontaktować się z Sophos Support, powołując się na NC-181971. Samo polecenie nie dowodzi występowania tego błędu. Sophos nadal nie podaje wersji zawierającej poprawkę i udostępnia obejście problemu wyłącznie za pośrednictwem pomocy technicznej. Wielokrotne próby ponownego uruchomienia lub nieudokumentowane polecenia naprawcze nie są właściwym rozwiązaniem.