Prawidłowe korzystanie z Sophos Firewall Health Check

Sophos Firewall Health Check to wbudowana funkcja sprawdzania konfiguracji zapory sieciowej. Pokazuje w Control Center, czy ważne ustawienia odpowiadają zalecanym specyfikacjom bezpieczeństwa i najlepszych praktyk. Jest to szczególnie przydatne dla administratorów, ponieważ ryzykowne konfiguracje stają się widoczne, zanim staną się problemem bezpieczeństwa lub operacyjnym.

Szerszy kontekst hardening opisuje hub Sophos Firewall Hardening: best practices dla bezpiecznej konfiguracji.

Sophos wprowadził Health Check wraz z Sophos Firewall v22. Według oficjalnych informacji o wydaniu SFOS 22.0 funkcja ocenia dziesiątki konfiguracji według benchmarków CIS i innych najlepszych praktyk. Wcześniejsze twierdzenie, że dopiero SFOS 22.0 MR1 zaktualizował kontekst CIS, nie znajduje potwierdzenia w tym źródle.

Jak korzystać z tego przewodnika

Health Check przedstawia listę, ale nie podejmuje decyzji. Dlatego przewodnik dodaje ocenę Avanet:

• Wysoki priorytet: podstawowa kontrola bezpieczeństwa lub działania; należy ją wdrożyć albo bardzo dobrze uzasadnić odstępstwo.
• Zależne od kontekstu: przydatne, ale nie dla każdej reguły, ścieżki ruchu lub architektury.
• Zrealizowane inaczej: cel bezpieczeństwa jest już osiągany przez równoważną kontrolę innego dostawcy lub inny proces operacyjny. Udokumentowany override może być wtedy prawidłowy.
• Opcjonalne: funkcja zgodności lub dodatkowa usługa Sophos; czerwony status nie oznacza automatycznie niebezpiecznej konfiguracji.

Ta klasyfikacja nie zastępuje analizy ryzyka. Zapobiega bagatelizowaniu ważnego backupu z powodu niskiej ważności Sophos oraz zbyt szybkiemu przekształceniu opcjonalnej integracji w projekt zakupowy.

Do czego przeznaczony jest Health Check

Health Check nie jest klasycznym stanem systemu ani czujnikiem sprzętowym. Nie sprawdza, czy zasilacz jest uszkodzony lub czy dysk SSD wkrótce ulegnie awarii. Do tego nadają się inne kontrole operacyjne, na przykład Sprawdź stan dysku SSD lub monitorowanie HA i sprzętu.

Do cyklicznej kontroli bieżącego stanu systemu, usług, bezpieczeństwa i administratorów służy codzienna lista administratora Sophos Firewall. Uzupełnia Health Check konfiguracji o Control Center, System graphs, raporty i zdarzenia.

Health Check odpowiada przede wszystkim na następujące pytania:

• Czy dostęp administracyjny jest otwarty zbyt szeroko?
• Czy MFA jest włączone dla krytycznych logowań?
• Czy reguły zapory są zbudowane zbyt otwarcie?
• Czy prawidłowo przygotowano kopie zapasowe, poprawki, rejestrowanie i funkcje Sophos Fusion?
• Czy konfiguracja odbiega od zalecanych standardów bezpieczeństwa?
• Czy są jakieś ustalenia, które należy wyjaśnić przed audytem lub uruchomieniem?

Dzięki temu jest to dobre narzędzie do wzmacniania, przeglądania i kontroli zmian. Nie zastępuje jednak czystej architektury, dokumentacji polityk i ręcznej oceny.

⚠️ Zielony Health Check nie oznacza automatycznie, że zapora jest bezpiecznie zaplanowana. Pokazuje, czy pewne testowalne ustawienia są prawidłowe. Projekt sieci, logika biznesowa, wyjątki, grupy użytkowników i procesy operacyjne nadal wymagają oceny technicznej.

Rozróżnienie SFOS Health Check i Sophos Fusion Account Health Check

Dwie podobnie nazwane funkcje odpowiadają na inne pytania. Opisany tutaj Firewall health check działa na zaporze od SFOS 22.0. Stale sprawdza lokalną konfigurację i jest dostępny w Monitor & analyze > Firewall health check albo przez widżet Control center. Pomoc SFOS 22 nie podaje osobnej licencji dla Health Check. Poszczególne sprawdzane funkcje, takie jak NDR, MDR threat feeds lub DNS Protection, mogą jednak wymagać własnych licencji i integracji z Sophos Fusion.

Sophos Fusion Account Health Check (wcześniej Sophos Central Account Health Check) jest natomiast usługą Sophos Fusion dla całego tenantu, dostępną w My Environment > Account Health Check. Zgodnie z zasadami obliczania wyników Sophos Fusion Health Check sekcja Firewall ocenia obecnie automatyczne kopie zapasowe Sophos Fusion. Na wynik wpływają wyłącznie licencjonowane zapory zarządzane przez Sophos Fusion i połączone z tą platformą. Filtr produktu Network wymaga dodatkowo MDR Plus i zarządzanej zapory. Widok Sophos Fusion nie jest więc szczegółowym widokiem 31 lokalnych kontroli SFOS ani ich zamiennikiem.

Różnią się też działania. Fix now w lokalnym SFOS Health Check jedynie otwiera odpowiednią stronę konfiguracji; administrator sam ocenia i zapisuje zmianę. Fix automatically w Sophos Fusion Account Health Check może zmieniać ustawienia. Według instrukcji Sophos Fusion dotyczącej automatycznych kopii zapasowych zapory harmonogram Never jest domyślnie zmieniany na comiesięczny, pierwszego dnia miesiąca, a brakujące zapory są dodawane. Aby tego nie wykonywać automatycznie, należy ręcznie skonfigurować Global Settings > Products and Services > Firewall > Schedule Backup. Kopie uruchamiają się o 08:00 w lokalnej strefie czasowej regionu konta; tej godziny nie można zmienić.

Przy otwieraniu WebAdmin z Sophos Fusion zakres działań określają uprawnienia Sophos Fusion do zapory: Full pozwala wprowadzać zmiany, Read-only tylko przeglądać, a Help Desk monitorować oraz korzystać z diagnostyki, logów i raportów. Usunięcie problemu wymaga więc roli uprawnionej do zmiany danego ustawienia. Sam dostęp do diagnostyki lub Health Check nie jest zgodą na zmianę.

Poprawnie oceń wynik i status

Health Check jest pomocne, ale nie jest niezależnym od producenta audytem bezpieczeństwa. Premiowane jest również użycie Sophos Fusion, DNS Protection, NDR Essentials, MDR threat feeds i Synchronized Security. Z punktu widzenia Avanet jest to wyraźny element cross-sellingu: Noncompliant może oznaczać prawdziwą lukę, na przykład WebAdmin wystawiony bez MFA, albo tylko brak opcjonalnej usługi Sophos, mimo że Microsoft Defender, inny EDR/NDR, SIEM lub filtr DNS już realizuje ten sam cel.

Rekomendacja Avanet: każde ustalenie należy ocenić, ale nie każde bezrefleksyjnie wdrażać. Czerwony punkt dotyczący WebAdmin, MFA, nieszyfrowanego uwierzytelniania, kopii zapasowych lub otwartych reguł wymaga dużej uwagi. Czerwony punkt dotyczący nielicencjonowanej usługi Sophos jest przede wszystkim decyzją architektoniczną i produktową, a nie automatycznie potwierdzoną luką bezpieczeństwa. Cel bezpieczeństwa, istniejące alternatywy i proces operacyjny decydują, czy właściwe jest włączenie, zabezpieczenie w inny sposób czy uzasadniony override.

Dlatego nie należy aktywować każdej rekomendacji tylko po to, aby wyświetlacz zmienił kolor na zielony. Przykładem jest komunikat logowania: może być wymagany w środowiskach audytu lub zgodności. Jednak w wielu normalnych środowiskach operacyjnych oznacza przede wszystkim dodatkowe kliknięcie przy każdym logowaniu i praktycznie nie zwiększa bezpieczeństwa technicznego. Jeżeli funkcja jest potrzebna, artykuł Konfiguracja komunikatu logowania i wiadomości w Sophos Firewall wyjaśnia zarządzanie tekstem, podgląd, weryfikację i wycofanie zmiany. Jeśli podnosi to tylko wynik Health Check, wartość dodana jest ograniczona.

Przy takich funkcjach należy zapytać, jakie ryzyko zmniejszają, czy istnieje już równoważna kontrola, jakiej licencji i transmisji danych wymagają oraz kto obsługuje alerty, wyjątki i fałszywe alarmy. Bez jasnych odpowiedzi udokumentowany override jest zwykle uczciwszy niż nieużywana funkcja włączona wyłącznie dla wyniku.

Nie należy utożsamiać NDR Essentials z MDR. NDR Essentials analizuje wybrany ruch zapory i generuje wykrycia. Sophos MDR oznacza Managed Detection and Response i jest dodatkową płatną usługą z analitykami oraz procesami obsługi incydentów. MDR threat feeds mają sens tylko wtedy, gdy usługa jest rzeczywiście licencjonowana i włączona w procesy operacyjne. Wynik NDR nie oznacza automatycznie konieczności zakupu MDR.

Ogólna zasada:

• Dostęp do zarządzania udostępniany przez Internet, MFA, poprawki, kopie zapasowe, reguły dotyczące haseł i IPS to zazwyczaj prawdziwe podstawy bezpieczeństwa lub działania. Punkty te należy traktować bardzo poważnie.
• Logowanie, raportowanie, powiadomienia i NTP są ważne dla działania i identyfikowalności. Jednak konkretna ścieżka zależy od modelu operacyjnego.
• DNS Protection, NDR, MDR threat feeds, X-Ops, Sophos Fusion i Synchronized Security są możliwymi rozwiązaniami, a nie uniwersalnymi wymaganiami. Skuteczna alternatywa jest ważniejsza niż logo Sophos.
• Zastrzeżenie dotyczące logowania jest zwykle bardziej funkcją zapewniającą zgodność/powiadomienie niż technicznym środkiem ochronnym. Powinieneś go aktywować tylko wtedy, gdy jest to naprawdę wymagane lub pożądane.

Szybka decyzja: co naprawdę należy wdrożyć?

Przy pierwszym otwarciu Health Check wyniki można podzielić na cztery grupy robocze:

• Sprawdzić natychmiast i zwykle naprawić: 8, 9, 11, 13-20, 22, 25, 28 i 31. Obejmują hotfixy, ochronę logowania, hasła administratorów, MFA, szyfrowane uwierzytelnianie, SSH, ekspozycję WAN, aktualizacje wzorców, IPS, zbyt szerokie reguły i prawidłowy czas.
• Bardzo ważne, nawet jeśli Sophos ocenia je jako Low lub Medium: 16 i 21. Backup wymaga przetestowanego restore. Alerty potrzebują działającej ścieżki przez e-mail, monitoring, Sophos Fusion lub SIEM.
• Decyzja zależna od ścieżki ruchu i architektury: 3, 5, 10 i 23-27. X-Ops, Heartbeat, zasady haseł użytkowników, Web Policy, Zero-Day Protection, Application Control i TLS Inspection nie są jednakowo przydatne w każdej regule.
• Włączyć tylko z odpowiednim ekosystemem Sophos lub świadomą decyzją o usłudze cloud: 1, 2, 4, 6, 12, 29 i 30. Synchronized Application Control, NDR Essentials, MDR threat feeds, Security Heartbeat, DNS Protection i funkcje Sophos Fusion nie są uniwersalnym minimum. Punkt 7, Login disclaimer, jest przede wszystkim decyzją zgodności.

Ta klasyfikacja jest celowo bardziej bezpośrednia niż ważność Sophos. Ocenia, co najpierw zmniejsza ryzyko w rzeczywistym środowisku, a nie co Sophos może sprzedać lub technicznie zintegrować.

Otwórz Health Check

Stan kontroli stanu pojawia się w Control center. Widok szczegółowy znajdziesz także w menu głównym:

Monitor & analyze > Firewall health check

Można tam zobaczyć liczbę sprawdzonych konfiguracji, punktów zgodnych i punktów niezgodnych. Sophos wyświetla niezgodne wpisy według ważności. Dane są aktualizowane w przypadku zmiany monitorowanej konfiguracji. Dzięki temu Health Check nadaje się również do bezpośredniego monitorowania po zmianach.

Podczas przeglądu nie należy po prostu odnotowywać ogólnego statusu. Ważniejsze są konkretne ustalenia, kontekst ryzyka i planowane działanie. Pojedyncze krytyczne odkrycie dotyczące dostępności WAN WebAdmin jest ważniejsze w działaniu niż kilka ustaleń niskiego poziomu bez ujawnienia w Internecie.

Zrozumienie stanu, ważności i zastąpienia

Widok szczegółowy pokazuje dla każdego testu, czy konfiguracja jest zgodna, niezgodna lub ręcznie nadpisana. Te trzy stany są ważniejsze dla działania niż czysta wartość procentowa.

• Zgodny: Sprawdzona konfiguracja jest zgodna z odpowiednią polityką. Po większych zmianach należy je jeszcze poddać walidacji technicznej.
• Niezgodny: Sprawdzona konfiguracja nie jest zgodna z polityką. Należy ocenić ryzyko, narażenie i wykonalność.
• Ręczne zastąpienie stanu zasady: Konfiguracja nie jest zgodna z polityką, ale została ręcznie oznaczona jako zgodna. Tego statusu należy używać wyłącznie z uzasadnieniem, właścicielem i terminem ponownego przeglądu.

Menu działań otwiera się za pomocą trzech kropek w kolumnie Action danego ustalenia. Fix now prowadzi do odpowiedniej strony konfiguracji, gdzie należy samodzielnie sprawdzić i zapisać zmianę. Override status ręcznie oznacza niezgodny punkt jako Complies, bez zmiany konfiguracji. Undo override pojawia się tylko dla polityki, której status został już nadpisany, i przywraca go do Doesn't comply; nie cofa poprawki konfiguracji. Jest to praktyczne, ale nie zastępuje oceny: Health Check nie wie automatycznie, czy równoważny mechanizm ochrony rzeczywiście działa w innym miejscu.

Ważność pomaga w sortowaniu, ale nie zastępuje oceny eksperckiej. Jest to statyczna ocena Sophos, która nie zna ekspozycji ani kontroli kompensujących. Ustalenie Low dotyczące brakujących backupów może być pilniejsze niż Medium dotyczące nieużywanej usługi Sophos.

Jeśli wynik wydaje się nielogiczny, należy również sprawdzić wersję firmware i znane błędy. Oficjalne informacje o wydaniu wymieniają dla SFOS 22.0 GA Build 411 poprawki NC-165825 dla błędnego wyniku Doesn't comply NDR Essentials na zaporach wirtualnych, NC-169472 dla błędnego wyniku reguł zapory oraz NC-167645 dla sortowania, które nie utrzymywało się po użyciu Override status. Te identyfikatory potwierdzają tylko opisane błędy i nie stanowią ogólnego wyjaśnienia późniejszych wyników. Jeśli zachowanie powtórzy się na aktualnym buildzie, najpierw należy udokumentować policy, rzeczywistą konfigurację i build, a następnie skontaktować się z Sophos Support, zamiast zmieniać ryzykowne ustawienie tylko po to, by uzyskać zielony status.

Funkcje wyszukiwania i sortowania tabeli kontroli stanu pomagają grupować wyniki według zasad, modułów, standardów lub ważności. W przypadku większych zapór sieciowych jest to bardziej praktyczne niż samo patrzenie na panel kontrolny.

Indywidualna ocena kontroli Health Check

Lista opiera się na 31 kontrolach z angielskiego widoku Health Check użytego w tej analizie. Sophos może zmienić ich liczbę, nazwę, standard lub ważność wraz z aktualizacją firmware. Jeśli lokalna zapora pokazuje dodatkowe lub inaczej nazwane wyniki, jej widok jest rozstrzygający. Status nie jest podany, ponieważ różni się zależnie od zapory. Ważne jest znaczenie każdej kontroli i jej właściwa ocena.

Aktywna reakcja na zagrożenia i zaawansowane zabezpieczenia

• 1. Synchronized Application Control powinno być włączone. Standard: Zalecany, Istotność: Średnia. Funkcja dokładniej identyfikuje aplikacje dzięki Sophos Endpoint i wymaga Security Heartbeat; przy pierwszym użyciu trzeba ją również włączyć w Sophos Fusion. Ocena Avanet: opcjonalne. Włączać tylko przy zgodnych endpointach Sophos i wtedy, gdy wykryte aplikacje będą później klasyfikowane oraz używane w Application Filter. Przy Microsoft Defender lub innym produkcie endpoint uzasadniony override jest lepszy niż nieskuteczna aktywacja.
• 2. Należy aktywować NDR Essentials i monitorować co najmniej jeden interfejs. Standard: Zalecany, Istotność: Średnia. Firewall analizuje wybrany ruch w chmurowej usłudze Sophos NDR, wykrywa IoC i je rejestruje, ale nie blokuje ich automatycznie. Obsługiwane są wybrane interfejsy w strefach LAN, DMZ i Custom; WAN, Wi-Fi oraz niektóre typy interfejsów, takie jak RED i XFRM, są wykluczone. Active-Active HA nie jest obsługiwane. Trzeba również włączyć logi Active Threat Response, a zależnie od typu IoC muszą działać kontrole firewall, DNS, IPS lub decryption. Ocena Avanet: zależne od kontekstu lub opcjonalne. Włączać tylko po wyjaśnieniu licencji, analizy w chmurze, ochrony danych, odpowiednich interfejsów i odpowiedzialności za alerty. Nie zastępować istniejącego NDR tylko po to, aby Health Check był zielony.
• 3. Sophos X-Ops powinien być włączony, Action Log and drop. Standard: CIS, ważność: wysoka. SophosLabs Threat Intelligence może blokować znane złośliwe adresy IP, domeny i URL. Ocena Avanet: zależne od kontekstu, z dużą korzyścią, jeśli dostępna jest wymagana licencja. Po włączeniu sprawdź logi i wyjątki; inny skuteczny proces Threat Intelligence może również realizować ten cel bezpieczeństwa, choć wynik Health Check nie musi go uwzględniać.
• 4. Należy włączyć MDR threat feeds, Action Log and drop. Standard: Zalecana, Ważność: Wysoka. Wymaga Sophos MDR, rejestracji w Sophos Fusion i odpowiednich licencji. Ocena Avanet: opcjonalne. Powiązany przewodnik opisuje pilot, Audit ID, Task Queue i weryfikację incydentu. Bez umowy MDR nie jest to błąd konfiguracji, lecz rekomendacja produktu i usługi.
• 5. W regule zapory sieciowej należy użyć Synchronized Security Heartbeat. Standard: CIS, Istotność: Średnia. Ocena Avanet: zależne od kontekstu. Funkcja jest bardzo przydatna z Sophos Endpoint, ale nie pasuje do Microsoft Defender ani innego EDR. Konieczny jest pilotaż: urządzenia, które nigdy nie wysłały heartbeat, zależnie od reguły mogą nadal uzyskać dostęp. Opcje Block clients with no heartbeat i Block request to destination with no heartbeat wymuszają oczekiwane zachowanie dla takich urządzeń.
• 6. Security Heartbeat powinien być włączony. Standard: CIS, ważność: wysoka. Funkcja łączy Sophos Firewall i Sophos Endpoint przez Sophos Fusion. Ocena Avanet: zależne od kontekstu. Jest przydatna w środowisku Sophos Endpoint. Bez Sophos Endpoint czerwony wynik jest spodziewany i nie dowodzi niebezpiecznej konfiguracji zapory.
• 12. DNS Protection powinien być skonfigurowany i aktywny. Standard: Zalecany, Istotność: Średnia. Status Active wymaga odpowiedniej licencji, resolverów DNS Protection na firewallu oraz publicznego adresu IP firewalla jako Location w Sophos Fusion. Ocena Avanet: opcjonalne. Włączać tylko wtedy, gdy usługa jest świadomie używana jako warstwa zabezpieczeń DNS, a jej logi są analizowane. Inne filtry DNS mogą realizować ten sam cel, mimo że Sophos Health Check nie uzna ich za compliant.

Administrator, uwierzytelnianie i Device Access

• 7. Login disclaimer powinien być aktywny. Standard: CIS, ważność: średnia. To przede wszystkim temat compliance. Techniczny efekt ochronny jest niewielki, ale przy logowaniu pojawia się dodatkowe kliknięcie.
• 8. Ustawienie hotfixów powinno być włączone. Standard: CIS, ważność: wysoka. Ocena Avanet: wysoki priorytet. W aktualnym SFOS 22 pod Backup & firmware > Firmware nie ma już osobnego bloku Hotfix. Sophos domyślnie instaluje hotfixy automatycznie; stan można sprawdzić poleceniem system hotfix show w Device Console. Brak pola wyboru w interfejsie nie jest ustaleniem.
• 9. Nieaktywne sesje powinny być kończone, a logowanie blokowane po nieudanych próbach. Standard: CIS, ważność: wysoka. Ocena Avanet: wysoki priorytet. Limity czasu sesji i blokady logowania ograniczają nadużycia otwartych sesji i automatyczne próby logowania. Dobierz wartości tak, aby chroniły, ale nie prowadziły zbyt łatwo do zablokowania dostępu administratorom.
• 10. Password complexity for users powinna być skonfigurowana. Standard: CIS, ważność: wysoka. Ocena Avanet: wysoki priorytet dla kont lokalnych, poza nimi zależne od kontekstu. Przy Entra ID, AD lub innym IdP decydują przede wszystkim jego zasady haseł, blokowania i MFA. Lokalne konta awaryjne i użytkowników portalu nadal należy sprawdzić oddzielnie.
• 11. Należy skonfigurować złożoność haseł administratorów. Standard: CIS, Istotność: Wysoka. To podstawowe utwardzenie. Ważne są również osobiste konta administratorów, MFA, ograniczone sieci zarządzające i usuwanie nieużywanych kont; sama złożoność haseł nie wystarcza.
• 13. MFA dla logowań Remote Access VPN powinno być aktywne. Standard: CIS, ważność: wysoka. Bardzo ważne dla SSL VPN i IPsec Remote Access. Wdrożenie wymaga użytkowników testowych, procedury awaryjnej i sprawdzenia wszystkich używanych ścieżek uwierzytelniania.
• 14. MFA dla WebAdmin Console i VPN Portal powinno być aktywne. Standard: CIS, ważność: wysoka. Jest to szczególnie ważne dla portali osiągalnych ze strefy WAN lub obcych sieci. MFA nie zastępuje ograniczeń Device Access i Local Service ACL.
• 15. Connections to Authentication Servers powinny być szyfrowane. Standard: CIS, ważność: średnia. Ocena Avanet: wysoki priorytet. LDAP bez TLS i inne nieszyfrowane ścieżki uwierzytelniania mogą ujawnić poświadczenia i informacje katalogowe. Test musi obejmować weryfikację certyfikatu i zachowanie w razie awarii.
• 17. Należy włączyć uwierzytelnianie kluczem publicznym dla SSH. Standard: Zalecana, Ważność: Wysoka. Jeśli SSH jest używane, zezwalaj na nie wyłącznie z zaufanych sieci zarządzających; nieużywany dostęp wyłącz.
• 18. User Portal nie powinien być osiągalny ze strefy WAN. Standard: Recommended, ważność: wysoka. Jeżeli dostęp WAN jest konieczny, ogranicz ekspozycję tak mocno, jak to możliwe, wymuś MFA i monitoruj logi logowania.
• 19. WebAdmin Console nie powinna być dostępna ze strefy WAN. Standard: CIS, ważność: wysoka. Jest to jeden z najważniejszych punktów. WebAdmin nigdy nie powinno być szeroko otwierane w internecie. Preferuj VPN lub ZTNA, sieć zarządzającą i ściśle ograniczone Local Service ACL Exception Rules.
• 20. Należy skonfigurować MFA dla domyślnego administratora. Standard: CIS, ważność: wysoka. To konto wymaga szczególnej ochrony jako dostęp awaryjny. Na co dzień używaj osobistych kont administratorów z odpowiednimi rolami.

Kopia zapasowa, aktualizacje, reguły i inspekcja

• 16. Kopie zapasowe należy zaplanować na zaporze lub w Sophos Fusion. Standard: CIS, ważność: niska. Dotkliwość wydaje się niewielka, ale w sytuacji awaryjnej kwestia ta jest niezwykle ważna. Kopie należy szyfrować, przechowywać poza zaporą i przetestować proces przywracania, dokumentując wynik.
• 21. Powiadomienia e-mail powinny być skonfigurowane dla zdarzeń systemowych i bezpieczeństwa. Standard: CIS, Istotność: Niska. Sophos Firewall może wysyłać powiadomienia przez e-mail i SNMP; wymagane zdarzenia wybiera się w System services > Notification list. Ocena Avanet: zależne od kontekstu. Decydujący jest niezawodny i przetestowany kanał alarmowy. Jeśli Syslog, SIEM, monitoring lub Central Alerts działają niezawodnie, e-mail nie jest obowiązkowy. Skonfigurowany serwer SMTP bez wybranych zdarzeń i testu dostarczenia nie stanowi jeszcze procesu alarmowania.
• 22. Należy włączyć automatyczne aktualizacje wzorców. Standard: CIS, Istotność: Wysoka. Ocena Avanet: wysoki priorytet. Bez aktualnych wzorców kilka funkcji ochronnych traci skuteczność. Procedura konfiguracji i sprawdzania aktualizacji wzorców przedstawia automatykę, stany oraz oddzielną instalację firmware APX i RED. W środowiskach odizolowanych (Air Gap) potrzebny jest dodatkowo udokumentowany ręczny proces aktualizacji wzorców i licencji.
• 23. W regule zapory sieciowej należy wybrać Web Policy. Standard: Zalecany, Istotność: Średnia. Jest to często przydatne dla ruchu WWW użytkowników, ale nie powinno być automatycznie stosowane do ruchu server-to-server, aktualizacji ani ruchu specjalnego.
• 24. W regule zapory należy wybrać Zero-day protection. Standard: CIS, ważność: wysoka. Ocena Avanet: zależne od kontekstu, z dużą korzyścią dla odpowiednich ścieżek WWW i pobierania. Licencja, typy plików, ochrona danych, opóźnienia i fałszywe alarmy muszą odpowiadać modelowi operacyjnemu.
• 25. Należy włączyć IPS i wybrać politykę IPS w regule zapory sieciowej. Standard: CIS, ważność: wysoka. Dobierz politykę do klienta, serwera i publikowanej usługi, włącz rejestrowanie i rozwiązuj fałszywe alarmy za pomocą precyzyjnych zmian.
• 26. W regule zapory sieciowej należy wybrać Politykę kontroli aplikacji. Standard: CIS, ważność: średnia. Ma to sens w przypadku reguł internetowych klienta. W przypadku ruchu krytycznego lub nieznanego najpierw obserwuj działanie w trybie rejestrowania, zanim włączysz blokowanie.
• 27. Reguła SSL/TLS Inspection powinna używać Action Decrypt. Standard: CIS, ważność: wysoka. Nie należy aktywować TLS Inspection na ślepo: warunkiem wdrożenia są dystrybucja certyfikatu CA, ochrona prywatności, uwzględnienie przypinania certyfikatów (certificate pinning), wyjątki, faza pilotażowa oraz procesy wsparcia i rozwiązywania problemów.
• 28. Reguła Allow nie powinna wszędzie używać Any dla pól sieciowych i usługowych. Standard: CIS, ważność: średnia. Zawężaj szerokie reguły do źródła, celu i usługi na podstawie rzeczywistych logów. Konieczne Any pozostaje dopuszczalne, ale wymaga uzasadnienia, rejestrowania i regularnego przeglądu.

Sophos Fusion i czas

• 29. Sophos Central Reporting powinien być włączony. Standard: Zalecany, Istotność: Średnia. Jest to przydatne do raportowania i dłuższych ocen, ale nie jest konieczne, jeśli Syslog/SIEM jest obsługiwane czysto.
• 30. Sophos Central Management powinno być zarejestrowane i aktywne. Standard: Zalecany, Istotność: Średnia. Centralne zarządzanie, kopie zapasowe i raportowanie są wygodne, ale wprowadzają zależność od chmury i dodatkowe uprawnienia. Środowiska lokalne, odizolowane lub Air Gap mogą świadomie z tego zrezygnować.
• 31. Należy skonfigurować serwer NTP. Standard: CIS, ważność: niska. Prawidłowy czas jest podstawą dla logów, certyfikatów, MFA, Kerberos i diagnostyki. Sprawdź co najmniej dwa niezawodne źródła czasu i ich osiągalność przez zaplanowaną ścieżkę.

Ustal priorytety i wdrażaj ustalenia

Nie każde odkrycie ma takie samo znaczenie w każdym środowisku. Dlatego też dobry przegląd sortuje wpisy nie tylko według wagi technicznej, ale także według narażenia i ryzyka operacyjnego.

Sprawdziła się następująca kolejność:

1. Sprawdź dostęp do zarządzania i portali wystawiony na Internet.
2. Sprawdź MFA i bezpieczeństwo logowania dla administratorów, VPN Portal, User Portal i dostęp zdalny.
3. Uporządkuj reguły zapory, zawężając zbyt szerokie źródła, cele lub usługi.
4. Sprawdź rejestrowanie zdarzeń, kopie zapasowe i poprawki hotfix.
5. Sprawdź funkcje ochrony na regułę, na przykład IPS, Web Policy, Application Control, TLS Inspection lub Zero-Day Protection.
6. Oceń ustalenia dotyczące Sophos Fusion, raportowania lub NDR pod kątem tego, czy dana funkcja jest rzeczywiście używana i obsługiwana w środowisku.

Kolejność jest pragmatyczna: najpierw elementy bezpośrednio widoczne w Internecie lub umożliwiające dostęp do zapory. Następnie porządkowanie reguł i funkcje ochronne. Na końcu kwestie operacyjne i integracje z ekosystemem.

Bezpieczne wprowadzanie i wycofywanie zmian

Przed pierwszą poprawką należy zapisać build SFOS, finding, wartość początkową i ścieżkę ruchu, której dotyczy zmiana. Zmiany dostępu administracyjnego, uwierzytelniania, reguł lub inspekcji wymagają także aktualnej kopii zapasowej, sprawdzonej alternatywnej drogi dostępu administratora i jasnego planu wycofania. Fix now jest tylko łączem nawigacyjnym, a nie zgodą na bezrefleksyjne przyjęcie proponowanego ustawienia.

Zmiany należy wprowadzać pojedynczo lub w małych, logicznie powiązanych grupach. Następnie trzeba sprawdzić zarówno status Health Check, jak i działanie odpowiedniej funkcji: dozwolony i niedozwolony dostęp administracyjny, logowanie testowe z MFA, trafienia reguły w Log Viewer albo aplikację po zmianie inspekcji. Jeśli finding pozostaje, należy najpierw potwierdzić, że zmieniono właściwą policy i obiekt. Pomoc nie podaje stałego czasu odświeżania; stwierdza jedynie, że dane aktualizują się po zmianie monitorowanej konfiguracji.

Jeśli wystąpią skutki uboczne, na podstawie zgłoszenia zmiany należy przywrócić konkretne ustawienie do udokumentowanej wartości początkowej i ponownie je zweryfikować. Pełne odtworzenie jest rozwiązaniem ostatecznym i musi pasować do platformy oraz wersji firmware. Override status nie zmienia konfiguracji, a Undo override nie wycofuje poprawki; przywraca tylko status policy Doesn't comply.

Typowe ustalenia i odpowiednie środki

WebAdmin, User Portal lub VPN Portal jest zbyt szeroko dostępny

Jeśli portale administracyjne lub portale przeznaczone dla użytkowników są dostępne ze zbyt wielu stref, wzrasta ryzyko skanowania, ataków brute force i automatycznych prób logowania z użyciem wykradzionych danych uwierzytelniających (credential stuffing). Najważniejszym artykułem na ten temat jest Sophos Firewall Zabezpieczenie dostępu: Device Access skonfiguruj poprawnie.

W środowiskach produkcyjnych należy sprawdzić:

• Czy WebAdmin ze strefy WAN jest naprawdę konieczne?
• Czy istnieje reguła wyjątku Local Service ACL dla adresu IP zarządzania lub sieci administracyjnej?
• Czy SSH jest dozwolone tylko z zaufanych sieci?
• Czy User Portal i VPN Portal są dostępne tylko tam, gdzie są potrzebne?

Brakuje MFA albo nie jest konsekwentnie aktywowane

MFA należy stosować co najmniej dla dostępów administracyjnych i Remote Access. Jeśli Health Check pokazuje findings dotyczące MFA, nie należy przełączać wszystkiego naraz dla wszystkich użytkowników. Lepszy jest kontrolowany rollout z użytkownikiem testowym, administratorem awaryjnym i czystym procesem tokenów.

Praktyczne instrukcje znajdują się w MFA dla Sophos Firewall WebAdmin, VPN Portal i Aktywacja zdalnego dostępu.

Reguły zapory są zbyt otwarte

Bardzo szerokie zasady z Any dla źródła, miejsca docelowego lub usługi często rozwijały się w przeszłości. Nie każda ogólna zasada jest automatycznie błędna, ale każdą należy uzasadnić.

Te pytania są pomocne przy czyszczeniu:

• Która strefa naprawdę ma dostęp do której strefy?
• Czy sieci docelowe lub Services można zawęzić?
• Czy rejestrowanie jest aktywne i widoczne są trafienia?
• Czy istnieją stare reguły testowe lub tymczasowe wyjątki?
• Czy regułę można podzielić na kilka bardziej zrozumiałych reguł?

Podstawy opisuje artykuł Zrozumienie i prawidłowa konfiguracja reguł Sophos Firewall. Jeśli nie jest jasne, która reguła ma zastosowanie, pomocne może być Przetestuj regułę zapory sieciowej za pomocą Log Viewer, Test zasad i Packet Capture.

Brak kopii zapasowych, poprawek i procesu aktualizacji

Health Check może wskazywać brakujące kopie zapasowe lub tematy dotyczące aktualizacji/poprawek. Punkty te są mniej spektakularne niż ekspozycja portalu, ale są kluczowe w sytuacji awaryjnej.

Przed wprowadzeniem większych zmian należy utworzyć kopię zapasową i wiedzieć, jak działa przywracanie. Proces opisano w Sophos Firewall Utwórz lub przywróć kopię zapasową. Aby zapoznać się z tematami oprogramowania sprzętowego, zobacz Sophos Firewall Aktualizacja oprogramowania sprzętowego — przygotowanie i najlepsze praktyki.

Rejestrowanie i raportowanie są niekompletne

Jeśli brakuje dzienników, operacja jest ślepa. Health Check może zapewnić wskazówki dotyczące tematów rejestrowania lub raportowania, ale faktyczna decyzja zależy od modelu operacyjnego.

Log Viewer, dzienniki usług i Packet Capture są istotne dla analizy lokalnej. W przypadku dłuższego przechowywania wymagane jest Centralne raportowanie zapory lub Syslog/SIEM. Jeśli nie chcesz badać pojedynczych zdarzeń w dzienniku, ale raczej przepływy ruchu, szczyty przepustowości lub widoczne relacje komunikacyjne, odpowiedni jest również Monitorowanie sFlow. Lokalne podstawy znajdziesz w Sophos Firewall Rozwiązywanie problemów: Services i dzienniki.

Funkcje zabezpieczające nie są aktywne w regułach

Częstym problemem są reguły bez IPS, Web Policy, Application Control, TLS Inspection lub Zero-Day Protection. Tutaj nie powinieneś aktywować wszystkiego we wszystkich obszarach, ale raczej zrozumieć ścieżkę ruchu.

Przykłady:

• Ruch sieciowy użytkowników wymaga innej kontroli niż ruch między serwerami.
• TLS Inspection należy wprowadzić w zaplanowany sposób, ponieważ może to zakłócać działanie aplikacji.
• IPS i Application Control wymagają logowania i procedury przeglądu.
• Funkcje NDR lub źródła zagrożeń są pomocne tylko wtedy, gdy ustalenia zostaną ocenione później.

Wdrożenie opisuje artykuł Prawidłowe wdrażanie TLS Inspection w Sophos Firewall. W przypadku kanałów zagrożeń pasuje Sophos Firewall Kanały zagrożeń.

Udokumentuj przegląd i sprawdź wyniki

Sophos Firewall umożliwia ręczne nadpisanie statusu poszczególnych kontroli. Może to być przydatne, jeśli rekomendacja celowo nie została wdrożona w Twoim własnym środowisku.

Nadpisania statusu nie należy traktować jako funkcji porządkowania wyników. Ma ono sens tylko wtedy, gdy wymóg jest świadomie spełniony w inny sposób lub istnieje skuteczny, równoważny mechanizm kompensujący. Udokumentowany przykład dotyczy polityki MFA should be configured for the default admin: jeśli środowisko wykorzystuje Microsoft Entra ID SSO z MFA jako obowiązkowy mechanizm ochrony logowania, status tego ustalenia można nadpisać z uzasadnieniem zależnym od projektu, ale tylko wtedy, gdy dane logowanie lub konto jest rzeczywiście chronione w równoważny sposób. Samo SSO z MFA dla osobistych kont administratorów nie dowodzi równoważnej ochrony domyślnego konta administratora. Lokalne dostępy zapasowe i awaryjne nadal trzeba chronić i sprawdzać oddzielnie. Nie jest to ogólne zezwolenie na nadpisywanie wszystkich lokalnych ustaleń MFA; inne równoważne mechanizmy ochrony również mogą uzasadniać wyjątek. Bez takiego uzasadnienia ryzyko pozostaje, nawet jeśli widok Health Check wygląda lepiej.

Jeśli punkt zostanie nadpisany, należy to udokumentować:

• Dlaczego zalecenie nie jest odpowiednie?
• Kto zatwierdził tę decyzję?
• Czy wyjątek ma zastosowanie na stałe czy tylko tymczasowo?
• Kiedy zostanie ponownie zbadany?
• Czy istnieje środek kompensujący?

⚠️ Zastąpienie nie jest rozwiązaniem. Jest to świadoma akceptacja ryzyka lub udokumentowany wyjątek. Bez uzasadnienia Health Check staje się mniej wartościowe.

Jasno dokumentuj wyniki

Przegląd kontroli stanu powinien dać zrozumiały wynik. W przeciwnym razie na krótko zobaczysz pulpit nawigacyjny, ale później nie będziesz już wiedział, jaka decyzja została podjęta i które punkty są nadal otwarte.

W małych środowiskach często wystarcza krótka lista śledzenia zawierająca następujące pola:

• Data: Kiedy sprawdzono Health Check?
• Firmware: Dla jakiej wersji SFOS przeprowadzono ocenę?
• Wykrycie: Który niezgodny element został zgłoszony?
• Ryzyko: Dlaczego dany punkt jest istotny lub mniej istotny w tym środowisku?
• Działanie: Co zostało zmienione, przetestowane lub świadomie zaakceptowane?
• Odpowiedzialny: Kto wyjaśni sprawę merytorycznie lub technicznie?
• Termin: Do kiedy działanie powinno zostać ukończone lub poddane ponownej ocenie?
• Dowód: Zrzut ekranu, zgłoszenie, identyfikator zmiany (Change-ID) lub notatka z dziennika audytu.

W przypadku zapór produkcyjnych dowód nie powinien ograniczać się do zrzutu ekranu. Jeśli konfiguracja została zmieniona, zgłoszenie zmiany, ścieżka audytu, reguła zapory, której dotyczy problem, oraz wynik kontroli uzupełniającej stanowią całość. W przypadku zmian w regułach, interfejsach, hostach i Services, szczególnie przydatne jest Sprawdzanie dzienników audytu Sophos Firewall.

Sprawdź ponownie po zmianach

Po naprawieniu powinieneś ponownie otworzyć Health Check i sprawdzić, czy wynik rzeczywiście zniknął. Ponadto wymagany jest test funkcjonalności technicznej, ponieważ sam status zielony nie dowodzi, że ruch produktywny nadal przebiega prawidłowo.

Przykłady:

• Po zmianie Device access sprawdź, czy dostęp administratora z zamierzonej sieci zarządzania nadal działa i nie jest już dostępny z niepożądanych sieci.
• Po zmianach MFA zaloguj się jako użytkownik testowy i osobno sprawdź administratora rezerwowego.
• Po zmianach reguł sprawdź Log Viewer, wykonaj Policy Test i przetestuj aplikacje, których dotyczą zmiany.
• Po zmianach konfiguracji rejestrowania lub raportowania sprawdź, czy nowe zdarzenia są faktycznie widoczne lokalnie, w Sophos Fusion lub w Syslog.
• Po nadpisaniu statusu ustaw przypomnienie o ponownym przeglądzie, aby wyjątek nie został zapomniany na stałe.

Jeśli jednocześnie przetwarzanych jest kilka wyników, zmiany należy podzielić na małe bloki. W przeciwnym razie w przypadku późniejszego problemu nie będzie jasne, czy przyczyną były Device Access, MFA, reguły zapory sieciowej, TLS Inspection, czy też inna zmiana.

Użyj Health Check jako procesu operacyjnego

Health Check jest najsilniejszy, gdy jest wykonywany regularnie i po ważnych zmianach.

Przydatne czasy:

• po wstępnej konfiguracji lub uruchomieniu,
• przed i po głównych zmianach zasad,
• przed aktualizacją oprogramowania sprzętowego,
• po przywróceniu lub wymianie sprzętu,
• po migracji lub większych zmianach architektonicznych,
• przed audytami,
• kwartalnie jako przegląd bezpieczeństwa.

Ścieżka audytu powinna być również używana do samych zmian. Artykuł Sophos Firewall Sprawdź dzienniki ścieżki audytu wyjaśnia, jak oceniać configuration-audit.log i śledzić zmiany konfiguracji.

Praktyczny przebieg przeglądu

Pragmatyczny przegląd kontroli stanu wygląda następująco:

1. Otwórz Health Check w Control Center.
2. Sortuj niezgodne wyniki według ważności.
3. Najpierw sprawdź usługi dostępne w Internecie i dostęp administratora.
4. Zajmij się kwestiami MFA, haseł i sesji.
5. Zidentyfikuj zbyt szerokie reguły zapory i zweryfikuj ich użycie za pomocą Log Viewer.
6. Sprawdź kopię zapasową, poprawki, rejestrowanie i raportowanie.
7. Oceń funkcje ochrony według reguły.
8. Dokumentuj uzasadnione wyjątki zamiast je zastępować bez komentarza.
9. Sprawdź ponownie po zmianach.
10. Udokumentuj wynik, datę, osobę przeprowadzającą przegląd i otwarte kwestie.

W przypadku przeglądów cyklicznych często wystarczą pola Ustalenie, Ryzyko, Działanie, Osoba odpowiedzialna, Status i Termin ponownego przeglądu. Ważne jest, aby ustalenia nie były tylko przeglądane, ale realizowane lub świadomie akceptowane.

Limity

Health Check jest pomocny, ale ma jasne ograniczenia.

• Nie zna pełnej logiki biznesowej środowiska.
• Nie ocenia, czy reguła jest potrzebna z punktu widzenia wymagań środowiska.
• Nie zastępuje modelu segmentacji sieci ani podziału na strefy.
• Nie wykrywa automatycznie każdego ryzykownego przypadku specjalnego.
• Nie zastępuje audytu zewnętrznego ani ręcznej kontroli zasad.
• Nie określa, czy alerty będą przetwarzane później.

Dlatego powinieneś zobaczyć Health Check jako punkt wyjścia. Dzięki temu widoczne odchylenia stają się namacalne, ale rzeczywista jakość bezpieczeństwa wynika z dobrej architektury, czystych procesów i konsekwentnej konserwacji.

Operacyjna lista kontrolna

• Wykonaj Health Check po uruchomieniu i po większych zmianach.
• Ustal priorytety ustaleń według wagi i narażenia.
• Sprawdź osiągalność WebAdmin, SSH, User Portal i VPN Portal ze strefy WAN.
• Włącz MFA dla administratorów, portali i dostępu zdalnego.
• Oczyść lub uzasadnij ogólne reguły zapory sieciowej.
• Włącz logowanie ważnych reguł.
• Sprawdź kopie zapasowe i proces przywracania.
• Udokumentuj proces hotfixów i aktualizacji firmware.
• Ustawiaj zastąpienia tylko z uzasadnieniem.
• Regularnie dokumentuj wyniki kontroli stanu.

Często zadawane pytania