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 sprawdzić nowe komunikaty oraz stan usług, WAN, interfejsów, VPN i uptime.
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. W Log Viewer 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.

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.

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.

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.

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.

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.

Sophos Central Firewall Reporting 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 wersji starszej niż SFOS 21 widgety raportów mogą początkowo pokazywać mało danych lub nie pokazywać ich wcale, dopóki nowa baza raportów nie zostanie zaktualizowana.
• 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.

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.

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.
• Skorelować podejrzane zdarzenia w Log Viewer ze źródłem, celem, użytkownikiem, działaniem i Rule ID.
• 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.
• 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