Codzienna kontrola Sophos Firewall: lista dla administratora

Sophos Firewall może pozostawać technicznie dostępny, a mimo to wykazywać pierwsze sygnały ostrzegawcze: połączenie WAN jest niestabilne, zajętość dysku rośnie, usługa zgłasza błąd albo przybywa nieudanych logowań administratorów. Krótka, powtarzalna kontrola operacyjna ujawnia takie zmiany, zanim doprowadzą do dłuższej awarii lub incydentu bezpieczeństwa.

Ta procedura dotyczy bieżącej pracy. Sophos Firewall Health Check ocenia natomiast, czy wybrane ustawienia są zgodne z zaleceniami Sophos i CIS. Obie kontrole uzupełniają się, ale nie zastępują się nawzajem.

Kontrola w dziesięć minut

Do codziennego przeglądu wystarczy stała procedura:

1. W Control Center zanotować model, wersję firmware i build, otworzyć nowe komunikaty i kliknąć ikony stanu usług, WAN, interfejsów i VPN.
2. W Diagnostics > System graphs porównać CPU, pamięć, load average, dysk i ważne interfejsy z typową wartością bazową.
3. Sprawdzić dashboardy bezpieczeństwa i używane raporty za ostatni w pełni dostępny okres pod kątem nowych zdarzeń IPS, web, aplikacji, zero-day lub Active Threat Response.
4. Otworzyć Log Viewer w prawym górnym rogu, wybrać moduł i okres oraz sprawdzić nieudane logowania administratorów, nietypowe źródła i powiązane usługi.
5. W HA uwzględnić węzeł przetwarzający ruch, a w centralnym raportowaniu oczekiwane źródło danych.
6. Udokumentować każde istotne odstępstwo wraz z czasem, firmware, węzłem, źródłem, usługą i kolejnym krokiem.
7. Nie uruchamiać ponownie usług, nie usuwać logów ani nie rozszerzać reguł z powodu pojedynczego skoku. Najpierw skorelować trend, logi i rzeczywiste działanie.

Ta krótka kontrola nie powinna każdego ranka wywoływać zmiany konfiguracji. Jej wartość polega na wczesnym rozpoznawaniu zmian i jasnej decyzji, czy potrzebna jest obserwacja, diagnoza lub eskalacja.

Cztery widoki, cztery różne informacje

Najważniejsze widoki nie pokazują tego samego:

• Control Center: bieżący przegląd systemu, usług, WAN, interfejsów, VPN, uptime oraz komunikatów wymagających działania.
• System graphs: przebieg CPU, pamięci, load average, dysku, transferu WAN i liczników interfejsów w czasie.
• Reports: zagregowana ocena zakończonego okresu. Niektóre widgety i dane raportowe nie są aktualizowane w czasie rzeczywistym.
• Log Viewer: pojedyncze zdarzenia z czasem, modułem, działaniem, informacjami o źródle i celu oraz, zależnie od rodzaju logu, Rule ID lub innymi szczegółami.

Czerwony widget jest sygnałem, a nie pełną diagnozą. Podobnie aktualny zielony status nie dowodzi, że w nocy nie wystąpił krótki błąd. Dopiero połączenie bieżącego stanu, przebiegu, raportu i pojedynczego zdarzenia daje wiarygodny obraz.

Kontrola stanu i dostępności systemu

Najpierw odczytać Control Center

W Control Center kontrola zaczyna się od nowych komunikatów. Sophos pokazuje tam między innymi problemy z rejestracją, licencją, raportowaniem, WAN lub aktualizacją. Niektóre komunikaty znikają automatycznie po usunięciu przyczyny i nie można ich po prostu ręcznie usunąć. Każdy istotny komunikat potrzebuje zatem właściciela i możliwego do prześledzenia kolejnego kroku.

Komunikat Registration pojawia się, gdy Sophos Firewall nie jest zarejestrowany. Komunikat Licenses pojawia się, gdy moduły firewalla nie mają licencji.

Niektóre liczniki widżetów w Control Center są zerowane po restarcie firewalla. Niska wartość licznika po restarcie nie dowodzi więc, że wcześniej nie wystąpiły żadne zdarzenia. Aby ją zinterpretować, należy skorelować uptime z logami trwale zachowanymi dla badanego okresu, na przykład eksportami CSV lub centralnymi logami w granicach ich okresu retencji. Konsola administracji webowej nie wyświetla informacji o temperaturze.

Messages pokazuje również czas, który upłynął od utworzenia komunikatu. Zależnie od typu lub poziomu ważności widżet używa wskaźników Alert, Warning i Available firmware versions. Zapisać razem wskaźnik, czas od utworzenia i tekst komunikatu; opisane poniżej liczniki Services i WAN/VPN nie dotyczą Messages.

Kolor należy zawsze interpretować razem ze szczegółami. W przypadku Services Warning oznacza, że co najmniej jedna usługa została zatrzymana, a Alert — że co najmniej jedna usługa nie mogła się uruchomić. W przypadku WAN i VPN Warning oznacza, że nie działa maksymalnie połowa skonfigurowanych połączeń, a Alert — że nie działa więcej niż połowa. Liczniki te nie uwzględniają znaczenia biznesowego. Awaria jednego głównego tunelu może więc być pilniejsza niż kilka celowo nieaktywnych połączeń. Kliknięcie odpowiedniej ikony pokazuje elementy, których dotyczy stan.

Następnie rzeczywiście używane usługi, połączenia WAN, interfejsy i VPN porównuje się ze stanem oczekiwanym. Czerwony interfejs nie zawsze oznacza awarię: nieużywany port bez adresu IP lub fizyczny interfejs nadrzędny VLAN może zgodnie z oczekiwaniem pojawić się na czerwono. Istotne jest odstępstwo od udokumentowanego projektu.

Jeśli używane są LAG-i, w SFOS 23 otworzyć ikonę Interfaces i sprawdzić również poszczególnych członków LAG pod kątem odłączonych kabli. Pomoc do SFOS 23 wyraźnie opisuje ten widok szczegółowy; odpowiadająca jej pomoc do SFOS 22 tego nie robi. Z operacyjnego punktu widzenia należy pamiętać: nadal dostępny agregat nie dowodzi, że dostępne są wszystkie jego składowe, a tym samym przewidziana redundancja i przepustowość. W zgłoszeniu odnotować składową, której dotyczy problem, oraz odchylenie od stanu docelowego.

Jeśli używane są tunele RED i Wireless APs, porównać widżety statusu połączeń ze stanem docelowym: RED pokazuje liczbę zestawionych tuneli w stosunku do skonfigurowanych, a Wireless APs liczbę aktywnych punktów dostępowych w stosunku do skonfigurowanych. Oczekujące punkty dostępowe są dodatkowo wyświetlane w czerwonych nawiasach i nie należy ich wliczać do aktywnych punktów dostępowych. RED otwiera listę tuneli, a Wireless APs prowadzi do Wireless > Access points. Connected remote users pokazuje liczbę użytkowników połączonych przez SSL VPN i otwiera Current activities > Remote users; natomiast Live users pokazuje liczbę wszystkich bieżących użytkowników i otwiera Current activities > Live users. Te liczby użytkowników nie zastępują sprawdzenia dostępności RED ani punktów dostępowych.

Jeśli przewidziano korzystanie z DNS Protection, sprawdzić status konfiguracji tej usługi w widżecie System. Pomoc do SFOS 22 wymienia pięć stanów: Not subscribed oznacza brak licencji; wymagana jest licencja Xstream Protection. Not configured wskazuje na konieczność wprowadzenia adresów IP DNS Protection. W przypadku Unrecognized source sprawdzić publiczny adres IP zapory i jego przypisanie do lokalizacji w Sophos Fusion. Active oznacza aktywną usługę DNS Protection; ikona informacji wskazuje na brak rejestracji w Fusion. W przypadku IP address conflict sprawdzić adres IP wpisany w lokalizacji, a konflikt, którego nie można rozwiązać, eskalować do Sophos Support.

Pomoc do SFOS 23 wymienia Not subscribed, Not configured i Active, a w przypadku braku konfiguracji odsyła do Configure DNS servers; przy ikonie informacji dla stanu Active wskazuje na rejestrację w Sophos Central. Nie wynika z tego, że dwa dodatkowe stany udokumentowane w SFOS 22 zostały usunięte z działającego systemu. Właściwą dla danej wersji ścieżkę konfiguracji i rozwiązywania problemów opisuje artykuł Konfiguracja DNS Protection z Sophos Firewall: nie przenosić bez zmian ścieżki Traditional DNS / lokalizacja z SFOS 22 na zintegrowaną ścieżkę SFOS 23.

Aby sprawdzić zdarzenia DNS Protection, w Log Viewer wybrać moduł System i filtrować według DNS Protection. W zgłoszeniu zapisać wersję, status widżetu i istotne wpisy dziennika. To sprawdzenie konfiguracji i zdarzeń nie zastępuje ani testu działania rozwiązywania nazw i skuteczności filtrowania, ani raportów DNS Protection; same ogólne raporty bezpieczeństwa nie potwierdzają gotowości operacyjnej DNS Protection.

Widżet Messages należy traktować jako listę działań, a nie ogólny strumień zdarzeń. Gdy pojawi się żądanie utworzenia Secure Storage Master Key, trzeba utworzyć klucz, aby dodatkowo chronić dane wrażliwe, takie jak hasła. Komunikat o dostępie WAN oznacza, że WebAdmin (HTTPS) i CLI (SSH) są dostępne ze strefy WAN: jeśli zdalne zarządzanie jest konieczne, należy użyć VPN albo Local Service ACL Exception ograniczonego do konkretnych hostów lub sieci zarządzających, zamiast pozostawiać szeroki dostęp z WAN. Przy komunikacie o dysku raportów wykorzystanie musi spaść poniżej dolnego progu; samo zejście poniżej górnego progu nie wystarcza. Komunikaty związane z wymaganiem znikają po jego spełnieniu i nie można ich usunąć ręcznie.

Przy komunikacie o nieudanej aktualizacji firewalli programowych, wirtualnych i chmurowych najpierw sprawdzić, czy firewall został przypisany do konta w Sophos Central (Claim). To przypisanie jest warunkiem przed aktualizacją, a nie tylko działaniem po jej niepowodzeniu. Dokumentacja SFOS 22 nazywa portal „Sophos Fusion (previously Sophos Central)”, a dokumentacja SFOS 23 — „Sophos Central”; warunek pozostaje taki sam. Zapisać status przypisania i komunikat błędu w tickecie przed zaplanowaniem kolejnej próby zgodnie z runbookiem firmware.

Active threat response należy odczytywać według źródła i działania. MDR oraz Sophos X-Ops pokazują liczbę zablokowanych zagrożeń, NDR Essentials zagrożenia monitorowane, a źródła zewnętrzne także stan synchronizacji. Configure prowadzi do konfiguracji ochrony, Reports do powiązanego raportu, a More details rozwija widżet. Działanie Reports nie jest dostępne w modelach bez raportowania lokalnego. Zagrożenie monitorowane nie oznacza zagrożenia zablokowanego, a problem z synchronizacją źródła zewnętrznego należy oddzielić od liczby zagrożeń.

Widżet Reports jest skrótem do maksymalnie pięciu raportów krytycznych, wybieranych zależnie od subskrybowanych modułów, a nie pełną listą zdarzeń na żywo. Mapowanie wygląda następująco:

• High-risk applications — Web Protection
• Objectionable websites — Web Protection
• Web users — Web Protection
• Intrusion attacks — Network Protection
• Web server protection — Web Server Protection
• Email usage — Email Protection
• Email protection — Email Protection
• Traffic dashboard — Web Protection lub Network Protection
• Security dashboard — Web Protection lub Network Protection

High-risk applications, Objectionable websites, Intrusion attacks, Web server protection i Email protection dotyczą poprzedniego dnia; Web users szereguje dziesięciu użytkowników według liczby bajtów ruchu web przesłanych poprzedniego dnia. Email usage pokazuje przesłane bajty poczty, a Traffic dashboard i Security dashboard podsumowują kategorie ruchu i odrzucone działania. Brak kafelka może zatem wynikać z subskrypcji, a nie z zerowej aktywności. Kliknięcie nazwy otwiera raport, a ikona pobierania pozwala go zachować. Oddzielne okresy i drill-downy dla sygnałów endpointów, użytkowników, Zero-day, TLS i sesji opisuje artykuł Interpretacja User & Device Insights.

Traffic insight podsumowuje ruch przetworzony w ciągu ostatnich 24 godzin. Web activity pokazuje trend oraz średnią i maksymalną liczbę przesłanych bajtów; Cloud applications pokazuje wykryte aplikacje oraz bajty przychodzące i wychodzące, a po wskazaniu także stany New, Sanctioned, Unsanctioned i Tolerated. Pozostałe wykresy szeregują pięć głównych dozwolonych kategorii aplikacji i web według bajtów, zablokowane kategorie aplikacji według trafień oraz hosty, którym odmówiono dostępu do sieci ze względów na stan zabezpieczeń. Kliknięcie wykresu chmurowego lub słupka kategorii otwiera odpowiednią stronę Cloud applications albo filtrowany raport; taki drill-down należy wykonać przed uznaniem skoku lub pozycji z pierwszej piątki za incydent.

Codzienna kontrola obejmuje co najmniej:

• nieoczekiwanie zatrzymane lub zdegradowane usługi;
• łącza WAN, które są down lub wielokrotnie zmieniają stan;
• interfejsy produkcyjne z nowymi errors, drops lub collisions;
• ważne połączenia VPN rozłączone wbrew planowi operacyjnemu;
• nieoczekiwany restart lub nietypowo krótki uptime;
• nowe komunikaty bez właściciela lub ticketu.

Odczytywać System graphs względem wartości bazowej

W Diagnostics > System graphs należy szukać wzorców, nie tylko pojedynczych skoków. CPU, pamięć i load average ocenia się razem z liczbą rdzeni, ruchem i badanym okresem. Krótki skok podczas kopii zapasowej, raportowania lub aktualizacji wzorców ma inne znaczenie niż stale wysokie obciążenie przy normalnym ruchu.

W przypadku Disk Usage najważniejszy jest trend. Jednorazowo wysokie wykorzystanie i stały wzrost to różne obrazy problemu. Przy interfejsach traffic, errors, drops i collisions pomagają odróżnić obciążenie firewalla od problemu z łączem, dupleksem, kablem lub switchem.

Aby uzyskać porównywalny materiał, należy zapisać typ wykresu i okres oraz użyć tego samego okresu w tickecie. Wykresy interfejsów pokazują oddzielny wykres tylko dla VLAN-ów w strefie WAN. SFOS łączy dane VLAN-ów z innych stref z wykresem ich fizycznego interfejsu nadrzędnego. Nie należy więc oczekiwać oddzielnego, spokojnego wykresu LAN VLAN, jeśli SFOS go nie udostępnia.

Szczegółowe omówienie load average, offloadingu, TLS Inspection i System graphs znajduje się w artykule Prawidłowa interpretacja wydajności Sophos Firewall. Limity pamięci i raportowanie on-box opisuje Kontrola pamięci i raportów Sophos Firewall.

⚠️ Pojedyncza wysoka wartość nie jest jeszcze powodem do restartu usługi. Najpierw muszą pasować czas, długość, powtarzalny wzorzec, objęty ruch i logi. Przed restartem zabezpiecza się odpowiednie logi, a w przypadku incydentu także CTR.

Kontrola zdarzeń bezpieczeństwa i logowań administratorów

Analizować raporty pod kątem zmian

Codzienny przegląd bezpieczeństwa koncentruje się na nowych lub wyraźnie zmienionych wzorcach. Zależnie od aktywnych funkcji szczególnie istotne są następujące obszary:

• Reports > Dashboards > Security dashboard jako zagregowany przegląd;
• Reports > Network & threats > Intrusion attacks dla zdarzeń IPS;
• Reports > Network & threats > Active threat response dla zablokowanych IoC;
• Reports > Applications & web dla ryzykownego, niepożądanego lub zablokowanego korzystania z webu i aplikacji;
• raporty zero-day, Security Heartbeat lub Wireless, jeżeli te funkcje są używane produkcyjnie.

W wybranym raporcie najpierw ustawić zakres dat, a następnie kliknąć Generate. Filter pozwala ograniczyć wyniki do odpowiedniego źródła, działania lub reguły. Dostępne formaty pobierania zachowują wyświetlone dane jako dowód w tickecie. Wraz z eksportem należy zapisać okres i strefę czasową, aby późniejsze porównanie nie obejmowało dwóch różnych okien.

Nie każde zdarzenie jest incydentem. Decydują źródło, cel, użytkownik, reguła, działanie, częstotliwość i związek czasowy. Pojedyncza próba dostępu z danego kraju nie uzasadnia ogólnej blokady całego kraju. Powtarzające się ataki na wystawioną usługę albo nowy dozwolony ruch wysokiego ryzyka wymagają natomiast konkretnej analizy.

W bezpiecznej ocenie źródeł i krajów pomaga Blokowanie szkodliwych adresów IP i krajów. Jeśli pakiet został odrzucony, Analiza odrzuconych pakietów w Sophos Firewall prowadzi od Log Viewer i Rule ID do rzeczywistej przyczyny odrzucenia.

Ocenić nieudane logowania administratorów

Nieudane logowania administratorów sprawdza się według czasu, źródłowego adresu IP, usługi docelowej, nazwy użytkownika i powtórzeń. Literówka z sieci zarządzającej wymaga innego traktowania niż rozproszone próby z Internetu lub wielokrotne logowania do wyłączonego konta.

Log Viewer otwiera się w prawym górnym rogu dowolnej strony WebAdmin, w nowym oknie pełnoekranowym. Należy wybrać odpowiedni moduł, ustawić okres za pomocą Timer filter, a następnie określić pole, warunek i wartość przez Add filter. Wyszukiwanie pełnotekstowe przydaje się dla adresu IP, nazwy użytkownika, portu lub reguły. Przed dalszymi zmianami trzeba zachować przefiltrowane wpisy jako CSV za pomocą Export; Reset usuwa potem wszystkie filtry. Brak wpisu sesji nie zawsze dowodzi braku ruchu, ponieważ reguły firewalla zwykle zapisują sesję dopiero po odebraniu przez firewall zdarzenia zamknięcia połączenia.

Przy podejrzanych próbach najpierw sprawdza się ekspozycję i tożsamość:

1. Czy WebAdmin, SSH, User Portal lub VPN Portal ma być dostępny z danej strefy?
2. Czy źródło pochodzi z zatwierdzonej sieci zarządzającej lub precyzyjnej Local Service ACL Exception?
3. Czy dla danego dostępu administracyjnego aktywne jest MFA?
4. Czy CAPTCHA, Session Timeout i Block login działają zgodnie z planem?
5. Czy występują równoczesne zmiany konfiguracji lub udane logowania tego samego konta?

Dostęp sieciowy kontroluje się w Device Access i Local Service ACL w Sophos Firewall. Konta, profile i offboarding opisuje Lokalni administratorzy i profile dostępu do urządzenia, a drugi składnik Włączanie MFA w Sophos Firewall.

⚠️ Block login może po nieudanych próbach zablokować źródłowy adres IP dla wielu usług. Nie należy agresywnie zaostrzać wartości podczas incydentu, dopóki nie istnieje przetestowana alternatywna ścieżka administracyjna i odzyskiwania.

Uwzględnić ograniczenia HA, raportowania i modeli

W klastrze HA każdy węzeł zapisuje tylko logi i raporty ruchu, który sam przetworzył. Dla zdarzenia należy więc ustalić węzeł aktywny lub przetwarzający ruch w danym momencie. Pusty raport lokalny na jednym węźle nie dowodzi, że w klastrze nie wystąpiło zdarzenie.

Central Firewall Reporting w Sophos Fusion (wcześniej Sophos Central) może zapewnić skonsolidowany widok i dłuższą retencję. Widoku lokalnego i centralnego nie należy jednak traktować jako identycznych źródeł czasu rzeczywistego. Włączanie i eksploatacja Central Firewall Reporting wyjaśnia wybór, odbiór i retencję logów.

Dodatkowe ograniczenia:

• Raporty Control Center są aktualizowane okresowo i nie stanowią widoku zdarzeń w czasie rzeczywistym.
• Po aktualizacji z SFOS 20.0 lub starszej wersji do SFOS 21.0 lub nowszej widżet Reports może pokazywać zero albo niższą wartość aż do następnej aktualizacji po 24 godzinach, ponieważ Sophos przechowuje raporty sprzed i po aktualizacji w oddzielnych bazach danych.
• XGS 87/87w i XGS 88/88w nie obsługują raportów on-appliance. Centralne logi, SIEM i monitoring są dlatego na tych modelach ważniejsze.
• Brakujące dane mogą wynikać z loggingu, okresu raportu, licencji, retencji, disk watermark lub wyboru niewłaściwego węzła HA. Nie dowodzą automatycznie, że nie było ruchu.

Porównać build firmware ze znanymi problemami

Jeśli obserwacja nie odpowiada stanowi oczekiwanemu, należy postępować zgodnie z runbookiem Avanet dotyczącym decyzji o firmware. Trzeba porównać dokładnie zainstalowany build i konkretny objaw, a nie tylko wersję główną. W zgłoszeniu należy zapisać ID problemu, buildy dotknięte i poprawione oraz ewentualny workaround, a przed zmianą systemu skorelować wynik ze szczegółami Control Center, System graphs, logami i testem funkcjonalnym. Przykłady do codziennej kontroli:

• NC-181971: w SFOS 22.0 GA i nowszych usługa IPS może w rzadkich przypadkach przejść w stan Dead i nie dać się ponownie uruchomić. Sophos nie publikuje samodzielnego obejścia i zaleca kontakt z Supportem w celu jego zastosowania.
• NC-181748: w SFOS 22.0 GA Build 411 wiadomości Web Instant Alert nie są generowane dla kategorii zablokowanych przez polityki webowe. W tym buildzie brak alertu nie dowodzi więc, że blokada nie wystąpiła.
• NC-180066, NC-180110, NC-178745 i NC-172912: informacje o wydaniu wymieniają poprawki w SFOS 22.0 MR2 Build 546 dotyczące zatrzymanych usług antywirusowych, trybu failsafe spowodowanego przez daemon logowania, restartów HA z powodu braku pamięci oraz migających System graphs. Jeśli objaw pasuje na starszym buildzie, w tickecie należy zapisać ID i ścieżkę aktualizacji. Firmware aktualizuje się wyłącznie w zatwierdzonym oknie serwisowym, z kopią zapasową i ścieżką rollbacku.

Znane problemy mogą się zmieniać niezależnie od tego artykułu. Przed eskalacją należy ponownie otworzyć wpis i zachować jego bieżący stan. Pasujące ID może wyjaśnić objaw, ale nie zastępuje oceny wpływu ani testu działania.

Dokumentowanie i eskalowanie odchyleń

Codzienna kontrola kończy się dopiero wtedy, gdy istotne odchylenia mają kolejny krok. W tickecie lub dzienniku operacyjnym zazwyczaj wystarczą następujące pola:

• data, czas i strefa czasowa;
• nazwa firewalla, model, wersja SFOS i build;
• w HA: węzeł, rola i ostatnia zmiana stanu;
• objęta funkcja, strefa, interfejs, VPN lub reguła;
• stan zaobserwowany i oczekiwany;
• zrzut ekranu, okres raportu, filtr logów lub Rule ID;
• wpływ na użytkowników lub usługi;
• właściciel, priorytet, termin kolejnej kontroli i ścieżka eskalacji.

Przed działaniem zmieniającym stan należy zachować szczegółowy status z Control Center, wykres z widocznym okresem oraz przefiltrowane wiersze logów lub eksport CSV. Dla zgłoszenia do Supportu można w Diagnostics > Tools > Consolidated troubleshooting report utworzyć CTR z System snapshot i potrzebnymi plikami logów: podać przyczynę, wybrać Generate i po zakończeniu pobrać zaszyfrowany plik. Tryb debug i czyszczenie logów nie należą do codziennej kontroli: zmieniają stan diagnostyczny lub niszczą dowody i powinny być używane celowo, wyłącznie zgodnie z instrukcjami Supportu.

Natychmiastowa eskalacja jest wskazana, gdy produkcyjne łącze WAN lub krytyczna ścieżka VPN niespodziewanie ulegają awarii, usługa ochronna jest zatrzymana, zajętość dysku nadal rośnie, obciążenie pozostaje wysokie, powtarzające się ataki na administratora korelują z udanym logowaniem albo nowe zdarzenie bezpieczeństwa pasuje do dozwolonego szkodliwego ruchu.

Obserwacja jest raczej wystarczająca przy krótkim, wyjaśnionym skoku, celowo nieużywanym interfejsie lub znanym zdarzeniu z udokumentowanym właścicielem i stabilnym testem działania.

Wybrać odpowiednią częstotliwość kontroli

Sophos nie określa jednego uniwersalnego codziennego rytmu dla wszystkich widoków. Częstotliwość zależy więc od ryzyka, godzin pracy i istniejącego monitoringu:

• Codziennie lub na zmianę: nowe komunikaty, zatrzymane usługi, WAN/VPN/HA, uptime, krytyczne zdarzenia bezpieczeństwa i nieudane logowania administratorów.
• Co tydzień: trendy wykresów, błędy interfejsów, wzrost zajętości dysku, wzorce raportów, powtarzające się źródła i otwarte tickety.
• Po zmianach, aktualizacjach lub failover: ponownie sprawdzić objętą funkcję, logi, raporty, ścieżkę alertów i rzeczywisty ruch.
• Regularnie poza krótką kontrolą: Health Check, przegląd reguł, test odtwarzania kopii zapasowej, terminy licencji i certyfikatów oraz planowanie pojemności.

Powiadomienia e-mail lub monitoring skracają czas reakcji, ale nie zastępują przeglądu. Ścieżka alertów jest wiarygodna dopiero po przetestowaniu transportu, wyboru zdarzeń, odbiorcy i reakcji. Pełną procedurę opisuje Konfiguracja i test powiadomień e-mail Sophos Firewall.

Operacyjna lista kontrolna

• Sprawdzić Control Center pod kątem nowych komunikatów i nieoczekiwanych zmian stanu.
• Porównać usługi, produkcyjne łącza WAN, interfejsy, VPN i uptime ze stanem oczekiwanym.
• Odczytać CPU, pamięć, load average, dysk i ważne liczniki interfejsów względem wartości bazowej.
• Sprawdzić raporty bezpieczeństwa za ostatni w pełni dostępny okres.
• Ustawić okres raportu, wybrać Generate i w razie potrzeby wyeksportować istotne wyniki.
• W Log Viewer wybrać moduł, Timer filter i Add filter; skorelować źródło, cel, użytkownika, działanie i Rule ID oraz zachować odpowiednie wiersze jako CSV.
• Ocenić nieudane logowania administratorów według źródła, usługi i powtórzeń.
• W HA uwzględnić węzeł przetwarzający ruch i jego lokalne logi.
• Porównać build i pasujący objaw z aktualnymi informacjami o wydaniu i znanymi problemami; zapisać ID w tickecie.
• Nie wykonywać restartów, usuwania logów ani szerokich zmian reguł bez zabezpieczenia dowodów i ścieżki odzyskiwania.
• Udokumentować każde istotne odchylenie z właścicielem, priorytetem i kolejnym krokiem.
• Po korekcie sprawdzić ponownie nie tylko status, ale również rzeczywiste działanie.

FAQ