Sophos Firewall Hardening: najlepsze praktyki bezpiecznej konfiguracji

Sophos Firewall hardening oznacza świadome zmniejszanie niepotrzebnej powierzchni ataku wokół samego firewalla i usług publikowanych przez firewall. Nie jest to jedno magiczne ustawienie, lecz powtarzalny proces operacyjny: ograniczyć dostęp administracyjny, wymusić MFA, utrzymywać firmware aktualny, przeglądać reguły, włączać funkcje ochronne i analizować logi.

Ten artykuł jest centralnym punktem wejścia. Nie zastępuje szczegółowych instrukcji, ale porządkuje najważniejsze best practices i odsyła do pasujących artykułów Avanet KB.

Co sprawdzić najpierw

W hardeningu kolejność ma znaczenie. Perfekcyjnie dostrojona polityka IPS niewiele pomaga, jeśli WebAdmin jest dostępny z WAN dla całego świata albo stary VPN Portal działa bez MFA.

Najważniejsze szybkie kontrole:

• Czy WebAdmin jest dostępny ze strefy WAN?
• Czy SSH jest dozwolony tylko z zaufanych sieci administracyjnych?
• Czy MFA jest aktywne dla administratorów, VPN Portal i Remote Access?
• Czy firmware, hotfixes i pattern updates są aktualne?
• Czy istnieją dostępy DNAT, WAF lub VPN, które nie są już potrzebne?
• Czy usługi publikowane mają IPS, WAF, Threat Feeds, logging i jasnego właściciela?
• Czy logi bezpieczeństwa są przechowywane niezależnie od firewalla i monitorowane, z określonym właścicielem i okresem przechowywania?
• Czy istnieje aktualny, przetestowany backup wraz z Secure Storage Master Key?

Zabezpieczyć dostęp administracyjny

Najważniejszym obszarem hardeningu jest dostęp do samego firewalla. WebAdmin, SSH, User Portal, VPN Portal, Captive Portal i usługi lokalne nie są zwykłymi regułami firewall, lecz lokalnymi usługami firewalla. Muszą być świadomie ograniczane przez Device Access i Local Service ACL.

Device Access i Local Service ACL

W Administration > Device access określa się dla każdej strefy, które usługi lokalne są osiągalne. Dla strefy WAN aktywne powinno być tylko to, co naprawdę potrzebne. Dostęp administracyjny i SSH zwykle nie powinny być szeroko wystawione do Internetu.

Jeśli administracja zdalna jest potrzebna, czystsze są te warianty:

• Zarządzanie przez Sophos Fusion (dawniej Sophos Central).
• Dostęp przez dedykowaną sieć administracyjną.
• Dostęp przez VPN lub ZTNA.
• Wąskie Local Service ACL Exception Rules dla stałych administracyjnych adresów źródłowych IP.

Konkretną konfigurację opisuje Zabezpieczanie dostępu do Sophos Firewall: prawidłowa konfiguracja Device Access. Jeśli potrzebny jest SSH, pomaga też Połączenie z Sophos Firewall przez SSH.

Podczas tworzenia wyjątku WAN trzeba uniknąć odcięcia własnego dostępu. Najpierw należy zalogować się niezależną drogą awaryjną przez konsolę, zarządzającą sieć LAN, administracyjny VPN lub Sophos Fusion i faktycznie ją przetestować. Następnie w Administration > Device access kliknąć Add pod Local service ACL exception rule. Przykład do dostosowania to WAN-Admin-203.0.113.10 z Rule position Top, IP version IPv4, Source zone WAN, stałym publicznym adresem IP administratora jako Source network / host, interfejsem WAN firewalla jako Destination host, Services HTTPS i tylko w razie potrzeby SSH oraz Action Accept. 203.0.113.10 jest adresem dokumentacyjnym i należy go zastąpić rzeczywistym stałym adresem administratora. Pozostawić obecną sesję otwartą, przetestować dostęp w drugiej sesji z tego źródła i dopiero potem usunąć szersze zezwolenie WAN dla HTTPS lub SSH w Local service ACL. Jeśli test się nie powiedzie, dotychczasowy dostęp pozostaje bez zmian; wyjątek trzeba poprawić przed zmianą zezwolenia strefy.

MFA, role i bezpieczeństwo logowania

VPN Portal nie służy tylko do pobierania: Klienty VPN i zmienione konfiguracje są udostępniane przez VPN Portal. SSO również wymaga utrzymania niezbędnej dostępności z WAN: Microsoft Entra ID SSO w SFOS 22 i OpenID Connect SSO w SFOS 23. Po pobraniu konfiguracji nie zamykać nadal potrzebnej ścieżki SSO. User Portal pozostaje wyłączony dla WAN; dostęp zdalny odbywa się przez VPN. Chronić VPN Portal odpowiednimi, możliwie wąskimi ACL, ważnym certyfikatem i monitorowaniem ataków brute force. Przy OIDC wymuszać MFA w IdP, nie przez dodatkowe OTP firewalla. Poniższe kroki lokalnego OTP dotyczą klasycznego uwierzytelniania, nie OIDC. Konfigurację opisują Entra VPN SSO i Google Workspace OIDC. Po zmianie ACL lub uwierzytelniania sprawdzić nowe logowanie i rzeczywisty tunel VPN z docelowej sieci zewnętrznej; przy błędach sprawdzić ACL, certyfikat i przypisanie przekierowań zamiast szeroko otwierać WAN.

MFA powinno być obowiązkowe dla administratorów i użytkowników Remote Access. Szczególnie krytyczne są lokalne konta admin, VPN Portal, User Portal i Remote Access VPN. MFA jest jednak tylko częścią hardeningu logowania. Równie ważne są imienne konta administratorów, jasne role, silne zasady haseł, ograniczone próby logowania i krótkie session timeouts.

Pozostawić CAPTCHA domyślnie włączone, szczególnie na stronach logowania dostępnych z WAN lub niezaufanych sieci. Nie zastępuje ono MFA ani Block login; błędne CAPTCHA nie liczy się jako nieudane logowanie dla tej blokady. Selektywna zmiana i przywracanie CAPTCHA opisuje uzasadniony, zatwierdzony wyjątek VPN dla WebAdmin lub User Portal. Najpierw zapisać zakres, cel i wartość początkową, sprawdzić dostęp i MFA, a po zmianie zweryfikować przez show i nowe logowanie zamierzoną ścieżką VPN. Rollback przywraca dokładnie zapisaną wartość; świadomy powrót do włączonej wartości domyślnej odbywa się przez enable. Globalne wyłączenie nie jest hardeningiem ani obejściem opisanej tam ograniczonej funkcjonalności SFOS 22.0 GA. Polecenia wyjątku nie dotyczą VPN Portal ani SPX Portal.

W SFOS 22 konfiguracja użytkowników znajduje się w Authentication > Multi-factor authentication (MFA). W One-time password (OTP) wybrać All users albo Specific users and groups, włączyć Generate OTP token with next sign-in dla tokenów aplikacyjnych i zaznaczyć każdą faktycznie używaną usługę w Require MFA for. Wbudowane konto admin zabezpiecza się oddzielnie w Administration > Device access > MFA for default admin. Przed wymuszeniem MFA co najmniej jedno imienne konto administratora powinno zarejestrować token; jego wydanie można sprawdzić w Issued tokens. Następnie przetestować nowe logowanie, pozostawiając obecną sesję admin jako drogę powrotu.

Praktyczną konfigurację opisuje Włączanie MFA dla Sophos Firewall WebAdmin, VPN Portal i Remote Access. Sposób współdziałania osobistych kont lokalnych, profili Device Access, źródeł logowania i offboardingu opisuje artykuł Bezpieczna konfiguracja administratorów i profili Sophos Firewall. Dla scenariuszy WAF z logowaniem użytkownika pasuje Zabezpieczanie Sophos Firewall WAF za pomocą MFA.

Sprawdzić autoryzację zdalnego dostępu VPN

Przyznawać dostęp VPN tylko użytkownikom i grupom, które go potrzebują, oraz wyłącznie do wymaganych zasobów. Nie wybierać w tym celu domyślnej grupy fallback Open group. Mogą do niej trafić użytkownicy bez pasującego przypisania grupy, na przykład podczas synchronizacji AD. Regularnie przeglądać członków i przypisywać ich do właściwych grup. Ta domyślna grupa nie jest ani regułą firewall fallback, ani celowo ograniczoną grupą fallback IdP z podlinkowanej instrukcji SSO. Mapowanie właściwe dla dostawcy pozostaje opisane tam. W odbiorze sprawdzić dozwolonego użytkownika, użytkownika fallback/nieprzypisanego oraz niedozwolony zasób: działać ma tylko zamierzony dostęp. Przy nieoczekiwanym powodzeniu poprawić przypisania grup i uprawnienia VPN/firewall, a następnie powtórzyć test.

Firmware, hotfixes i recovery

Firewall jest systemem brzegowym. Opóźnione aktualizacje nie są więc drobnym problemem, lecz prawdziwym oknem ataku. Jednocześnie aktualizacji nie wolno wykonywać na ślepo, ponieważ mogą dotknąć zdalne lokalizacje, klastry HA, VPN i produkcyjne reguły NAT.

Uczynić aktualizacje planowalnymi

Aktualizacje firmware powinny być przygotowane z backupem, oknem serwisowym, przeglądem release notes, planem HA i kryteriami rollback. Dostępne maintenance releases należy regularnie sprawdzać i po zatwierdzeniu niezwłocznie instalować. W aktualnych wersjach SFOS 22 strona WebAdmin Backup & Firmware > Firmware nie pokazuje już oddzielnej sekcji Hotfix. Funkcja hotfix nadal istnieje: Sophos domyślnie instaluje hotfixes automatycznie i zaleca, aby nie zmieniać tego ustawienia. Jeżeli trzeba sprawdzić status, użyć system hotfix show w Device Console. Hotfixes nie zastępują regularnego procesu aktualizacji. Proces opisuje Sophos Firewall firmware update: przygotowanie i best practices.

Strona przechowuje najwyżej dwie wersje firmware. Rollback uruchamia poprzednią wersję z odpowiadającą jej wcześniejszą konfiguracją; zmiany wprowadzone od przełączenia wersji zostają utracone. Od SFOS 19.0 MR1 zmiana firmware po trzech bezpłatnych aktualizacjach wymaga Enhanced Support lub Enhanced Plus; hotfixes nie wymagają tej subskrypcji wsparcia. Dlatego przed dalszymi zmianami po aktualizacji trzeba zweryfikować oczekiwany firmware, dostęp administracyjny, VPN i krytyczne publikacje.

Przy większych skokach wersji trzeba dodatkowo sprawdzić ścieżkę upgrade, licencję, platformę i znane ograniczenia. Pasuje tu Sprawdzenie Sophos Firewall przed upgrade do SFOS 22.

Sprawdzić backup i restore

Hardening nie kończy się na prewencji. Utwardzony firewall musi też dać się odtworzyć. Potrzebny jest aktualny backup, hasło backupu, Secure Storage Master Key, udokumentowana ścieżka dostępu po restore i test odbiorczy.

Szczegóły są w Tworzenie lub przywracanie backupu Sophos Firewall. Pełny pakiet recovery jest obowiązkowy szczególnie przed firmware update, migracją, reimage i wymianą sprzętu.

Szczególną migracją zgodności jest tryb FIPS 140-3 na Sophos Firewall: Jego aktywacja wykonuje reset fabryczny i wymaga w pełni zaplanowanej odbudowy z ustawieniami VPN i certyfikatów zgodnymi z FIPS.

Zmniejszyć powierzchnię ataku w regułach

Wiele ryzyk nie wynika z egzotycznych ataków, lecz ze zbyt szerokich reguł, starych wyjątków i usług publikowanych, za które nikt już naprawdę nie odpowiada.

NAT, WAF i usługi publikowane

Każda usługa publikowana przez DNAT lub WAF jest świadomie otwartym wejściem. Może być potrzebna, ale musi być zaplanowana wąsko: source, destination, service, kolejność NAT, reguła firewall, polityka IPS/WAF, logging, test i owner należą razem.

Nie publikować wewnętrznych usług RDP ani dostępu administracyjnego bezpośrednio w Internecie. VPN lub ZTNA to preferowana ścieżka zdalnego dostępu do systemów wewnętrznych i zdalnej administracji. Threat Feeds nie uzasadniają publicznej ekspozycji. Urządzenia IoT bez architektury proxy w chmurze, wymagające bezpośredniego dostępu przychodzącego przez NAT, wymagają zaplanowanej izolacji, zastąpienia lub wycofania, a nie stałego wystawienia do WAN. Samo proxy w chmurze również nie gwarantuje bezpieczeństwa. Przed zatwierdzonym wyłączeniem ustalić z właścicielem zależności, skutki operacyjne i wymaganą ciągłość usługi.

W konkretnym przeglądzie zinwentaryzować jedną istniejącą publikację RDP i jedno mapowanie NAT dla IoT: host docelowy, usługę, dozwolone źródła, identyfikatory reguł firewall/NAT, właściciela i rzeczywistą potrzebę zdalnego dostępu. Zaplanować migrację do VPN/ZTNA lub zatwierdzone wycofanie. Nieunikniona istniejąca publikacja pozostaje jedynie jawnie udokumentowanym, wąsko ograniczonym wyjątkiem przejściowym z odpowiednią polityką IPS, aktualnymi poprawkami, logowaniem, właścicielem i datą wygaśnięcia; nie jest równoważna VPN/ZTNA. Po migracji sprawdzić nowe dozwolone połączenia i celowo niedozwolony dostęp z zewnątrz: wymagana usługa działa zamierzoną ścieżką, a niepożądana publiczna osiągalność została usunięta. Przy błędach najpierw sprawdzić reguły, NAT, routing i ścieżkę zastępczą zamiast szeroko otwierać WAN.

Dla publikowanych serwerów pomagają Publikowanie serwera przez DNAT na Sophos Firewall i Zrozumienie NAT na Sophos Firewall. Jeśli publikowane są serwery web, lepszą podstawą jest Sophos Firewall WAF: bezpieczne publikowanie webserverów.

Reguły firewall i segmentacja

Reguły z Any jako source, destination lub service nie są automatycznie błędne, ale zawsze wymagają wyjaśnienia. W hardeningu ważne są pytania:

• Czy reguła jest nadal potrzebna?
• Czy logging jest aktywny?
• Czy istnieje dokładniejsza source lub destination?
• Czy reguła jest prawidłowo ustawiona przed szerszymi regułami?
• Czy sieci admin, serwerowe, klienckie, IoT, gościnne i backup są czysto rozdzielone?

Podstawy są w Zrozumienie i bezpieczna konfiguracja reguł Sophos Firewall. Do sprawdzenia konkretnej reguły pasuje Czyste testowanie reguły Sophos Firewall.

DMZ zamiast głównej sieci LAN: Serwery dostępne z Internetu powinny znajdować się w osobnym segmencie i strefie DMZ. Sprawdzić faktyczne przypisanie w Network > Zones i Network > Interfaces; sama nazwa VLAN lub strefy nie wymusza izolacji. W Rules and policies > Firewall rules domyślnie odmawiać połączeń DMZ do LAN, z jedynie jawnie wymaganymi, wąskimi wyjątkami. Przykład do dostosowania pozwala na WAN do serwera web w DMZ tylko przez HTTPS i sieć administracyjną do DMZ wyłącznie dla zatwierdzonej usługi admin, bez ogólnego dostępu z DMZ do LAN klientów. Hosty i usługi zastąpić własnymi zatwierdzonymi obiektami. Planowanie stref i interfejsów, w części o kierunkach dostępu przed tworzeniem reguł, wyjaśnia model. Sprawdzić dozwolony dostęp do aplikacji i odrzucone połączenia DMZ do LAN nowymi przepływami, oczekiwanym Rule ID i w razie potrzeby Packet Capture. Przy nieoczekiwanym dostępie najpierw sprawdzić kolejność, strefy, obiekty i szersze zezwolenia. Przed nowymi produkcyjnymi regułami blokowania web uwzględnić nierozstrzygnięte zastrzeżenie HTTP/HTTPS Drop w części Action i logowanie artykułu o regułach; nie obiecuje się tu uniwersalnej blokady web.

Internet tylko dla uwierzytelnionych użytkowników LAN: Włączyć Match known users w zamierzonej regule klienckiej i wybrać uprawnionych użytkowników/grupy po zapewnieniu wiarygodnego mapowania użytkownika na ruch. Część Match known users opisuje uwierzytelnianie i wymagania. Serwery, IoT i pozostały ruch bez logowania użytkownika wymagają osobnych, wąskich reguł; samo przypisanie IP nie jest uwierzytelnianiem. Żadna szeroka reguła fallback nie może zezwalać na ten sam ruch użytkowników bez kontroli tożsamości. Przetestować użytkownika uprawnionego oraz nieznanego/nieuprawnionego, porównując użytkownika, grupę, Rule ID i rzeczywisty dostęp z założeniami. Przy rozbieżnościach sprawdzić mapowanie, kolejność i fallback zamiast usuwać kryterium użytkownika.

Świadomie skonfigurować Security Heartbeat: Sama rejestracja do zarządzania nie izoluje skompromitowanych endpointów. Synchronized Security Heartbeat opisuje wymagania: Network Protection, zarządzany Sophos Endpoint z licencją, to samo konto zarządzania w chmurze i włączony Heartbeat. W odpowiednich regułach ustawić Minimum source HB permitted i w razie potrzeby dla wewnętrznych celów Minimum destination HB permitted; nie używać Heartbeat celu dla WAN. Green dopuszcza tylko Green, Yellow dopuszcza Green lub Yellow, a No restriction również Red i urządzenia bez Heartbeat. Świadomie sprawdzić osobne opcje Block clients with no heartbeat i Block request to destination with no heartbeat: urządzenia, które nigdy nie wysłały Heartbeat, są blokowane tylko po włączeniu obu opcji. Urządzenia bez Sophos Endpoint i Web Exceptions pomijające Policy checks uniemożliwiają ogólną gwarancję izolacji. Zaplanować zatwierdzony pilotaż z określonymi przypadkami statusu/braku Heartbeat, nowymi połączeniami i logami; nie wywoływać infekcji produkcyjnej jako testu. Jeśli oczekiwane ograniczenie nie działa, sprawdzić dopasowanie reguły, wymagania, status i wyjątki oraz wycofać tylko ostatnią zmianę. To kroki odbiorcze dla własnego środowiska, nie testy appliance wykonane tutaj.

Świadomie aktywować funkcje ochronne

Funkcje ochronne pomagają tylko wtedy, gdy pasują do reguły, ruchu i procesu operacyjnego. Aktywowane na ślepo powodują false positives, problemy z wydajnością lub zgłoszenia supportowe. Wyłączone pozostawiają niepotrzebną powierzchnię ataku.

IPS, Spoof Protection i DoS

IPS powinien być używany na przychodzącym niezaufanym ruchu oraz na istotnych przejściach wewnętrznych. Ważne są pasujące IPS Policies, logging, proces false positive i obserwacja wydajności. Wdrożenie opisuje Konfiguracja i bezpieczne testowanie Sophos Firewall IPS.

Spoof Protection i DoS Settings redukują nieprawdopodobne źródła i proste wzorce floodingu. Trzeba je testować ostrożnie, szczególnie przy VoIP, VPN, wysokim ruchu pakietowym lub specjalnym routingu. Pasuje Sprawdzenie Sophos Firewall Spoof Protection i DoS Settings.

Threat Feeds dla WAF i DNAT

Threat Feeds uzupełniają ochronę tylko dla potwierdzonego modułu i ścieżki ruchu. Od SFOS 22 udokumentowano dopasowywanie źródłowego IPv4 przychodzącego przekazywanego ruchu DNAT/WAF do MDR, NDR i Third-Party Threat Feeds. Dla usług lokalnych, takich jak VPN Portal, potwierdzonym dodatkowym zabezpieczeniem jest dopasowanie źródłowego IPv4 do obsługiwanych Third-Party Feeds; ta ścieżka nie przechodzi przez tranzytową regułę firewall. Wskaźniki domen/URL dotyczą odpowiedniego dopasowania celu ruchu wychodzącego, nie źródłowego IP przychodzącego logowania. Ścieżka DNS/IPS/Application Classification lub web/inspekcji TLS musi być właściwa; pełne ścieżki URL HTTPS wymagają odszyfrowania. Źródła IPv6 nie są objęte tą ochroną.

Nierozstrzygnięta granica X-Ops: Opis ATR i macierz ruchu SVG przeczą sobie w odniesieniu do niektórych kierunków dopasowania X-Ops, zwłaszcza celu i lokalnego źródła ruchu wychodzącego. Nie przenosić twierdzeń o MDR, NDR ani Third-Party Feeds na Sophos X-Ops, również dla DNAT/WAF i lokalnych portali. Do wiarygodnego wyjaśnienia nie polegać na spornych efektach: restrykcyjne ACL, reguły firewall/WAF, poprawki i MFA pozostają wymagane niezależnie od feedu. Moduł, kierunek, logi i rzeczywisty efekt sprawdzać tylko w zatwierdzonych, kontrolowanych testach. MDR Threat Feeds i podlinkowana niżej instrukcja NDR szerzej wyjaśniają tę granicę.

Monitor wykrywa i rejestruje dopasowania, lecz nie blokuje; Block musi być skonfigurowany dla zweryfikowanej ścieżki. Samo dopasowanie nie dowodzi blokowania ani kompletności logów. Sprawdzić odpowiedni log ATR/firewall/WAF wraz z rzeczywistym połączeniem; allowlista, obsługa false positives i odpowiedzialność pozostają potrzebne. Poniższe przykłady dotyczą tylko tych granic modułu i ścieżki.

Są szczególnie wartościowe dla:

• publicznych webserverów za WAF lub DNAT,
• jawnie zatwierdzonych, ograniczonych czasowo wyjątków przejściowych RDP, SSH lub admin podczas migracji do VPN/ZTNA; tylko jako dodatkowa ochrona w potwierdzonym module/ścieżce, nie jako zalecenie publicznej ekspozycji,
• VPN i portali z dużym szumem z Internetu,
• środowisk, gdzie blokowanie krajów jest zbyt ogólne,
• klientów, którzy oprócz Sophos X-Ops chcą używać kuratowanych feedów firm trzecich.

Liczy się eksploatacja: jakość feedu, akcja Monitor lub Block, allowlist, false positives, logging i odpowiedzialność muszą być jasne. Konfigurację opisuje Konfiguracja i bezpieczna eksploatacja Sophos Firewall Threat Feeds. Dla kuratowanych feedów Cybora może być sensownym elementem, szczególnie gdy usługi publikowane mają być konsekwentnie chronione przed znanymi złymi źródłami.

Web, DNS, TLS i Zero-Day Protection

Web Protection, DNS Protection, TLS Inspection i Zero-Day Protection zwiększają widoczność i skuteczność blokowania, ale wymagają dobrego planowania. TLS Inspection nie powinien startować jako projekt wszystko-albo-nic. DNS Protection musi pasować do używanych ścieżek DNS. Zero-Day Protection pomaga tylko wtedy, gdy odpowiednie typy plików i polityki są sensownie włączone.

Pasujące artykuły to Tworzenie Sophos Firewall Web Protection z Web Policies, Konfiguracja Sophos DNS Protection z Sophos Firewall, Prawidłowe wprowadzanie Sophos Firewall TLS Inspection i Zrozumienie i eksploatacja Sophos Firewall Zero-Day Protection.

Detekcja, logging i review

Hardening nie jest jednorazowym zadaniem projektowym. Reguły, użytkownicy, portale, wyjątki NAT i wersje firmware się zmieniają. Dlatego potrzebne są regularne przeglądy i logi dostępne zanim dojdzie do incydentu.

Health Check jako punkt startowy

Sophos Firewall Health Check jest dobrym punktem startowym, bo pokazuje ryzykowne konfiguracje. Findings nie powinny być wdrażane ślepo, ale oceniane według ryzyka, wpływu operacyjnego i lokalnej architektury.

W SFOS 22 otworzyć widget Firewall health check w Control Center albo przejść do Monitor & analyze > Firewall health check. Dane aktualizują się po zmianie monitorowanej konfiguracji. Ważne: finding można ręcznie oznaczyć jako compliant bez usunięcia jego przyczyny. Walidacja musi więc potwierdzać spełnienie wymagania policy, a nie tylko zmianę wyświetlanego statusu.

Dobre momenty na Health Check:

• po initial setup,
• po migracjach,
• przed i po firmware upgrades,
• po większych zmianach reguł,
• przed audytami,
• kwartalnie w eksploatacji.

Oddzielna ocena telemetrii i Sophos Assistant

W Administration > Admin and user settings opcja Sophos Adaptive Learning określa, jakie dane o użytkowaniu i zagrożeniach firewall wysyła do Sophos. Obejmuje to niesklasyfikowane aplikacje oraz dane o alertach IPS, wykrytych wirusach, spamie i wykryciach Active Threat Response. Podstawowe raportowanie danych o konfiguracji i użytkowaniu jest również domyślnie włączone: urządzenie okresowo przesyła przez HTTPS dane o konfiguracji, funkcjach, błędach i wykorzystaniu zasobów. Sophos deklaruje, że nie zbiera przy tym informacji dotyczących konkretnych użytkowników ani danych spersonalizowanych. Mimo to decyzję należy świadomie udokumentować zgodnie z wymaganiami prywatności i modelem eksploatacji, zamiast traktować tę opcję jako funkcję ochrony lokalnego ruchu.

Turn on Sophos Assistant dotyczy natomiast tylko tekstów pomocy, smart tips i przewodników konfiguracji w WebAdmin. Po zmianie ustawienia trzeba się wylogować i zalogować ponownie. Wyłączenie asystenta nie zmniejsza powierzchni ataku sieciowego ani automatycznie nie zatrzymuje telemetrii; oba ustawienia należy oceniać oddzielnie. Obsługę, weryfikację źródeł i ograniczenia procedur prowadzonych krok po kroku wyjaśnia artykuł Bezpieczne korzystanie z Sophos Assistant.

Logging, alerty i SIEM

Reguły firewall bez logowania są często bezużyteczne przy troubleshooting i incident response. Udokumentowana baza to centralne raportowanie w Sophos Fusion (dawniej Sophos Central) oraz wybrane rozwiązanie SIEM. Określić klasy zdarzeń, odbiorców, odpowiedzialnego właściciela, okres przechowywania i monitorowanie z procedurą reakcji. Każdy wyjątek architektoniczny jawnie udokumentować: musi zapewniać równoważną ścieżkę, przechowywaną niezależnie od firewalla i monitorowaną; nie każda architektura wymaga podwójnych miejsc docelowych. Sam regularny przegląd lokalnego Log Viewer nie wystarcza. MDR, XDR i NDR nie są zamiennymi archiwami logów. Zatwierdzonym, bezpiecznym zdarzeniem testowym sprawdzić dostarczenie do każdego zamierzonego celu, wyszukanie w przechowywanych logach i ścieżkę monitorowania/alarmowania. Gdy dostarczenie zawiedzie, poprawić wybór zdarzeń, łączność i odbiorców oraz powtórzyć test. Sprawdzić również retencję i uprawnienia w miejscu docelowym.

Dodatkowo w System services > Notification list wybrać wymagane zdarzenia systemowe dla e-mail lub SNMP. Najpierw skonfigurować cel poczty w Administration > Notification settings albo agenta SNMP oraz community lub użytkownika w Administration > SNMP. Po Save bezpieczne, kontrolowane zdarzenie powinno dotrzeć do zamierzonego odbiorcy; jeśli nie, najpierw sprawdzić cel e-mail lub SNMP, łączność i wybraną klasę zdarzeń.

Techniczną konfigurację Syslog opisuje Bezpieczne wysyłanie Sophos Firewall Syslog do SIEM. Dla raportów centralnych pasuje Aktywacja i eksploatacja Sophos Firewall Central Reporting. Jeśli istotne są NDR i Active Threat Response, pomaga Eksploatacja Sophos Firewall NDR i Active Threat Response.

Walidacja zmian i bezpieczny rollback

Hardening należy wdrażać małymi, możliwymi do prześledzenia krokami. Przed każdą grupą zmian zapisać bieżącą wartość, ownera i planowaną drogę powrotu. Następnie zmienić tylko jeden obszar, na przykład Device Access, regułę firewall lub akcję Threat Feed. Przetestować zarówno oczekiwaną dozwoloną ścieżkę, jak i celowo niedozwoloną, oraz sprawdzić odpowiednie logi. Dopiero potem przejść do kolejnego obszaru.

Przy rollbacku przywrócić tylko ostatnio zmienione ustawienie do udokumentowanej wartości początkowej. Przy zmianach Device Access zachować zarówno istniejącą sesję admin, jak i wcześniej przetestowaną niezależną drogę zarządzania. Nie usuwać poprzedniej reguły, zanim jej węższy zamiennik nie przejdzie walidacji. Threat Feeds uruchamiać najpierw z Monitor, sprawdzić trafienia i możliwe false positives, a dopiero potem przejść na Block; jeśli blokowanie powoduje problemy, wrócić do Monitor i dodać wyłącznie zweryfikowane wyjątki. Pełny restore backupu nie jest wygodnym przyciskiem Undo, lecz ścieżką recovery dla większych awarii.

Kompaktowa checklista hardeningu

Do pierwszego przeglądu użyć tej kolejności:

1. Ograniczyć dostęp WAN do WebAdmin i SSH, pozostawić User Portal wyłączony oraz zachować i sprawdzić VPN Portal wymagany do pobierania i SSO.
2. Włączyć MFA dla adminów i Remote Access.
3. Oczyścić lokalne konta admin, role i zasady haseł.
4. Sprawdzić firmware, hotfixes, pattern updates i status supportu.
5. Udokumentować backup, SSMK, ścieżkę restore i test recovery.
6. Sprawdzić zasadność publikacji DNAT, WAF i VPN; ograniczyć grupy/zasoby VPN, nie autoryzować Open group oraz przetestować dostęp dozwolony i odrzucony.
7. Oczyścić reguły z Any, bez loggingu albo bez jasnego ownera.
8. Celowo aktywować IPS, Spoof Protection, DoS Settings i Threat Feeds.
9. Wprowadzać Web, DNS, TLS i Zero-Day Policies etapami.
10. Ustanowić Health Check, niezależnie przechowywane i monitorowane logi, testy dostarczenia, alerty i regularne przeglądy z właścicielem i okresem retencji.

Częste błędy

Dostęp WAN zostaje otwarty dla wygody

Dostęp WebAdmin lub SSH jest otwierany dla support case i potem zapomniany. Takie tymczasowe wyjątki powinny mieć datę wygaśnięcia, ownera i kontrolę po zakończeniu.

Threat Feeds są aktywowane bez koncepcji operacyjnej

Threat Feeds są silne, ale nie bezobsługowe. Bez monitoringu, allowlisty i procesu false positive można zablokować legalnego partnera, dostawcę lub usługę cloud. Najpierw testować z Monitor albo ograniczonym zakresem, potem przejść czysto na Block.

Brakuje loggingu na krytycznych regułach

Jeśli publiczna reguła DNAT, WAF lub VPN nie loguje, w incydencie widać zbyt mało. Co najmniej wejścia security-relevant, dostępy admin, reguły deny i krytyczne przejścia segmentów powinny być śledzalne.

Health Check jest traktowany jako jednorazowe zadanie

Dobry wynik po setupie nie jest stanem trwałym. Nowe reguły, nowi użytkownicy VPN, tymczasowe wyjątki i zmiany firmware mogą zmienić sytuację. Hardening potrzebuje rytmu review.

FAQ