Sophos Firewall: dobre praktyki bezpieczeństwa sieci

Przez długi czas firewalle były miejscem, w którym odpierało się ataki. Dziś same należą do najatrakcyjniejszych celów. To logiczne: firewall znajduje się w uprzywilejowanej pozycji pomiędzy Internetem, sieciami lokalizacji, usługami cloud, dostępem VPN i aplikacjami wewnętrznymi. Kto znajdzie tutaj podatność, słabe hasło albo błędną konfigurację, nie stoi już przed drzwiami, ale często jest już w środku budynku.

Dlatego nie wystarczy już traktować firewalla tylko jako silnika policy dla reguł Allow i Deny. Nowoczesne bezpieczeństwo sieci potrzebuje trzech filarów: hardening, protection oraz detection and response. Trzeba ograniczyć powierzchnię ataku przed atakiem, czysto blokować w jego trakcie i szybko rozpoznać, co się wydarzyło.

Od wielu lat pracuję z środowiskami Sophos Firewall o bardzo różnych rozmiarach i w różnych branżach. Poniższe rekomendacje nie są więc teoretyczną listą funkcji, lecz tym, co wielokrotnie sprawdza się w realnych środowiskach klientów, migracjach, audytach i przypadkach supportowych.

Dlaczego firewalle są tak mocno na celowniku

Firewall jest dla atakujących wartościowym celem, ponieważ jest wystawiony, uprzywilejowany i często krytyczny dla biznesu. Do tego wiele środowisk przez lata utrzymuje firewalle, portale VPN albo zdalny dostęp administracyjny. Nie każde środowisko jest poprawnie patchowane, nie każda powierzchnia zarządzania jest naprawdę odizolowana i nie każde logowanie jest chronione multi-factor authentication.

W praktyce w udanych atakach powtarzają się przede wszystkim trzy przyczyny:

• Podatności w firewallach i systemach edge, szczególnie gdy patche są instalowane z opóźnieniem albo wcale.
• Skompromitowane dane logowania i ataki na tożsamość, często bez MFA lub ze słabą konfiguracją MFA. Sophos Active Adversary Report 2026 wskazuje przyczyny związane z tożsamością jako root cause w 67.32% analizowanych przypadków.
• Wystawione systemy, na przykład RDP, portale VPN, User Portals albo interfejsy admina dostępne bezpośrednio z Internetu.

Najważniejsza myśl jest taka: wiele ataków nie jest dziś spektakularnym “włamaniem”. Bardzo często atakujący po prostu się logują. Jeśli konto użytkownika, hasło admina albo dostęp VPN są skompromitowane, pierwszy krok wygląda dla firewalla początkowo jak legalne użycie.

Trzy filary nowoczesnego bezpieczeństwa sieci

Sophos opisuje ochronę nowoczesnych sieci jako spektrum od proaktywnej do reaktywnej:

1. Hardening: ograniczanie powierzchni ataku, usuwanie przestarzałych systemów, używanie bezpiecznych produktów, sprawdzanie konfiguracji i ograniczanie dostępu.
2. Protection: blokowanie ataków, kontrola ruchu szyfrowanego oraz sensowne użycie funkcji Web, IPS, Zero-Day i Application Control.
3. Detection and Response: wykrywanie anomalii, izolowanie skompromitowanych urządzeń, korelowanie danych o zagrożeniach i automatyczna reakcja.

Wiele firewalli tradycyjnie jest mocnych w drugim filarze. Blokują ruch, sprawdzają pakiety, rozpoznają znane wzorce i egzekwują policies. To ważne, ale już niewystarczające. Jeśli sam firewall jest źle skonfigurowany, Remote Access działa bez MFA albo niezałatany system pozostaje produkcyjny, pojawia się problem strukturalny, którego nie rozwiąże pojedyncza reguła IPS.

Moje doświadczenie pokazuje, że najlepsze rezultaty nie powstają dzięki jednej magicznej funkcji, ale dzięki czystej konfiguracji bazowej, regularnym przeglądom i firewallowi włączonemu w szerszy proces bezpieczeństwa.

Filar 1: Hardening przed atakiem

Hardening to część pracy security, która rzadko dostaje brawa, ale w sytuacji incydentu robi różnicę. Chodzi o mniejszą powierzchnię ataku, mniej starych systemów, mniej otwartych ścieżek zarządzania i mniejszą zależność od reakcji manualnych.

Ograniczać infrastrukturę i usuwać stare systemy

Najprostszy sposób na zmniejszenie powierzchni ataku bywa najtrudniejszy: wyłączyć rzeczy. Każda stara appliance, zapomniana usługa VPN, portal zarządzania i niewspierany serwer to dodatkowy punkt ataku. Szczególnie krytyczne są systemy na brzegu sieci albo takie, które pośrednio umożliwiają uprzywilejowany dostęp do sieci wewnętrznych.

Dla adminów Sophos Firewall oznacza to konkretnie:

• Regularnie sprawdzać, które firewalle, REDs, bramy VPN, kontrolery WLAN, reverse proxies i komponenty Remote Access są jeszcze produkcyjne.
• Usuwać systemy end-of-life albo end-of-support z uprzywilejowanych pozycji.
• Konsolidować funkcje, gdy zmniejsza to złożoność: firewall, SD-WAN, DNS Protection, ZTNA, Threat Feeds, reporting i central management powinny być możliwie czysto skoordynowane.
• Dokumentować, które usługi naprawdę muszą być dostępne z Internetu.

Celem nie jest włożenie jak największej liczby funkcji do jednego produktu. Celem jest unikanie niewidocznego legacy. Mała, aktualna i dobrze kontrolowana infrastruktura jest prawie zawsze bezpieczniejsza niż duże, historycznie narosłe środowisko z wieloma wyjątkami typu “tak zawsze było”.

Konsekwentnie zabezpieczać dostęp administracyjny

Jedna z najważniejszych best practices jest prosta: Web Admin Console i User Portal nie powinny być niepotrzebnie dostępne z WAN. Jeśli administracja zdalna jest konieczna, powinna odbywać się przez Sophos Central, dedykowaną sieć zarządzania, ZTNA albo inną kontrolowaną ścieżkę.

W środowiskach klientów wciąż widzę, że problemem nie jest najbardziej skomplikowana technika ataku, ale stary dostęp admina, historycznie narosły portal albo “tymczasowy” wyjątek, którego nigdy nie usunięto. Właśnie takie miejsca należą do regularnego firewall review.

W każdym środowisku Sophos Firewall należy sprawdzić następujące punkty:

• Aktywować MFA dla administratorów, szczególnie dla domyślnego admina i wszystkich kont z szerokimi uprawnieniami.
• Wymusić MFA dla logowań VPN i portali, jeśli takie dostępy są jeszcze używane.
• Unikać dostępu WAN do Admin Console i User Portal albo mocno ograniczyć go do dedykowanych sieci źródłowych.
• Skonfigurować silne reguły haseł dla użytkowników i administratorów.
• Zabezpieczyć SSH, najlepiej z public-key authentication i bez szerokiej dostępności WAN.
• Aktywować centralne backupy i chronić dostęp do backupów, ponieważ backupy konfiguracji mogą zawierać wrażliwe informacje.
• Aktywować powiadomienia i logging, aby zdarzenia istotne dla bezpieczeństwa nie ginęły w codziennej eksploatacji.

Backupy są często niedoceniane. Backup firewalla zawiera nie tylko niewinne ustawienia, ale informacje o sieciach, regułach, certyfikatach, VPNs i strukturach wewnętrznych. Dlatego backupy muszą być szyfrowane, przechowywane w kontrolowany sposób i regularnie testowane.

Świadomie ustawiać Device Access i Local Service ACL

Gdy mówi się o dostępie WAN, w Sophos Firewall trzeba konkretnie mówić o Device Access i Local Service ACL. W macierzy Device Access strefowo definiuje się, które lokalne usługi firewalla są dostępne: HTTPS admin, User Portal, SSH, ping, DNS, Captive Portal, portale VPN i inne usługi.

Best practice jest tu prosta, ale skuteczna: ze strefy WAN dostępne powinno być tylko to, co naprawdę potrzebne. Dostęp admina, SSH i User Portal nie powinny być szeroko wystawione do Internetu. Jeśli wyjątki są konieczne, należy ograniczać je przez Local Service ACL Exception Rules do konkretnych adresów IP źródłowych albo sieci zarządzania.

Reguły krajów jako minimalna ochrona

Jeśli stałe adresy IP źródłowe nie są realistyczne, rekomenduję przynajmniej pracę z regułami krajów. Dostęp tylko z kilku istotnych krajów jest nadal znacznie lepszy niż dostępność globalna. Alternatywnie można blokować kraje, z którymi firma nie ma związku i w których pracownicy albo admini zwykle nie przebywają. To nie zastępuje MFA, silnych ról i czystych ACLs, ale ogranicza niepotrzebny szum i wiele automatycznych prób dostępu.

Z mojego punktu widzenia jest to jeden z pierwszych punktów w każdym firewall review. Wiele ryzykownych konfiguracji nie wynika ze złej woli, lecz z tego, że usługa została chwilowo otwarta do migracji, supportu albo testu i nigdy nie została zamknięta. Właśnie takie szczegóły odróżniają firewall, który po prostu działa, od firewalla naprawdę dobrze eksploatowanego.

Sprawdzać Login Security i role adminów

MFA jest ważne, ale warstwa logowania to więcej niż drugi faktor. Administratorzy powinni używać własnych, śledzalnych kont i nie pracować stale na współdzielonym full admin. Uprawnienia oparte na rolach pomagają oddzielić dostęp supportu, reportingu albo helpdesku od właściwej administracji firewall.

Dodatkowo należy ograniczać nieudane próby logowania, czysto kończyć sesje i ograniczać dostęp admina do zdefiniowanych sieci. Login disclaimer może mieć sens prawny w niektórych środowiskach, ale nie zastępuje prawdziwych kontroli technicznych. Ważniejsze są silne polityki haseł, krótkie sesje nieaktywne, ochrona brute-force i least privilege.

Unikać patch fatigue: Hotfixes muszą działać szybko

Patching to jeden z tematów, w których teoria i praktyka mocno się rozchodzą. Oczywiście każdy admin wie, że aktualizacje firmware są ważne. W rzeczywistości oznaczają jednak okna serwisowe, ocenę ryzyka, planowanie HA, komunikację z działami biznesowymi i czasem downtime. To prowadzi do patch fatigue: updates są odkładane, bo wymagają wysiłku.

Właśnie tu czynnik czasu staje się niebezpieczny. Ataki tożsamościowe są obecnie dominującą root cause, ale wykorzystanie podatności pozostaje realnym wektorem, szczególnie przy systemach edge takich jak firewalle, VPNs i inne usługi blisko Internetu. Sophos Active Adversary Report 2026 podaje jako przykład CVE-2024-40766 w SonicOS, widoczną w dużej części potwierdzonych przypadków exploitacji w zbiorze danych. Jednocześnie mediana czasu między advisory albo patchem producenta a zaobserwowaną exploitacją wynosiła 322 dni. To jasny sygnał: patch fatigue nie jest abstrakcyjnym problemem operacyjnym, lecz oknem ataku.

Sophos Firewall robi tu ważny krok: Automated Hotfixes umożliwiają security-relevant live patches bez klasycznego okna serwisowego. Dla adminów to bardzo wartościowe, ponieważ krytyczny efekt ochronny nie czeka na następne wolne okno.

Mimo to Hotfixes nie zastępują czystej strategii update. Zamykają niebezpieczną lukę między odkrytą podatnością a regularnym firmware upgrade. Best practice brzmi więc:

• Pozostawić Hotfixes aktywne.
• Regularnie sprawdzać wersje firmware i dokumentować przygotowanie firmware update.
• Wcześniej czytać ścieżki upgrade i kompatybilność.
• Przygotować backupy i plan rollback.
• Osobno planować klastry HA i lokalizacje zdalne.

Nie traktować VPN jako dowodu zaufania

Remote Access VPN był standardem przez lata. Problem: klasyczny VPN myśli często w sieciach, nie w aplikacjach. Kto połączy się poprawnie, z perspektywy wielu środowisk znajduje się już w zaufanym obszarze. Jeśli endpoint jest skompromitowany albo dane logowania zostały skradzione, atakujący może poruszać się dalej.

Zero Trust Network Access (ZTNA) nie rozwiązuje tego magią, ale lepszą zasadą: Trust nothing, verify everything. Dostęp nie jest przyznawany szeroko do sieci, lecz oceniany per użytkownik, urządzenie, stan i aplikacja. Urządzenie musi być zdrowe i compliant, tożsamość musi być zweryfikowana, a policy decyduje granularnie, która aplikacja jest dostępna.

ZTNA nie jest automatycznie decyzją Sophos

Ważne jest to: ZTNA nie jest decyzją, która automatycznie musi oznaczać Sophos ZTNA. W zależności od środowiska wyspecjalizowani dostawcy ZTNA, SSE albo SASE mogą być funkcjonalnie dalej, oferować lepsze integracje albo lepiej pasować organizacyjnie. Decydująca nie jest nazwa producenta, lecz to, czy tożsamość, posture urządzenia, dostęp aplikacyjny, logging i operacja współgrają czysto.

To także moja ogólna postawa w projektach Sophos: nie wybieram automatycznie Sophos w każdym temacie. Jeśli rozwiązanie third-party dla ZTNA, SSE, Threat Intelligence, SIEM albo NDR pasuje technicznie lepiej, to właśnie ono jest lepszą rekomendacją. Dobra architektura security nie powstaje z maksymalnego vendor lock-in, ale z dobrze zintegrowanych komponentów z jasną odpowiedzialnością.

W czystych środowiskach Sophos integracja może mimo wszystko być interesująca, ponieważ ZTNA, Endpoint, Firewall i Sophos Central mogą być używane razem. Skompromitowane albo niezgodne urządzenie może stracić dostęp bez tego, by admin musiał najpierw ręcznie przebudowywać reguły firewalla. Warto też spojrzeć na ZTNA Gateway na Sophos Firewall. W środowiskach mieszanych albo większych trzeba jednak świadomie porównać opcje i nie ustawiać automatycznie istniejącego producenta firewalla jako platformy ZTNA.

Kto nadal mocno polega na SSL VPN albo IPsec Remote Access, powinien sprawdzić przynajmniej te punkty:

• Wymusić MFA dla każdego dostępu Remote Access.
• Usunąć starych albo nieużywanych użytkowników VPN.
• Kontrolować import grup z AD albo Entra ID, aby Remote Access nie został aktywowany niezamierzenie.
• Ograniczyć Split-Tunnel, dozwolone sieci i uprawnienia do minimum.
• Zaplanować etapową migrację do odpowiedniego rozwiązania ZTNA, SSE albo SASE, szczególnie dla wewnętrznych web apps, RDP, SSH, portali administracyjnych i aplikacji biznesowych.

Segmentacja przeciw Lateral Movement

Gdy atakujący wchodzą z ważnymi credentials albo przez wystawioną usługę, segmentacja wewnętrzna decyduje, jak daleko mogą się poruszać. Firewall nie powinien więc być tylko bramą perymetryczną, ale czysto oddzielać strefy wewnętrzne: użytkowników, serwery, management, IoT, sieć gościnną, produkcję, backup i szczególnie krytyczne systemy nie należy ślepo wrzucać do tego samego modelu zaufania.

Praktycznie oznacza to budowanie VLANs i stref nie tylko dla porządku, ale zabezpieczanie ich prawdziwymi regułami firewall. Między sieciami użytkowników i serwerów powinny być dozwolone tylko potrzebne aplikacje. Dostępy management należą do dedykowanych sieci admin. Sieci IoT i drukarek nie powinny swobodnie rozmawiać z serwerami. Backups i domain controllers zasługują na szczególnie restrykcyjne reguły i dobry logging.

Tu zamyka się pętla z tezą “atakujący logują się”. Jeśli skompromitowane konto ma dostęp do jednej aplikacji, ale nie do całej sieci, incydent nie staje się automatycznie pełną kompromitacją.

W nowych projektach planuję więc segmentację możliwie wcześnie. Później nadal jest możliwa, ale wyraźnie trudniejsza, bo trzeba najpierw rozplątać aplikacje, wyjątki i historyczne zależności.

Uwidaczniać błędne konfiguracje

Firewall może być technicznie bardzo mocny, a mimo to stać się niebezpieczny przez złą konfigurację. Zbyt szerokie reguły, obiekty “Any”, słaba autentykacja, brakujące IPS policies, wyłączone pattern updates albo otwarte portale to typowe przykłady. Trudność polega na tym, że w narosłych środowiskach takie ryzyka nie zawsze widać od razu.

Sophos Firewall Health Check adresuje dokładnie ten problem. Sprawdza dziesiątki ustawień względem best practices i benchmarks oraz pokazuje w Control Center, gdzie konfiguracje są ryzykowne albo odbiegają od zalecanych standardów. Wyniki są priorytetyzowane według ryzyka, prowadzą bezpośrednio do dotkniętych ustawień i w zależności od sytuacji mogą zostać naprawione albo świadomie nadpisane.

Health Check jest szczególnie przydatny w powtarzalnych procesach operacyjnych:

• po nowym firewall rollout,
• po większych zmianach reguł,
• przed i po firmware upgrades,
• przed audytami,
• po migracjach ze starego hardware,
• jako regularny kwartalny check.

Ważne jest jednak też to: Health Check nie zwalnia adminów z myślenia. Nie każda rekomendacja pasuje do każdego środowiska. Niektóre punkty mają powody compliance albo operacyjne, inne są jasnymi lukami bezpieczeństwa. Decydujące jest świadome ocenianie odchyleń i niedopuszczanie do ich niezauważonego wzrostu.

Z mojego punktu widzenia Health Check jest szczególnie mocny jako bieżące narzędzie operacyjne. To nie tylko coś na pierwszy go-live, ale dobry punkt startowy do kwartalnych reviews, przygotowania audytu i czyszczenia starych zestawów reguł.

Secure by Design: utwardzać sam firewall

Z mojego punktu widzenia potrzebujemy nie tylko produktów security, ale bezpiecznych produktów security. To ważna różnica. Firewall nie może tylko blokować ataków na inne systemy, ale musi być sam utwardzony przeciwko atakom.

W Sophos Firewall obejmuje to kilka poziomów:

• Utwardzony kernel i zmodernizowana architektura: nowsza architektura Xstream mocniej stawia na izolację, modularność, konteneryzację i separację uprawnień. Dzięki temu ograniczane są pewne klasy podatności, a skutki są redukowane przez lepszą izolację. Dochodzą mitigations przeciw podatnościom side-channel i CPU. To czyni platformę bardziej odporną, ale nie odporną na wszystkie podatności.
• Automated Hotfixes: poprawki bezpieczeństwa mogą być dystrybuowane bardzo szybko i bez klasycznego okna serwisowego.
• Remote Integrity Monitoring: zintegrowany Sophos XDR Linux Sensor może monitorować integralność systemu w czasie rzeczywistym, na przykład nieautoryzowane zmiany konfiguracji, Rule Exports, podejrzane uruchamianie programów albo File Tampering. Wartościowe jest to tylko wtedy, gdy funkcja jest aktywna, licencjonowana, podłączona i monitorowana w operacji.
• Bezpieczne zarządzanie Central: administracja może odbywać się przez Sophos Central bez szerokiego wystawiania portów management do Internetu.
• Health Check: ryzykowne konfiguracje stają się bezpośrednio widoczne.
• Szyfrowane backupy: dane konfiguracyjne są przesyłane i przechowywane w sposób chroniony.

Dodatkowo Sophos stawia na proaktywne monitorowanie zainstalowanej bazy firewalli. Telemetria z firewalli może pomóc wcześniej rozpoznać sygnały ataków albo manipulacji. Gdy wzorzec staje się widoczny, Sophos może celowo wesprzeć klientów albo partnerów i szybko szeroko wdrożyć Hotfixes.

Te punkty są w codzienności mniej spektakularne niż nowa reguła firewalla albo zablokowany atak w logu. Długoterminowo są jednak decydujące. Utwardzony produkt zmniejsza prawdopodobieństwo, że sam firewall stanie się punktem wejścia. Nie zastępuje jednak czystego procesu patch, monitoringu ani regularnej kontroli konfiguracji.

Czego oczekiwać od producenta firewalli

Secure by Design to nie tylko właściwość produktu, ale też kwestia producenta. Klienci powinni oczekiwać, że producenci transparentnie obsługują podatności, jasno komunikują lifecycle information, szybko wdrażają security fixes i budują produkty tak, aby błędne konfiguracje oraz skompromitowane komponenty były widoczne możliwie wcześnie.

Odpowiedzialność jest dzielona. Producenci muszą dostarczać bezpieczne produkty i reagować transparentnie. Klienci muszą instalować updates, zastępować systemy EOL, używać MFA i regularnie sprawdzać operację. Jedno należy do drugiego.

Filar 2: Protection podczas ataku

Hardening jest bazą. Potem firewall musi nadal robić to, do czego jest używany: kontrolować ruch i blokować ataki. W Sophos Firewall obejmuje to między innymi IPS, Web Protection, Application Control, Zero-Day Protection, TLS Inspection, DNS Protection oraz Threat Intelligence Feeds.

Sophos mocno opiera się tu na architekturze Xstream. Zaufany ruch może być przetwarzany efektywniej, zadania obliczeniowo ciężkie jak crypto operations przechodzą optymalnymi ścieżkami, a dla ruchu o wyższym ryzyku zostaje więcej rezerwy wydajności na Deep Packet Inspection, TLS Inspection i Zero-Day Protection.

TLS Inspection jest dobrym przykładem równowagi między bezpieczeństwem a operacją. Bez deszyfrowania duża część nowoczesnego ruchu pozostaje niewidoczna. Przy źle zaplanowanych regułach TLS powstają jednak przypadki supportowe, problemy z certyfikatami albo wąskie gardła wydajności. Best practice nie brzmi więc “odszyfrować wszystko na ślepo”, lecz czysto klasyfikować:

• najpierw krytyczne grupy użytkowników i serwery,
• czysto wyłączyć banking, health, privacy i znane problematyczne kategorie,
• testować strony blokad i ostrzeżeń,
• dokumentować dystrybucję certyfikatów,
• aktywnie analizować logi.

Moja rekomendacja: nie zaczynać TLS Inspection jako projektu wszystko-albo-nic. Lepszy jest czysty rollout z jasnymi grupami użytkowników, wyjątkami, oknami testowymi i analizą logów. Widoczność rośnie, ale helpdesk nie zostaje zalany pierwszego dnia.

Threat Feeds również należą do tego obszaru ochrony. Takie feeds pomagają blokować znane złośliwe IPs, domeny albo URLs bezpośrednio na granicy sieci. W nowszych wersjach Sophos Firewall są znacznie mocniej zintegrowane z Active Threat Response i mechanizmami ochrony.

Threat Feeds stają się szczególnie interesujące, gdy nie używa się tylko list generycznych, ale kuratorowanych third-party feeds z aktualnym kontekstem. Przykładem jest Cybora.io, gdzie złośliwe IPs i domeny z różnych źródeł oraz telemetrii firewalli są łączone w użyteczne feeds. Jak takie feeds można stosować na firewallach, opisałem szerzej w artykule Threat Intelligence Feeds dla firewalla.

Tutaj również obowiązuje zasada: Threat Feeds muszą być testowane i obserwowane. Zbyt agresywne feeds, brak procesów allowlist albo niejasne odpowiedzialności mogą blokować legalny ruch i w operacji wyrządzić więcej szkody niż pożytku. Dobre feeds nie zastępują przeglądu reguł, lecz są dodatkowym komponentem z własnym tuningiem.

Nie należy też zapominać o klasycznych elementach hardeningu SFOS: Spoof Protection, odpowiednie ustawienia DoS i Geo-IP-Blocking mogą ograniczyć proste, głośne albo oczywiście niechciane dostępy. Nie zastępuje to czystej policy, ale usuwa z firewalla niepotrzebny szum i blokuje ścieżki ataku, które w wielu środowiskach nie mają legalnego celu.

Rekomenduję tu pragmatyczne podejście: najpierw czysto kontrolować największe ryzyka, potem stopniowo zaostrzać funkcje ochrony i logami udowadniać, co naprawdę działa. Przeładowana policy, której nikt już nie rozumie, nie jest długoterminowym zyskiem bezpieczeństwa.

Filar 3: Detection and Response po pierwszym sygnale

Najciekawszą częścią nowoczesnego bezpieczeństwa sieci jest reakcja. Firewall nie powinien działać w izolacji, ale korzystać z sygnałów z Endpoint, Server, NDR, MDR, XDR i Threat Intelligence. Sophos może tu wykorzystać zalety ekosystemu, ale tylko wtedy, gdy te integracje naprawdę pasują do środowiska.

Ekosystemy pomagają tylko wtedy, gdy pasują

Synchronized Security i Security Heartbeat to dobre pomysły: firewall może uwzględniać stan endpoints i ograniczać albo blokować komunikację urządzeń skompromitowanych. W rzeczywistości jednak coraz więcej firm używa Microsoft Defender albo innych rozwiązań endpoint. Wtedy ta część ekosystemu Sophos działa tylko częściowo albo wcale. Właśnie dlatego nie należy automatycznie brać wszystkiego od jednego producenta tylko dlatego, że jest oferowane jako zintegrowany ekosystem.

Moja rekomendacja jest tu jasna: decydujące jest to, co pasuje do firmy i można czysto wdrożyć. Jeśli Microsoft Defender, inne EDR, third-party NDR albo zewnętrzne SIEM są lepszą bazą, firewall powinien być czysto zintegrowany z tą architekturą. Ważniejsze niż cross-selling jest to, aby logi trafiały we właściwe miejsce, alerty były rozumiane i ktoś regularnie sprawdzał, co systemy zgłaszają. Bez analizy logów, tuningu i procesu incident nawet najlepsza integracja pomaga niewiele.

Z Active Threat Response wykryte zagrożenia mogą być automatycznie tłumaczone na decyzje sieciowe. A dzięki NDR Essentials firewall zyskuje dodatkową widoczność podejrzanego ruchu sieciowego, także tam, gdzie nie ma klasycznego endpoint agenta.

Automatyzacja potrzebuje runbooków

Automatyzacja potrzebuje zasad. Musi być jasne, które sygnały mogą automatycznie blokować, kto zdejmuje izolację, jak obsługiwane są false positives i jak takie procesy są testowane. Bez runbooks, odpowiedzialności i regularnych ćwiczeń nikt w incydencie nie wie, czy blokada była zamierzona, poprawna czy zbyt agresywna.

Co dzieje się w incydencie? Skompromitowane urządzenie może zostać odizolowane, komunikacja C2 przerwana, exfiltration zablokowana, a analityk MDR albo XDR może uruchomić Active Threat Response bez wcześniejszego ręcznego budowania reguły na firewallu. To szczególnie wartościowe, gdy atak jest wykrywany poza normalnymi godzinami pracy.

Dla adminów szczególnie ważne jest jedno: reakcja musi być wystarczająco szybka. Jeśli analityk MDR albo XDR musi najpierw zadzwonić, napisać ticket, a lokalny admin w piątek wieczorem ręcznie buduje regułę, czas reakcji jest zbyt długi. Automatyczna reakcja nie oznacza zastąpienia ludzi. Oznacza, że pierwsze ograniczenie następuje natychmiast, a zespół może potem spokojnie analizować.

W małych zespołach IT ta automatyzacja jest szczególnie wartościowa. Nie każda firma ma specjalistę firewall dostępnego 24/7. Gdy Endpoint, Firewall, NDR, MDR i SIEM sensownie współpracują ponad granicami producentów, zyskuje się czas, a czas podczas aktywnych ataków bywa najważniejszym czynnikiem.

Praktyczna checklista dla adminów Sophos Firewall

Kto chce dziś utwardzić Sophos Firewall, może zacząć od tej listy:

Sprawdzić natychmiast

• Czy Hotfixes są aktywne?
• Czy MFA jest aktywne dla administratorów?
• Czy Web Admin Console i User Portal są dostępne z WAN?
• Czy SSL VPN albo IPsec Remote Access są chronione MFA?
• Czy istnieją nieużywane lokalne konta admin?
• Czy backupy są zaplanowane, szyfrowane i testowane?
• Czy Device Access i Local Service ACL są ograniczone do minimum?
• Czy usługi dostępne z WAN są ograniczone przynajmniej do istotnych krajów albo znanych sieci źródłowych?
• Czy pattern updates i wersje firmware są aktualne?

W najbliższych tygodniach

• Uruchomić Health Check i priorytetyzować findings.
• Sprawdzić stare reguły firewall z “Any” jako źródło, cel albo service.
• Sprawdzić role admin, Login Security, session timeouts i ochronę brute-force.
• Zinwentaryzować wystawione usługi jak RDP, SSH, serwery web, portale i reguły NAT.
• Sprawdzić wewnętrzne strefy i reguły VLAN przeciw lateral movement.
• Porównać opcje ZTNA, SSE albo SASE dla typowych aplikacji Remote Access.
• Sprawdzić Threat Feeds i DNS Protection.
• Aktywować Spoof Protection, ochronę DoS i Geo-IP-Blocking według ryzyka.
• Testować TLS Inspection strukturalnie i wdrażać etapowo.

Planować strategicznie

• Zastąpić systemy end-of-life.
• Sensownie skoordynować operację firewall, VPN, DNS, SD-WAN i ZTNA/SSE.
• Standaryzować central management, reporting i alerting, na przykład przez Sophos Central, SIEM albo istniejące platformy security.
• Zdefiniować Syslog/SIEM export i log retention do analiz forensycznych.
• Włączyć sygnały MDR/XDR/NDR do procesu incident.
• Wprowadzić powtarzalne firewall hardening reviews.

Podsumowanie

Network Security Best Practices nie są jednorazowym projektem, ale modelem operacyjnym. Ponieważ firewalle na brzegu sieci są tak uprzywilejowane, muszą być regularnie utwardzane, patchowane, sprawdzane i integrowane z detection.

Moja rekomendacja po wielu latach z Sophos Firewall jest jasna: nowoczesny firewall musi być czymś więcej niż produktem ochronnym. Decydują bezpieczny design, widoczne błędne konfiguracje, szybkie poprawki security i reakcja, która w incydencie współpracuje z Endpoint, NDR, XDR i MDR.

Albo praktycznie: jeśli firewall jest tak stary, że bardziej pasuje do muzeum niż do racka, to nie jest tylko ryzyko operacyjne. To powierzchnia ataku. I właśnie tę powierzchnię ataku utrzymuję tak małą, jak to możliwe.

Wsparcie Avanet

Jeśli potrzebne jest wsparcie przy hardeningu Sophos Firewall, Avanet może pomóc. Jako wieloletni specjalista Sophos wspieram zespoły IT w firewall audits, Health Check reviews, czyszczeniu reguł, planowaniu Remote Access i ZTNA/SSE, strategiach update oraz szkoleniach.

Zewnętrzne spojrzenie na dostępy management, konfigurację VPN, stare reguły, usługi wystawione przez WAN i status updates często się opłaca. Wiele ryzyk nie powstaje przez jedno błędne ustawienie, lecz przez historycznie narosłe wyjątki, których w codzienności nikt już nie kwestionuje.

W razie zainteresowania wystarczy krótka wiadomość przez formularz kontaktowy. Następnie można wspólnie ustalić, czy dla danego środowiska najbardziej sensowny jest kompaktowy firewall review, audyt czy szkolenie.

FAQ

Linki dodatkowe

• Avanet Blog: Sophos Firewall v22: przegląd i wszystkie nowe funkcje
• Avanet Blog: Threat Intelligence Feeds dla firewalla
• Avanet Blog: Sophos ZTNA Gateway na Sophos Firewall
• Avanet Blog: Sophos NDR - eliminowanie ślepych punktów w sieci
• Avanet KB: Sophos Firewall Firmware Update - przygotowanie i best practices

Źródła

• Sophos: Firewall: Network Security Best Practices
• Sophos Docs: Hardening your Sophos Firewall
• Sophos X-Ops: Nowhere, man: The 2026 Active Adversary Report