Sophos Firewall Health Check użyj poprawnie

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.

Health Check został wprowadzony wraz z Sophos Firewall v22. Funkcja ocenia konfiguracje między innymi pod kątem najlepszych praktyk i standardów, takich jak testy porównawcze CIS. W przypadku SFOS 22.0 MR1 zaktualizowano także kontekst CIS.

Instrukcje wideo

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.

Health Check z większym prawdopodobieństwem odpowie 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 centralne?
• 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.

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 Central, 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 finding 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 Zastrzeżenie dotyczące logowania: Powiadomienie o logowaniu może być wymagane w środowiskach audytu lub zgodności. Jednak w wielu normalnych środowiskach operacyjnych generuje on przede wszystkim dodatkowe kliknięcie przy każdym logowaniu i praktycznie nie zapewnia żadnego zwiększenia bezpieczeństwa technicznego. Jeśli to tylko zwiększy wynik kontroli stanu, wartość dodana jest możliwa do zarządzania.

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 Central 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, Central 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 Central 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 Centrum sterowania. 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 ponownym przesłaniem.

Pod Action widok oferuje bezpośrednie etapy pracy w zależności od wyniku. Napraw teraz prowadzi do odpowiedniej strony konfiguracji, Stan zastąpienia ręcznie ustawia niezgodny punkt na zgodny, a Cofnij zastąpienie cofa takie zastąpienie. Jest to praktyczne, ale nie zastępuje oceny: Health Check nie wie automatycznie, czy kontrola została rzeczywiście wdrożona w równym stopniu gdzie indziej.

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. SFOS 22.0 MR1 skorygował fałszywe statusy Doesn't comply dla reguł zapory oraz NDR Essentials na zaporach wirtualnych. Wyraźnie błędny status nie uzasadnia ryzykownej zmiany konfiguracji ani pochopnego override.

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 Central. 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. Wartość domyślna: CIS, ważność: wysoka. Ma to znaczenie dla bezpieczeństwa, gdy aktywnie wykorzystywane są źródła zagrożeń. Należy sprawdzić fałszywe alarmy i rejestrację.
• 4. Należy włączyć MDR threat feeds, Action Log and drop. Wartość domyślna: Zalecana, Ważność: Wysoka. Wymaga Sophos MDR, rejestracji w Sophos Central i odpowiednich licencji. Ocena Avanet: opcjonalne. 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. Jest to ważne w środowiskach Sophos Endpoint. W przeciwnym razie należy najpierw wyjaśnić projekt endpointów.
• 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 Central. 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. Wartość domyślna: 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 określonej liczbie nieudanych prób. Standard: CIS, Istotność: Wysoka. Ogranicza to nadużycie pozostawionych sesji i automatyczne próby logowania, szczególnie w przypadku wystawionych portali i dostępu administracyjnego.
• 10. Password complexity for users powinna być skonfigurowana. Standard: CIS, ważność: wysoka. Jest to szczególnie istotne dla lokalnych użytkowników i portali. Jeśli używany jest zewnętrzny IdP, należy również sprawdzić jego politykę haseł i MFA.
• 11. Należy skonfigurować złożoność haseł administratorów. Standard: CIS, Istotność: Wysoka. To podstawowe utwardzenie. Równie ważne są osobiste konta administratorów, MFA i ograniczony dostęp z sieci zarządzającej.
• 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. Rollout wymaga administratora awaryjnego i użytkowników testowych.
• 14. MFA dla WebAdmin Konsola i VPN Portal powinny być aktywne. Wartość domyślna: CIS, ważność: wysoka. Jest to szczególnie ważne, gdy do portali można dotrzeć z mniej ściśle kontrolowanych sieci.
• 15. Connections to Authentication Servers powinny być szyfrowane. Standard: CIS, ważność: średnia. W przypadku połączeń AD/LDAP/RADIUS należy unikać nieszyfrowanego uwierzytelniania.
• 17. Należy włączyć uwierzytelnianie kluczem publicznym dla SSH. Wartość domyślna: Zalecana, Ważność: Wysoka. Ponadto SSH powinno być dozwolone wyłącznie z zaufanych sieci.
• 18. User Portal nie powinien być osiągalny ze strefy WAN. Standard: Recommended, ważność: wysoka. Jeżeli dostęp WAN jest konieczny, powinien być mocno ograniczony i chroniony przez MFA.
• 19. WebAdmin Konsola nie powinna być dostępna ze strefy WAN. Wartość domyślna: CIS, ważność: wysoka. Jest to jeden z najważniejszych punktów. WebAdmin nigdy nie powinno być szeroko otwierane w Internecie.
• 20. Należy skonfigurować MFA dla domyślnego administratora. Wartość domyślna: CIS, ważność: wysoka. Ponadto wymagany jest czysty proces administracyjny z osobistymi kontami administratora.

Kopia zapasowa, aktualizacje, reguły i inspekcja

• 16. Kopie zapasowe należy zaplanować na zaporze lub w Sophos Central. Wartość domyślna: CIS, ważność: niska. Dotkliwość wydaje się niewielka, ale w sytuacji awaryjnej kwestia ta jest niezwykle ważna. Należy również przetestować proces przywracania.
• 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ść. Aktualizacje są domyślnie automatyczne, ale nadal trzeba kontrolować status i ostatnią udaną aktualizację. Firmware Access Pointów i urządzeń RED jest tylko pobierany i instalowany oddzielnie, ponieważ wymaga restartu. W środowiskach odizolowanych (Air Gap) potrzebny jest 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 sieciowej należy wybrać ochronę typu zero-day. Wartość domyślna: CIS, ważność: wysoka. Pasuje to do odpowiednich ścieżek sieciowych i pobierania. Należy wziąć pod uwagę licencję, wydajność i fałszywe alarmy.
• 25. Należy włączyć IPS i wybrać politykę IPS w regule zapory sieciowej. Wartość domyślna: CIS, ważność: wysoka. IPS jest ważnym punktem ochrony, ale musi zostać odpowiednio wybrany i zarejestrowany dla każdej ścieżki ruchu.
• 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 należy najpierw przetestować.
• 27. Reguła SSL/TLS Inspection powinna używać Action Decrypt. Wartość domyślna: CIS, ważność: wysoka. Nie należy aktywować TLS Inspection na ślepo, ponieważ konieczna jest dystrybucja urzędu certyfikacji, wyjątki, faza pilotażowa i proces 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. Any może być świadomie konieczne, ale musi być następnie uzasadnione i zarejestrowane.

Sophos Central 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. Wartość domyślna: CIS, ważność: niska. Bez prawidłowego czasu ucierpią dzienniki, certyfikaty, uwierzytelnianie i rozwiązywanie problemów.

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.

To zamówienie okazało się skuteczne:

1. Zaznacz opcję Zarządzanie z dostępem do Internetu i dostęp do portalu.
2. Sprawdź MFA i bezpieczeństwo logowania dla administratorów, VPN Portal, User Portal i dostęp zdalny.
3. Usuń reguły zapory sieciowej ze źródłami, miejscami docelowymi lub Services, które są zbyt ogólne.
4. Check logging, backups and hotfixes.
5. Sprawdź funkcje ochrony na regułę, na przykład IPS, Zasady sieciowe, Application Control, TLS Inspection lub Zero-Day Protection.
6. Oceń Centralny, Raportujący lub Wyniki NDR w oparciu o to, czy funkcja jest rzeczywiście używana i obsługiwana w środowisku.

Kolejność jest pragmatyczna: najpierw rzeczy, które są bezpośrednio widoczne w Internecie lub umożliwiają dostęp do zapory ogniowej. Następnie regularne funkcje higieniczne i ochronne. Następnie tematy operacyjne i ekosystemowe.

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, prób użycia siły i upchania poświadczeń. 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?
• Are there old test rules or temporary exceptions?
• Czy regułę można podzielić na kilka bardziej zrozumiałych reguł?

Podstawy znajdują się w regułach Sophos Firewall i skonfiguruj je poprawnie. 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, Polityki sieciowej, 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.

Dla TLS Inspection pasuje do Sophos Firewall TLS Inspection poprawnie wstaw. W przypadku kanałów zagrożeń pasuje Sophos Firewall Kanały zagrożeń.

Udokumentuj i zweryfikuj recenzję

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.

Zastąpienia nie powinny być błędnie rozumiane jako funkcja czyszcząca. Mają sens tylko wtedy, gdy wymóg jest świadomie spełniony w inny sposób lub jeśli istnieje kontrola kompensująca. Przykładem jest MFA: Jeśli środowisko wykorzystuje Microsoft Entra ID SSO z MFA jako obowiązkową kontrolę logowania, lokalne ustalenie MFA może zostać zastąpione z powodów technicznych, w zależności od projektu. Bez takiego uzasadnienia ryzyko pozostaje, nawet jeśli wyświetlacz kontroli stanu 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?
• Oprogramowanie sprzętowe: Jaka wersja SFOS została przetestowana?
• 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ę pod względem zawodowym lub technicznym?
• Data: Do kiedy działanie powinno zostać ukończone lub poddane ponownej ocenie?
• Dowód: Zrzut ekranu, zgłoszenie, zmiana identyfikatora lub notatka z dziennika audytu.

W przypadku wydajnych zapór ogniowych dowód nie powinien składać się tylko z zrzutu ekranu. Jeśli konfiguracja została zmieniona, bilet 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 Sophos Firewall Sprawdź dzienniki dziennika audytu.

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 na Dostęp do urządzenia 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 zmianie zasad Log Viewer przetestuj zasady i aplikacje, których to dotyczy.
• Po zarejestrowaniu lub zgłoszeniu zmian sprawdź, czy nowe zdarzenia są faktycznie widoczne lokalnie, w Sophos Central lub w Syslog.
• Ustaw ponowne przesłanie po zastąpieniu, aby wyjątek nie został trwale zapomniany.

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. Edytuj MFA, hasło i tematy sesji.
5. Zidentyfikuj ogólne reguły zapory sieciowej i zatwierdź 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 z datą, procesorem i punktami otwartymi.

W przypadku przeglądów cyklicznych często wystarczą pola Znalezienie, Ryzyko, Działanie, Osoba odpowiedzialna, Status i Ponowne przesłanie. Ważne jest, aby ustalenia nie były tylko przeglądane, ale przetwarzane i świadomie akceptowane.

Limity

Health Check jest pomocny, ale ma jasne ograniczenia.

• Nie zna pełnej logiki biznesowej środowiska.
• Nie sprawdza, czy reguła jest wymagana z technicznego punktu widzenia.
• 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.
• WAN sprawdź dostępność WebAdmin, SSH, User Portal i VPN Portal.
• 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.
• Dokumentowanie poprawki i procesu oprogramowania sprzętowego.
• Ustawiaj zastąpienia tylko z uzasadnieniem.
• Regularnie dokumentuj wyniki kontroli stanu.

Często zadawane pytania