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 centralnie albo przynajmniej regularnie sprawdzane?
- 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 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.
MFA, role i bezpieczeństwo logowania
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.
Praktyczną konfigurację opisuje Włączanie MFA dla Sophos Firewall WebAdmin, VPN Portal i Remote Access. Dla scenariuszy WAF z logowaniem użytkownika pasuje Zabezpieczanie Sophos Firewall WAF za pomocą MFA.
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. 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.
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.
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.
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.
Ś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 są bardzo sensownym uzupełnieniem, gdy usługi są osiągalne przez WAF, DNAT, VPN Portal lub inne publiczne wejścia. Mogą wcześniej blokować znane złośliwe adresy IP, domeny lub URL, zanim dotrą do aplikacji albo reguły.
Są szczególnie wartościowe dla:
- publicznych webserverów za WAF lub DNAT,
- dostępów RDP, SSH lub admin, które nie zostały jeszcze zastąpione przez ZTNA,
- 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.
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.
Logging, alerty i SIEM
Reguły firewall bez logowania są często bezużyteczne przy troubleshooting i incident response. Do dłuższego przechowywania lokalny Log Viewer zwykle nie wystarcza. W zależności od środowiska sensowne są Sophos Central Reporting, Syslog, SIEM, MDR, XDR lub NDR.
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.
Kompaktowa checklista hardeningu
Do pierwszego przeglądu użyć tej kolejności:
- Sprawdzić dostęp WAN do WebAdmin, SSH, User Portal i VPN Portal.
- Włączyć MFA dla adminów i Remote Access.
- Oczyścić lokalne konta admin, role i zasady haseł.
- Sprawdzić firmware, hotfixes, pattern updates i status supportu.
- Udokumentować backup, SSMK, ścieżkę restore i test recovery.
- Sprawdzić zasadność publikacji DNAT, WAF i VPN.
- Oczyścić reguły z
Any, bez loggingu albo bez jasnego ownera. - Celowo aktywować IPS, Spoof Protection, DoS Settings i Threat Feeds.
- Wprowadzać Web, DNS, TLS i Zero-Day Policies etapami.
- Ustanowić Health Check, Syslog, alerty i regularne review jako proces operacyjny.
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.