Każde wdrożenie firewalla ma podobny przebieg. Najpierw jest intensywnie: reguły, VPN-y, migracja, poprawki, kilka telefonów w weekend. Potem przychodzi moment, w którym wszystko zaczyna działać stabilnie — i to jest moment, w którym urządzenie znika z pola widzenia.
To całkowicie racjonalne. Nikt nie ma czasu przeglądać co kwartał listy funkcji sprzętu, który nie sprawia problemów. Kłopot polega na tym, że w tym samym czasie organizacja często kupuje albo utrzymuje osobne rozwiązanie problemu, który firewall już potrafi obsłużyć.
Ta część zamyka cykl przeglądem funkcji, które najczęściej pozostają niewykorzystane — bo nie mieszczą się w codziennym obrazie „firewall plus VPN”.
1. WAF: Web Protection to nie Webserver Protection
Zacznę od nieporozumienia, które słyszę najczęściej — również od osób, które pracują z XGS na co dzień.
Web Protection chroni użytkownika wychodzącego do Internetu. Webserver Protection, czyli Web Application Firewall, działa w przeciwnym kierunku: jako reverse proxy przed aplikacją lub serwerem HTTP/HTTPS, który organizacja publikuje na zewnątrz. Nazwy są podobne, kierunek ruchu i chroniony obiekt — zupełnie różne.
Zakres, który warto znać:
- definiowanie serwera wirtualnego i rzeczywistego oraz publikacja usługi przez reverse proxy,
- polityki ochrony i uwierzytelniania przed dopuszczeniem żądania do aplikacji,
- ochrona przed typowymi atakami na aplikacje webowe.
Kiedy to wystarczy? Zwykle wtedy, gdy publikujemy kilka aplikacji o umiarkowanej złożoności: portal dla kontrahentów, panel serwisowy, wewnętrzny system udostępniony na zewnątrz. Jeśli aplikacja jest głównym produktem firmy, ma dużą powierzchnię i wymaga dedykowanych reguł — warto rozważyć rozwiązanie wyspecjalizowane. Warto też pamiętać, że Webserver Protection jest osobną subskrypcją.
2. Email Protection: XGS może być również elementem ochrony poczty
Ta funkcja bywa pomijana, bo ochrona poczty kojarzy się dziś przede wszystkim z rozwiązaniami chmurowymi. Warto więc rozróżnić: Email Protection to funkcjonalność Sophos Firewall, a nie chmurowy produkt Sophos Email. To dwa różne rozwiązania.
W aktualnym SFOS dostępne są m.in. polityki dla SMTP/S, POP/S i IMAP/S, kontrola spamu i malware, mechanizmy ochrony danych oraz szyfrowanie — w zakresie zależnym od scenariusza. Tryb MTA pozwala routować i przekazywać pocztę, przy czym nie jest dostępny na modelach XGS 87/87w oraz 88/88w.
Scenariusze, w których to ma sens, są dość konkretne: lokalny serwer pocztowy wymagający filtracji przed dostarczeniem, potrzeba kontroli treści wychodzącej albo środowisko, w którym poczta nie przechodzi przez usługę chmurową.
3. High Availability: funkcji, której nie widać, dopóki działa
Wracam do tematu z części trzeciej, bo w kontekście „co przeoczyliśmy” wygląda inaczej.
HA jest klasycznym przykładem funkcji, której wartość jest zerowa przez 99% czasu i krytyczna przez pozostały procent. Sophos Firewall obsługuje warianty Active-Passive i Active-Active.
Pytanie kontrolne warto postawić inaczej niż zwykle: nie „czy mamy HA?”, tylko „ile procesów w firmie zatrzyma się, jeśli to jedno urządzenie przestanie działać na cztery godziny?”. Odpowiedź na to pytanie zwykle rozstrzyga temat.
4. Sophos Central Firewall Management: zarządzanie nie musi kończyć się na lokalnym GUI
Przy jednym urządzeniu logowanie do lokalnego interfejsu jest całkowicie wystarczające. Przy pięciu zaczyna być uciążliwe. Przy piętnastu w różnych lokalizacjach staje się realnym źródłem rozbieżności konfiguracyjnych — bo prędzej czy później któraś zmiana zostanie wprowadzona tylko w części miejsc.
Centralne zarządzanie firewallami z poziomu Sophos Central pozwala grupować urządzenia, utrzymywać wspólne elementy konfiguracji i uzyskiwać dostęp administracyjny bez konieczności publikowania interfejsu zarządzania.
5. Central Reporting i Central Orchestration
Tu warto rozdzielić trzy pojęcia, które bywają używane zamiennie:
- Central Firewall Reporting — centralizacja raportów z wielu urządzeń i dłuższa perspektywa danych, zależnie od licencji,
- SD-WAN VPN Orchestration — automatyzacja budowania połączeń między firewallami zamiast konfigurowania każdego tunelu ręcznie,
- Central Orchestration — licencja obejmująca m.in. SD-WAN VPN Orchestration oraz Central Firewall Reporting Advanced.
Nie powtarzam tu technicznej strony SD-WAN z części trzeciej. Tutaj chodzi o coś innego: operacyjne skalowanie zarządzania. Konfiguracja pełnej siatki tuneli między dziesięcioma lokalizacjami to zadanie, w którym błąd ludzki jest praktycznie pewny — i to jest dokładnie ten rodzaj pracy, który warto zautomatyzować.
6. Firewall Health Check: „działa” to nie to samo co „bezpiecznie skonfigurowane”
To jeden z mocniejszych elementów wprowadzonych w SFOS 22.0 i moim zdaniem najczęściej niewykorzystywany.
Firewall Health Check stale ocenia wybrane ustawienia urządzenia względem rekomendowanych konfiguracji, dobrych praktyk i standardów, w tym CIS. Wśród kontrolowanych obszarów znajdują się m.in. reguły firewalla, złożoność haseł oraz uwierzytelnianie wieloskładnikowe.
Wartość polega na tym, że odpowiada na inne pytanie niż monitoring. Monitoring mówi, czy urządzenie działa. Health Check mówi, czy działa w sposób, który dałoby się obronić podczas audytu.
Konfiguracja firewalla ma naturalną tendencję do degradacji: reguła dodana „tymczasowo” zostaje na trzy lata, wyjątek utworzony na czas migracji nikt nie usuwa, konto serwisowe zakładane przez integratora pozostaje aktywne. Nic z tego nie powoduje awarii — i właśnie dlatego nikt tego nie zauważa.
7. Logi, raportowanie i integracja z SIEM
XGS generuje bardzo dużo danych. Pytanie brzmi, gdzie one trafiają.
Lokalnie dostępny jest Log Viewer i raporty na urządzeniu; szerszą perspektywę daje raportowanie w Sophos Central. Osobną kwestią jest eksport przez syslog do zewnętrznego SIEM — istotny wszędzie tam, gdzie analiza incydentów odbywa się poza konsolą producenta.
Warto zadać jedno praktyczne pytanie: czy logi z firewalla trafiają do miejsca, w którym faktycznie prowadzimy analizę incydentów? Jeśli analiza dzieje się w SIEM, a firewall loguje wyłącznie lokalnie, to w praktyce znaczy, że przy poważniejszym zdarzeniu ktoś będzie łączył ze sobą dwa niezależne obrazy sytuacji — pod presją czasu.
W kontekście monitoringu infrastruktury warto wspomnieć również o SNMP, przydatnym do obserwacji stanu urządzenia i łączy.
8. API i automatyzacja
Administracja nie musi kończyć się na interfejsie graficznym. API pozwala włączyć XGS w procesy, które organizacja i tak realizuje: powtarzalne zmiany konfiguracji, tworzenie obiektów na podstawie danych z innych systemów, integrację z narzędziami do zarządzania zmianą.
Nie wchodzę tu w szczegóły techniczne — chodzi o wskazanie kierunku. W środowiskach, w których zmiany na firewallu są częste i powtarzalne, automatyzacja bywa mniej ryzykowna niż praca ręczna, bo eliminuje najczęstsze źródło błędów: rozbieżność między tym, co miało zostać zrobione, a tym, co faktycznie kliknięto.
9. Operacyjne drobiazgi, które też mają znaczenie
Na koniec krótka lista rzeczy, które trudno nazwać funkcjami sztandarowymi, a które regularnie decydują o jakości utrzymania:
- backup konfiguracji i sprawdzona procedura odtworzenia,
- powiadomienia i alerty skonfigurowane tak, by ktoś je faktycznie czytał,
- automatyczne hotfixy,
- monitoring stanu łączy WAN,
- agregacja łączy,
- redundantne zasilanie lub moduły interfejsów — zależnie od modelu.
Backup zasługuje na osobne zdanie: jego wartość weryfikuje się dopiero przy odtwarzaniu. Kopia, której nigdy nie przywracano, jest hipotezą, nie zabezpieczeniem.
10. Checklista na zakończenie cyklu
Zamiast rozbudowanego podsumowania — pytania, na które warto odpowiedzieć we własnym środowisku:
- Czy XGS chroni tylko ruch wychodzący, czy również aplikacje, które publikujemy?
- Czy potrzebujemy lokalnej ochrony poczty SMTP na firewallu?
- Czy firewall jest zabezpieczony przed własną awarią?
- Czy wszystkie urządzenia są zarządzane i raportowane centralnie?
- Czy korzystamy z orkiestracji tam, gdzie mamy wiele lokalizacji?
- Czy Firewall Health Check pokazuje ustawienia oznaczone jako ryzykowne?
- Czy logi trafiają tam, gdzie faktycznie analizujemy incydenty?
- Czy powtarzalne zadania administracyjne dałoby się zautomatyzować przez API?
Pełne wykorzystanie XGS nie oznacza włączenia każdej funkcji. Oznacza świadome sprawdzenie, które z nich rozwiązują problem, za który dziś odpowiada inny system, ręczny proces albo — co gorsza — nikt.
Zamknięcie cyklu
Przeszliśmy przez pięć perspektyw na to samo urządzenie: mapę możliwości, ochronę ruchu, bezpieczny dostęp, skoordynowaną reakcję i operacyjne wykorzystanie tego, co już mamy.
Wniosek, który przewija się przez wszystkie części, jest prosty. Wartość firewalla nie wynika z liczby dostępnych funkcji. Wynika z tego, ile z nich odpowiada na realny problem w konkretnej architekturze — i ile z tych odpowiedzi rzeczywiście zostało użytych.
Zostaje więc pytanie, od którego zaczynałem pierwszą część: ile z możliwości swojego XGS faktycznie wykorzystujesz?
Źródła
- Sophos Firewall 22.0 — Licensing info
- Sophos Firewall 22.0 — WAF rules
- Sophos Firewall 22.0 — Email
- Sophos Firewall 22.0 — Firewall Health Check
- Sophos Firewall 22.0 — Release notes
Informacje zależne od wersji SFOS, licencji lub konkretnego modelu sprzętowego wymagają ponownej weryfikacji przed publikacją.