W wielu organizacjach Sophos XGS stoi na brzegu sieci i robi dokładnie trzy rzeczy: wypuszcza użytkowników do Internetu, przekłada adresy i utrzymuje kilka tuneli VPN. Wszystko działa, nikt nie zgłasza problemów, więc urządzenie znika z listy tematów do przemyślenia.
To zrozumiałe, ale warto zauważyć jedną rzecz. Ten sam punkt sieci, przez który i tak przechodzi cały ruch, może jednocześnie analizować komunikację szyfrowaną, rozpoznawać aplikacje, blokować próby wykorzystania podatności i złośliwe pliki, łączyć oddziały i pracowników zdalnych, pełnić rolę bramy ZTNA, chronić usługi publikowane do Internetu, a także reagować na informacje, których sam nie zobaczył — bo dostarczył ich inny element środowiska bezpieczeństwa.
Ten artykuł otwiera cykl poświęcony funkcjonalności Sophos XGS. Nie jest instrukcją konfiguracji ani katalogiem ekranów SFOS. To mapa: co urządzenie może robić i po co te możliwości w ogóle istnieją.
1. Firewall jest punktem wyjścia, nie końcem
Zacznijmy od podstawy, bo ona się nie zmieniła. XGS jest firewallem stanowym: ocenia źródło, cel, strefę, usługę i użytkownika, stosuje reguły, wykonuje NAT i DNAT, obsługuje VLAN-y i pozwala podzielić sieć na segmenty. Pytanie przewodnie brzmi tu prosto: kto, skąd i dokąd może się komunikować?
Warto jednak od razu poszerzyć perspektywę. Kontrola ruchu nie musi dotyczyć wyłącznie kierunku LAN → Internet. Równie istotne bywa to, co dzieje się wewnątrz organizacji: czy sieć produkcyjna widzi sieć biurową, czy drukarki mają dostęp do serwerów aplikacyjnych, czy gość w sali konferencyjnej trafia dokładnie tam, gdzie powinien.
W praktyce to właśnie segmentacja wewnętrzna jest tym elementem, który później ogranicza skutki incydentu. Jeśli atakujący przejmie jedną stację roboczą, granice zdefiniowane na firewallu decydują o tym, jak daleko może się przemieścić.
2. Ta sama komunikacja, kilka warstw oceny
Decyzja „zezwól” to dopiero początek. Ruch dopuszczony przez regułę może być następnie oceniany przez kolejne mechanizmy, z których każdy zadaje inne pytanie:
- IPS — czy w dozwolonym ruchu nie ma próby wykorzystania podatności?
- TLS Inspection — czy w ogóle widzimy, co jest w środku sesji szyfrowanej?
- Web Protection — dokąd użytkownik zmierza i jaka jest reputacja tego miejsca?
- Application Control — jaka aplikacja faktycznie generuje ten ruch?
- Malware Protection i Zero-Day Protection — czy przesyłany obiekt jest bezpieczny, także wtedy, gdy nikt go wcześniej nie widział?
- DNS Protection — czy pozwalamy w ogóle rozwiązać tę domenę?
- NDR — czy sam wzorzec komunikacji nie wygląda na działanie przeciwnika?
Nie rozwijam tu żadnego z tych mechanizmów — to temat drugiej części cyklu. Chodzi o skalę: jeden przepływ, kilka niezależnych perspektyw. Każda z nich może zatrzymać coś, czego pozostałe nie zauważą.
3. Miejsce, w którym spotykają się wszystkie ścieżki dostępu
Druga rola XGS to łączność. Firewall jest zwykle jedynym punktem, w którym stykają się ze sobą pracownicy zdalni, oddziały, sieć lokalna, usługi chmurowe i Internet. To sprawia, że jest naturalnym miejscem na politykę dostępu — niezależnie od tego, którędy ktoś przychodzi.
- site-to-site VPN — trwałe połączenia między lokalizacjami lub z chmurą,
- remote access VPN i Sophos Connect — dostęp pracownika do zasobów firmy,
- ZTNA Gateway — publikowanie pojedynczych aplikacji zamiast całej sieci,
- SD-WAN — świadomy wybór trasy zależnie od jakości i typu ruchu,
- SD-RED — bezpieczne przedłużenie sieci do małej lokalizacji bez lokalnego firewalla klasy enterprise,
- High Availability — ograniczenie ryzyka, że sam firewall stanie się pojedynczym punktem awarii.
To także temat na osobny artykuł — wrócę do niego w części trzeciej. Tu wystarczy jedna obserwacja: skoro decyzja o dostępie i decyzja o bezpieczeństwie ruchu zapadają w tym samym urządzeniu, mogą się wzajemnie uwzględniać.
4. XGS może chronić także usługi, które sama organizacja publikuje
Tu pojawia się rozróżnienie, które w rozmowach bywa mylone najczęściej.
Web Protection chroni użytkownika, który wychodzi z firmy do Internetu. Webserver Protection (WAF) działa w przeciwnym kierunku: to reverse proxy chroniące aplikację lub serwer WWW, który organizacja publikuje na zewnątrz. Pierwsze pilnuje, dokąd idą nasi ludzie. Drugie pilnuje, kto i w jaki sposób puka do naszej aplikacji.
Podobnie Email Protection — to funkcjonalność samego Sophos Firewall, obejmująca m.in. polityki SMTP, kontrolę spamu i malware oraz mechanizmy ochrony danych. Nie należy jej mylić z chmurowym produktem Sophos Email; to dwa różne rozwiązania, które odpowiadają na podobny problem w innych miejscach architektury.
Obie funkcje łączy jedno: bywają całkowicie pominięte, bo nie mieszczą się w codziennym obrazie „firewall = ruch wychodzący”. Wrócę do nich w ostatniej części cyklu.
5. Gdy informacja o zagrożeniu przychodzi z zewnątrz
I tu dochodzimy do zmiany, która moim zdaniem jest najciekawsza.
Klasyczny firewall podejmuje decyzje na podstawie tego, co sam zobaczy w pakietach. To nadal ważne, ale niesie oczywiste ograniczenie: jeśli atak nie zostawia rozpoznawalnego śladu w ruchu, firewall nie ma na czym oprzeć decyzji.
Sophos XGS może działać inaczej. Jest w stanie przyjmować kontekst z innych elementów środowiska:
- Security Heartbeat i Synchronized Security — stan bezpieczeństwa endpointu staje się elementem polityki sieciowej,
- Synchronized Application Control — informacja ze stacji pomaga rozpoznać aplikację, której sam ruch nie identyfikuje jednoznacznie,
- threat feeds — m.in. Sophos X-Ops, MDR, NDR oraz źródła zewnętrzne,
- Active Threat Response — mechanizm, dzięki któremu wskaźnik zagrożenia przekłada się na konkretną akcję na firewallu.
XGS nie musi podejmować decyzji wyłącznie na podstawie tego, co sam zobaczył w pakietach. Może stać się punktem egzekwowania reakcji wynikającej z kontekstu zebranego w zupełnie innym miejscu systemu.
Zastrzeżenie, które warto postawić od razu: XGS nie jest całym systemem Cyber Defense. Jest w nim jednym z komponentów — takim, który widzi ruch i potrafi go ograniczyć. To dużo, ale to nie to samo co „firewall załatwia bezpieczeństwo”.
6. Mam XGS — z czego faktycznie korzystam?
Zamiast podsumowania proponuję krótką listę pytań kontrolnych. Nie po to, żeby włączyć wszystko, tylko po to, żeby świadomie stwierdzić, co zostało pominięte i dlaczego.
- Czy używam XGS głównie jako firewalla i NAT-a?
- Czy ruch HTTPS jest objęty świadomą polityką inspekcji — łącznie z listą wyjątków?
- Czy korzystam z IPS, Web Protection, Application Control i Zero-Day Protection?
- Czy dostęp zdalny nadal opiera się wyłącznie na VPN, mimo że ZTNA jest dostępne?
- Czy XGS jest zintegrowany z Sophos Central i ochroną stacji końcowych?
- Czy wykorzystuję mechanizmy Active Threat Response?
- Czy sprawdzam konfigurację przez Firewall Health Check?
Jeżeli na większość odpowiedź brzmi „nie” — to nie jest błąd. To zwykle znak, że urządzenie zostało wdrożone pod konkretną potrzebę i od tego czasu nikt nie miał powodu wracać do tematu. Warto jednak wiedzieć, co się w tym czasie pojawiło.
Jeśli firewall ma być tylko firewallem — XGS zrobi to dobrze. Jego wartość zaczyna jednak rosnąć wtedy, gdy traktujemy go jako element większej architektury bezpieczeństwa.
Źródła
- Sophos Firewall 22.0 — Licensing info
- Sophos Firewall 22.0 — Active Threat Response
- Sophos Firewall 22.0 — Remote connectivity
- Sophos Firewall 22.0 — Firewall Health Check
Informacje zależne od wersji SFOS, licencji lub konkretnego modelu sprzętowego wymagają ponownej weryfikacji przed publikacją.