Konfiguracja i bezpieczne testowanie IPS na Sophos Firewall

System zapobiegania włamaniom (Intrusion Prevention System, IPS) analizuje ruch sieciowy pod kątem znanych wzorców ataków, exploitów i nietypowych cech protokołów. Aby IPS faktycznie zapewniał ochronę, musi być włączony globalnie. Ponadto reguła zapory przetwarzająca dany strumień ruchu musi korzystać z odpowiedniej polityki IPS.

Bezpieczna, skrócona procedura wygląda następująco: sprawdzić licencję i wzorce, włączyć IPS, wybrać politykę odpowiednią do chronionego systemu, przypisać ją do właściwej reguły zapory, a następnie zweryfikować ścieżkę ruchu na małej grupie pilotażowej. Stosowanie najbardziej restrykcyjnej polityki w każdej regule nie zapewnia automatycznie najlepszej ochrony. Niedopasowana polityka generuje zbędne wykrycia, obciążenie lub zakłócenia i utrudnia analizę rzeczywistych zagrożeń.

Sprawdzanie wymagań wstępnych i stanu licencji

Przed rozpoczęciem konfiguracji potrzebne są:

• aktywna subskrypcja Network Protection albo licencja próbna;
• dostępne sygnatury IPS oraz prawidłowo działające aktualizacje wzorców;
• Firewall Rule ID reguły, która faktycznie obsługuje przewidziany ruch;
• rejestrowanie zdarzeń reguły w celu skorelowania sesji, reguły zapory i zdarzenia IPS;
• osoba odpowiedzialna, zdefiniowane testy i procedura wycofania zmian na wypadek fałszywych alarmów.

Funkcja IPS Protection jest domyślnie wyłączona. Na zaporze połączonej z Internetem sygnatury IPS są aktualizowane tylko przy ważnej licencji i włączonym IPS. Udokumentowanym wyjątkiem są licencjonowane zapory Air Gap: mogą one otrzymywać sygnatury IPS za pośrednictwem przewidzianego procesu aktualizacji także wtedy, gdy IPS jest wyłączony. Różnice opisano w artykule Licencjonowanie Air Gap i aktualizacje wzorców.

Po wygaśnięciu subskrypcji Network Protection przełącznik IPS może nadal wyglądać na aktywny, mimo że zapora nie egzekwuje już ochrony IPS. Licencja próbna działa inaczej: po jej wygaśnięciu IPS wyłącza się automatycznie. Gdy IPS jest wyłączony, sygnatury online nie są już pobierane, a konfigurowanie polityk i własnych sygnatur staje się niemożliwe. Po 30 dniach pozostawania w tym stanie SFOS usuwa sygnatury i reguły IPS. Jeśli konfiguracja ma zostać zachowana, wcześniej należy utworzyć eksport lub kopię zapasową.

Nawet przy wyłączonym IPS istniejące polityki IPS można nadal przypisywać do reguł zapory. Takie przypisanie nie potwierdza aktywnej analizy ani skuteczności ochrony. Jeśli płatna subskrypcja wygasła i IPS jest wyłączony albo wygasła licencja próbna automatycznie wyłączyła IPS, przed ponownym włączeniem IPS trzeba najpierw aktywować subskrypcję Network Protection. Po aktywacji należy ponownie sprawdzić przełącznik IPS i sygnatury.

Nawet ważna subskrypcja nie zapewnia ochrony bezterminowo bez kontaktu z systemem licencjonowania. Zapory online zwykle synchronizują licencje co 24 godziny. Jeżeli synchronizacja nie powiedzie się przez 90 kolejnych dni, SFOS wyłącza subskrypcje zabezpieczeń; w przypadku licencji Air Gap okres ten wynosi 180 dni. Logowanie do systemu i przesyłanie ruchu mogą nadal działać, ale bez ochrony zapewnianej przez wyłączone subskrypcje. Dlatego stan licencji należy uwzględnić podczas diagnostyki, gdy IPS pozornie jest skonfigurowany, lecz nie działa.

W sekcji Backup & firmware > Pattern updates SFOS wyświetla między innymi stany Ready to install, Downloading, Success i Failed. Opcja Update pattern now uruchamia aktualizację standardowych definicji wzorców. Pomyślny wpis dotyczący Application Signatures nie dowodzi, że pobrano również sygnatury IPS: w systemach online nadal wymagają one licencji i włączonego IPS.

Włączanie IPS i określanie ścieżki ruchu

1. Otworzyć Intrusion prevention > IPS policies.
2. Włączyć IPS Protection.
3. W sekcji Backup & firmware > Pattern updates sprawdzić czas i stan wzorców IPS.
4. Udokumentować dotychczasowy stan IPS Protection, Firewall Rule ID pilotażowego strumienia ruchu, dotychczasową politykę IPS, ustawienie Log firewall traffic oraz istniejące wyjątki.

Włączenie lub wyłączenie funkcji Firewall Acceleration albo PKI Acceleration powoduje ponowne uruchomienie IPS lub silnika DPI. Takich zmian nie należy wprowadzać w ramach tej procedury aktywacji. Jeżeli powtarzalny problem dotyczy globalnego ustawienia silnika, artykuł Bezpieczne sprawdzanie globalnych ustawień IPS wyjaśnia, które zmiany obowiązują natychmiast, które wymagają kliknięcia Apply lub ponownego uruchomienia oraz jak zachować wartość początkową.

Politykę dobiera się do chronionego systemu

Target oznacza tę stronę komunikacji, której podatne oprogramowanie chroni dana sygnatura. Nie jest to po prostu odpowiednik strefy źródłowej lub docelowej. Przykładowo w przypadku przeglądarki odbierającej spreparowaną odpowiedź wartością Target może być Client, natomiast w przypadku opublikowanego serwera WWW odbierającego złośliwe żądanie — Server.

Wyboru można dokonać, odpowiadając na trzy pytania:

1. Który system jest chronionym celem w analizowanym przepływie: klient czy serwer?
2. Jakie platformy, protokoły i usługi rzeczywiście na nim działają?
3. Czy istniejąca polityka obejmuje ten zakres bez grup sygnatur niezwiązanych z danym zastosowaniem?

Dla typowej ścieżki klienta do Internetu punktem wyjścia jest odpowiednia polityka kliencka lub LAN-to-WAN. W przypadku publikacji DNAT należy wybrać politykę serwerową lub przeznaczoną dla serwera WWW, dopasowaną do systemu operacyjnego i faktycznie opublikowanych portów. W przepływie VPN lub między segmentami również decyduje chroniona aplikacja, a nie wyłącznie nazwa strefy źródłowej. MTU, MSS, opóźnienie i przepustowość sprawdza się przy tym na rzeczywistej trasie VPN.

VoIP wymaga osobnego testu funkcjonalnego sygnalizacji SIP i mediów RTP, z przygotowaną możliwością powrotu do wcześniejszej polityki. W sieciach zarządzania, kopii zapasowych i infrastruktury precyzyjne reguły są zwykle cenniejsze niż szczególnie szeroki wybór sygnatur. IPS może również utrudniać ataki lateralne na granicach segmentów wewnętrznych; progi ochrony przed spoofingiem i zalewaniem ruchem pozostają jednak odrębnym zadaniem realizowanym za pomocą ustawień ochrony przed spoofingiem i DoS.

Własna polityka jest przydatna, gdy trzeba precyzyjniej ograniczyć ścieżkę ruchu, pojedynczy SID wymaga udokumentowanego wyjątku albo działanie ma świadomie odbiegać od Recommended. W tym celu w sekcji Intrusion prevention > IPS policies > Add nadaje się jednoznaczną nazwę, na przykład IPS-Pilot-LAN lub IPS-DNAT-Webserver, i klonuje odpowiednią istniejącą politykę jako punkt wyjścia. Najpierw należy zapisać nową lub sklonowaną politykę za pomocą Save; nie oznacza to jeszcze utworzenia nowej reguły polityki. Następnie modyfikuje się reguły w kopii; samych dostarczonych sygnatur nie można edytować.

Filtrowanie sygnatur i kolejność reguł polityki

Podczas dodawania reguły można wybrać pojedyncze sygnatury, własne sygnatury lub opcję Select all. Smart Filter obsługuje wyszukiwane terminy oraz kryteria takie jak Category, Severity, Platform i Target; po wprowadzeniu danych filtr stosuje się klawiszem Enter.

Edytor reguł otwiera się niezależnie od tworzenia polityki: w sekcji Intrusion prevention > IPS policies należy wybrać Edit przy żądanej, już zapisanej polityce, następnie Add i wprowadzić jednoznaczną nazwę reguły. Następnie należy wybrać potrzebne sygnatury: Select individual signature dla pojedynczych sygnatur albo Custom signature dla własnych sygnatur. Aby wyszukiwać za pomocą Smart filter, należy najpierw wybrać Select all, wprowadzić wyszukiwany termin i zastosować go klawiszem Enter.

Kategorie ułatwiają merytoryczne zawężenie zakresu. Poniższa pełna tabela objaśnia etykiety widoczne w SFOS. Category jest pomocą w wyszukiwaniu, a nie oceną ryzyka; wraz z Platform i Target pozwala filtrowi Smart Filter wybierać wyłącznie właściwe sygnatury.

Szerokie kategorie wskaźników należy najpierw wdrażać obserwacyjnie w ramach pilotażu. Zwłaszcza indicator-compromise może powodować fałszywe alarmy, więc sama kategoria nie uzasadnia blokady ani wyjątku.

Po wybraniu sygnatur należy świadomie ustawić Action; różnice wyjaśniono w sekcji dotyczącej poziomu Severity i działania. Regułę należy zapisać za pomocą Save w edytorze reguł. Jest to odrębny krok od pierwszego zapisania polityki. W procedurze DDoS należy następnie dodatkowo zapisać politykę zawierającą tę regułę za pomocą Save.

Po zapisaniu należy rozpocząć nową sesję testową i sprawdzić ips_policy_id lub idp_policy_id oraz fw_rule_id; przy wykryciu trzeba także porównać signature_id, classification i log_subtype z zamierzoną regułą i działaniem. Sam brak wykrycia nie dowodzi, że filtr lub polityka zostały zastosowane.

Reguły polityki są analizowane od góry do dołu. Szeroka reguła obejmująca wszystkie sygnatury serwerowe może więc przesłonić umieszczoną niżej regułę szczególną dla pojedynczego SID. Konkretne wyjątki lub odmienne działania należy umieścić nad regułą ogólniejszą. Kolejne wykrycie musi wskazywać oczekiwaną politykę, Rule ID i działanie.

Własne sygnatury IPS służą do jasno opisanego przypadku wykrywania, a nie jako zamiennik niewłaściwie dobranego zestawu standardowego. Procedurę obejmującą składnię, precyzyjną politykę pilotażową oraz test pozytywny i negatywny opisano w artykule Tworzenie i testowanie własnych sygnatur IPS.

Oddzielna ocena poziomu Severity i działania

W logach, zgłoszeniach i wyjątkach istotne są SID, Category, Severity, Platform, Target oraz Recommended action. Sophos przypisuje poziom Critical wartościom 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 sygnaturom nadrzędnym. Warning oznacza określony rodzaj ruchu i generuje alarm. Sam poziom Severity nie rozstrzyga o ryzyku: ocena musi także uwzględniać osiągalność celu, system docelowy, stan poprawek i faktycznie zastosowane działanie.

To przyporządkowanie CVSS nie jest pozbawione wyjątków: Sophos opisuje przypadki, w których klasyfikacja Severity nie mieści się w podanych formułach. Nie można z tego wywnioskować ani istnienia udokumentowanej funkcji WebAdmin umożliwiającej nadpisanie poziomu Severity, ani procedury ponownej klasyfikacji; należy sprawdzić faktycznie wyświetlany poziom Severity sygnatury.

Reguła polityki może zastąpić zalecane działanie:

• Recommended stosuje działanie zalecane przez Sophos dla danej sygnatury i jest typowym punktem wyjścia dla reguł produkcyjnych.
• Allow packet rejestruje wykrycie, ale przepuszcza pakiet. Nadaje się to do pilotażu, lecz nie zapobiega wykrytemu atakowi.
• Drop packet odrzuca tylko dany pakiet. Aplikacja może działać dalej albo zgłosić błąd.
• Drop session po wykryciu kończy całą sesję.
• Reset aktywnie kończy sesję TCP, wysyłając reset do inicjatora.
• Disable wyłącza dokładnie tę sygnaturę, a związane z nią wykrywanie przestaje działać.
• Bypass session pomija kontrolę pozostałej części sesji. Ruch może wówczas trafić do FastPath lub zostać odciążony (offload), a tym samym uniknąć kontroli w szerszym zakresie, niż zamierzano.

Działania dotyczące pakietów są stosowane do poszczególnych pakietów. Działania dotyczące sesji analizują ruch do pierwszego wykrycia, a następnie obejmują całe połączenie. Dlatego każde odstępstwo od Recommended należy uzasadnić, wskazując sygnaturę, politykę, regułę zapory, osobę odpowiedzialną i datę przeglądu.

Wybieranie polityki IPS w regule zapory

1. Otworzyć Rules and policies > Firewall rules.
2. Edytować regułę, której Rule ID potwierdzono w przepływie pilotażowym.
3. W sekcji Other security features, przy opcji Detect and prevent exploits (IPS), ustawić wybraną politykę IPS.
4. Włączyć Log firewall traffic, zapisać zmiany i utworzyć nową sesję na potrzeby testu.

Samo włączenie funkcji globalnie nie wystarcza. Jeśli ruch najpierw trafi do innej reguły bez polityki IPS, późniejsza reguła nie zapewni mu ochrony. Artykuł Reguła Sophos Firewall nie jest stosowana: sprawdzanie przyczyn pomaga zweryfikować dopasowanie reguły.

Reguły zapory ograniczają ruch, który może zostać przepuszczony. IPS wykrywa wzorce ataków w widocznym strumieniu danych. Web Protection kontroluje treści i kategorie internetowe, Application Control klasyfikuje aplikacje, TLS Inspection w razie potrzeby udostępnia do analizy zaszyfrowaną zawartość, a Zero-Day Protection bada podejrzane pliki. Threat Feeds, na przykład aktualizowane kanały firmy Cybora, dodatkowo blokują znane złośliwe adresy IP, domeny i adresy URL. Moduły te wzajemnie się uzupełniają; żaden nie zastępuje precyzyjnej reguły zapory, zarządzania poprawkami ani prawidłowego doboru polityki.

Zatwierdzanie kontrolowanego pilotażu

Przed rozpoczęciem należy określić czas trwania testu, osobę odpowiedzialną, punkt odniesienia i kryteria przerwania. Punkt odniesienia obejmuje czas aktualizacji wzorców, Firewall Rule ID, dotychczasową i nową politykę IPS, znane wyjątki, użycie procesora i pamięci oraz co najmniej jedno niezmienione połączenie kontrolne. W przypadku VoIP, ERP, protokołów przemysłowych, VPN i starszych aplikacji test wymaga okna serwisowego.

1. Potwierdzić przypisanie polityki: utworzyć nową sesję, a następnie w Packet Capture lub logu zapory sprawdzić oczekiwane Firewall Rule ID i IPS Policy ID. Potwierdza to przypisanie, ale jeszcze nie wykrycie sygnatury. Wspólną procedurę użycia Log Viewer i Packet Capture można zastosować bezpośrednio do połączenia testowego.
2. Przetestować rzeczywiste procesy robocze: wykonać logowanie, przesyłanie plików, aktualizacje, operacje API oraz długotrwałe sesje. Ping nie jest ich zamiennikiem.
3. Przeanalizować zdarzenia: po wykryciu zapisać identyfikator i nazwę sygnatury, politykę, regułę zapory, źródło, cel, porty oraz faktycznie zastosowane działanie. Na potrzeby testu funkcjonalnego nie przeprowadza się prawdziwego ataku. Do uzyskania deterministycznego, nieszkodliwego wykrycia służy kontrolowany pilotaż własnej sygnatury.
4. Porównać połączenie kontrolne: dozwolone połączenie z tego samego zakresu musi nadal wskazywać oczekiwaną regułę i aplikację. Jeśli pakiety znikają, odrębna analiza odrzuconych pakietów pomoże zawęzić przyczynę.
5. Dopiero wtedy rozszerzyć zakres: kolejne hosty lub reguły można objąć polityką tylko wtedy, gdy nie ma niewyjaśnionych blokad i zachowane są wcześniej ustalone limity obciążenia, opóźnienia i działania aplikacji.

Powodzenie testu nie oznacza, że koniecznie musiała zostać wyzwolona sygnatura ataku. Istotne są: potwierdzone przypisanie polityki, prawidłowe działanie przepływów testowych i kontrolnych, brak niewyjaśnionych blokad oraz akceptowalne wykorzystanie zasobów. Gdy tylko przestanie działać krytyczny proces biznesowy, wystąpi niewyjaśniona blokada lub zostanie przekroczony uzgodniony limit wydajności, należy przywrócić udokumentowane wartości początkowe przypisania polityki i rejestrowania zdarzeń reguły. Politykę utworzoną specjalnie na potrzeby pilotażu usuwa się dopiero wtedy, gdy nie jest już przypisana do żadnej reguły, a jej wyjątki zostały udokumentowane. Jeżeli przed pilotażem IPS był globalnie wyłączony, ten stan początkowy można przywrócić dopiero po sprawdzeniu, które inne reguły zapory utracą w ten sposób ochronę IPS.

Prawidłowa interpretacja logów, Packet Capture i raportów

Poszczególne narzędzia odpowiadają na różne pytania:

• Log zapory: ips_policy_id wskazuje politykę przypisaną do przepływu. Informacja ta jest przydatna nawet bez wykrycia sygnatury.
• Zdarzenie IPS: log_type=IDP, signature_id, signature_msg, idp_policy_id, fw_rule_id, classification i log_subtype łączą sygnaturę, politykę, regułę oraz wynik. Pole detection_severity w logu nie musi odpowiadać sposobowi prezentacji kategorii Severity w polityce.
• Packet Capture: pokazuje między innymi Firewall Rule ID, NAT ID i IPS Policy ID w przepływie pakietów.
• ips.log: zawiera bardziej szczegółowe informacje o decyzjach IPS, DPI, Application Control i Active Threat Response.
• sig_upgrade.log i sigmigration.log: przedstawiają odpowiednio aktualizację i migrację sygnatur.
• Reports > Network & threats > Intrusion attacks: nadaje się do analizy historycznej; Log Viewer jest lepszy do sprawdzania pojedynczych, bieżących zdarzeń.

Przeznaczenie pozostałych plików logów i usług opisano w artykule Usługi i logi Sophos Firewall. Jeśli aktywnych jest kilka modułów ochrony, należy porównać ten sam moment w logach zapory, IPS, Web, Application Control oraz SSL/TLS Inspection. Reguła zapory może zezwolić na ruch, który następnie zostanie zablokowany przez moduł działający na dalszym etapie przetwarzania.

Sprawdzanie wydajności przy porównywalnym obciążeniu

Zapotrzebowanie IPS na zasoby zależy od modelu urządzenia, ruchu, sygnatur, TLS Inspection, Application Control, VPN i rozmiaru pakietów. Przed włączeniem i po włączeniu funkcji należy przy porównywalnym obciążeniu zarejestrować użycie procesora i pamięci, przepustowość, opóźnienie, retransmisje w krytycznych aplikacjach, a także wolumen logów IPS/DPI i Syslog.

Krótkotrwałe wyłączenie IPS nie dowodzi jeszcze związku przyczynowego. Powtarzalne porównania umożliwia prawidłowa interpretacja danych o wydajności zapory i kontrolowany test iPerf.

Rozstrzyganie fałszywych alarmów zamiast prostego zezwalania na ruch

Wykrycie IPS może być fałszywym alarmem, oznaką nieoczekiwanej aplikacji albo rzeczywistą próbą wykorzystania podatności. Najpierw należy zapisać identyfikator i nazwę sygnatury, źródło, cel, usługę, regułę zapory, czas, częstotliwość, aplikację, której dotyczy zdarzenie, oraz stan poprawek. Następnie trzeba podjąć decyzję:

1. Odtworzyć prawidłowy proces i potwierdzić, że wyzwala go właśnie ten SID.
2. Sprawdzić stan poprawek, informacje producenta i dostępność chronionego systemu.
3. Ocenić ryzyko wynikające z zezwolenia na wykryty ruch. Nie należy tworzyć trwałego wyjątku, jeżeli wyniki są niejednoznaczne lub niemożliwe do odtworzenia.
4. Wybrać najwęższe odwracalne rozwiązanie: najlepiej zainstalować poprawkę albo dokładniej ograniczyć ścieżkę ruchu; w przeciwnym razie tymczasowo ustawić dla pojedynczego SID działanie Allow packet w polityce używanej wyłącznie w tym miejscu. Opcje Disable i Bypass session usuwają większy zakres ochrony, dlatego wymagają mocniejszego uzasadnienia.
5. Ponownie przetestować prawidłowy przepływ pozytywny oraz przepływ negatywny lub kontrolny.
6. Udokumentować wyjątek, osobę odpowiedzialną i datę przeglądu, a następnie ponownie go ocenić po aktualizacji aplikacji, wzorców, oprogramowania układowego lub systemu.

Jeśli wiele sygnatur zakłóca działanie tej samej aplikacji, lepszym rozwiązaniem niż zbiór trwałych wyjątków globalnych jest własna polityka o wąskim zakresie albo lepsza segmentacja. Globalne wyłączenie IPS nie jest właściwym sposobem wycofania zmiany dotyczącej pojedynczego SID.

Rozwiązywanie problemów według objawu

Brak widocznych zdarzeń IPS

Najpierw należy utworzyć nową sesję i sprawdzić Firewall Rule ID oraz ips_policy_id w logu zapory lub Packet Capture. Brak identyfikatora polityki oznacza, że przepływ trafia do innej reguły albo do wybranej reguły nie przypisano polityki IPS. Jeżeli przypisanie polityki jest potwierdzone, ale nie występuje wykrycie sygnatury, może to być prawidłowe zachowanie dla nieszkodliwego ruchu. Powtarzalną weryfikację zapewnia precyzyjna własna sygnatura w izolowanym pilotażu, a nie prawdziwy exploit.

Zdarzenie występuje, ale ruch nie jest blokowany

W zdarzeniu IPS należy sprawdzić signature_id, politykę i log_subtype. Następnie trzeba zweryfikować pierwszą pasującą regułę polityki oraz jej faktyczne działanie. Opcje Allow packet, Disable lub Bypass session mogą uniemożliwić oczekiwaną blokadę, a szeroka reguła umieszczona wyżej może przesłonić regułę szczegółową. Po każdej zmianie należy przetestować nową sesję.

Brak sygnatur IPS lub niepowodzenie aktualizacji wzorców

Należy łącznie sprawdzić stan licencji, globalny przełącznik IPS oraz sekcję Backup & firmware > Pattern updates. Stan Failed ani aktualny stan Application Signatures nie potwierdzają pomyślnej aktualizacji IPS. Plik sig_upgrade.log przedstawia przebieg aktualizacji, a przy problemach z licencją dodatkowego kontekstu dostarcza licensing.log. W klastrze HA urządzenie Primary aktualizuje wzorce IPS i automatycznie synchronizuje je z urządzeniem Auxiliary.

Usługa IPS ma stan DEAD

W sekcji System services > Services należy sprawdzić i udokumentować stan usługi IPS. Jeżeli Sophos Support dodatkowo poprosi o dane z powłoki dotyczące konkretnego węzła, opcja 5 Device Management > 3 Advanced Shell prowadzi do następującego sprawdzenia tylko do odczytu:

service -S | grep -i ips

Istotny jest wiersz, w którym pierwsza nazwa usługi to dokładnie ips; nie chodzi o ipsec-monitor. To polecenie Advanced Shell nie jest częścią opublikowanej procedury dotyczącej znanego problemu i powinno być używane wyłącznie w ramach uzgodnionej diagnostyki z pomocą techniczną. W klastrze HA wymagany stan należy zapisać osobno na każdym węźle, którego dotyczy problem.

W systemie SFOS 22.0 GA i nowszym w rzadkich przypadkach może brakować danych konfiguracyjnych wymaganych przez politykę Web. Usługa Web Policy nie uruchamia się wtedy, IPS nie może zainicjować swojej polityki i pozostaje w stanie DEAD; nie udają się również aktualizacje wzorców. W klastrze HA problem może niezależnie dotyczyć każdego węzła.

Należy zapisać wersję SFOS, czas, węzeł, stan usługi, pliki ips.log i sig_upgrade.log, a następnie skontaktować się z Sophos Support, powołując się na NC-181971. Sam stan usługi nie potwierdza tej przyczyny. W aktualnej liście znanych problemów Sophos nadal nie podaje wersji zawierającej poprawkę, a obejście udostępnia za pośrednictwem pomocy technicznej. Wielokrotne ponowne uruchamianie ani nieudokumentowane polecenia naprawcze nie są właściwą metodą diagnostyczną.

Pełny pakiet sygnatur tylko w uzasadnionych przypadkach szczególnych

Podczas aktualizacji wzorców SFOS może pobrać pełny pakiet sygnatur IPS zamiast pakietu częściowego. Opcja jest dostępna wyłącznie na urządzeniach z co najmniej 32 GB pamięci RAM i według Sophos może wpływać na wydajność. Nie włącza ona IPS ani nie przypisuje polityki do żadnej reguły zapory.

Uzasadnionym przypadkiem jest wskazana wprost przez Sophos Support sygnatura, której brakuje w pakiecie częściowym. Opcji nie należy włączać profilaktycznie tylko dlatego, że większa liczba sygnatur wydaje się korzystna. Najpierw trzeba odczytać bieżący stan w Device Console:

system ips full-signature-pack show

Pomoc Device Console nie podaje wartości domyślnej. Po potwierdzeniu wymaganego limitu pamięci RAM i konkretnej potrzeby można włączyć pobieranie pełnego pakietu:

system ips full-signature-pack enable

Po następnej aktualizacji wzorców należy sprawdzić czas ich aktualizacji, plik sig_upgrade.log, oczekiwaną sygnaturę, stan IPS, użycie procesora i pamięci RAM oraz ruch, którego dotyczy zmiana. Jeżeli nie uzyskano oczekiwanej korzyści albo działanie systemu się pogorszyło, trzeba przywrócić odczytany wcześniej stan. Jeśli przed testem miał on wartość disable, polecenie wycofujące zmianę brzmi:

system ips full-signature-pack disable

Wykrywanie PQC od SFOS 22.0 MR2

SFOS 22.0 MR2 potrafi wykrywać i kontrolować czyste oraz hybrydowe mechanizmy postkwantowej wymiany kluczy oparte na ML-KEM. Nowe wzorce IPS są domyślnie wyłączone, ponieważ PQC nie jest z definicji podejrzane. Aby analizować takie połączenia, należy najpierw użyć własnej polityki pilotażowej z opcją Allow packet i rejestrowaniem zdarzeń. Dopiero zdefiniowany przypadek użycia oraz stabilne testy — pozytywny i kontrolny — uzasadniają zastosowanie opcji Drop session lub Reset. Więcej informacji zawiera artykuł Sophos Firewall v22 MR2: kontrola PQC.

FAQ