Sophos Firewall v23: przegląd wszystkich nowości

Sophos Firewall v23 usprawnia wiele codziennych zadań, które zajmują administratorom czas: wyszukiwanie reguł, prawidłowe przypisywanie użytkowników, planowanie aktualizacji i ustalanie przyczyn przełączenia klastra. Nowa wersja główna wprowadza w tym celu REST API, asystenta AI oraz rozszerzenia dotyczące WAF, DNS i DHCP.

Stan wydania: Podobnie jak w poprzednich latach następna wersja główna rozpoczyna się od programu Early Access dla Sophos Firewall v23 w okolicach października, w tym roku już 28 września 2026 r. Ten artykuł opiera się na wydaniu EAP1. Do czasu udostępnienia wersji finalnej poszczególne funkcje i szczegóły mogą się jeszcze zmienić.

Część nowości jest dostępna bezpośrednio na firewallu, inne funkcje wymagają Sophos Fusion lub dodatkowego oprogramowania. Przy planowaniu szczególnie ważne jest to, że nowa identyfikacja użytkowników przez Synchronized Security wymaga Sophos Endpoint na odpowiednich urządzeniach oraz właściwej licencji Endpoint. Organizacja korzystająca dotąd wyłącznie z Microsoft Defender lub innego rozwiązania do ochrony stacji końcowych nie uzyska więc tej funkcji przez samą aktualizację firewalla. Musiałaby dodatkowo wdrożyć i licencjonować Sophos Endpoint. Jeśli licencje Sophos już istnieją, dodatkowe wymagania zależą od obecnej umowy. Wymagania pozostałych funkcji objaśniamy w odpowiednich sekcjach.

AI i automatyzacja

REST API: automatyzacja konfiguracji firewalla

Nowe REST API umożliwia skryptom i narzędziom administracyjnym odczytywanie i modyfikowanie konfiguracji bezpośrednio na firewallu. Uwierzytelnianie odbywa się za pomocą kluczy API. Specyfikacja w formacie OpenAPI 3.0 opisuje dostępne wywołania i pola danych, co ułatwia integrację interfejsu z używanymi już narzędziami. Dostęp odbywa się bezpośrednio do firewalla i jest niezależny od Sophos Central API służącego do eksportu oraz importu konfiguracji.

Rozsyłanie wspólnych ustawień do wielu firewalli było już jednym z głównych założeń Sophos Central Firewall Management. Grupy firewalli i nadrzędne zasady miały umożliwiać centralne zarządzanie takimi zmianami. W naszej praktyce działa to jednak tylko częściowo tak, jak wymaga tego niezawodna eksploatacja. Przy powtarzalnych zmianach wolimy więc polegać na własnych skryptach i procesach, których przebieg i rezultat możemy sami kontrolować. Nowe REST API jest przydatnym uzupełnieniem właśnie w tym obszarze.

Przykładem są obiekty sieciowe nowego serwera potrzebne na firewallach w kilku lokalizacjach. Skrypt może najpierw sprawdzić, czy obiekt już istnieje, wprowadzić tylko niezbędną zmianę, a następnie ponownie odczytać zapisaną wartość. W dzienniku będzie widać, który firewall został pomyślnie zaktualizowany, a gdzie potrzebna jest dalsza praca. Jest to szczególnie pomocne, gdy w czasie zmiany jedna z lokalizacji jest niedostępna i trzeba ją później zaktualizować osobno.

Kluczami API zarządza się w Administration > API access. Dziedziczą one uprawnienia przypisanego administratora. Dlatego do automatyzacji warto utworzyć osobne konto z odpowiednim profilem uprawnień. Prawidłowo ustawione muszą być także dozwolone adresy źródłowe i dostęp administracyjny. Dostęp należy ograniczyć do systemów, które rzeczywiście go potrzebują do zadań administracyjnych.

Allowed IP hosts: Również w v23 można tutaj dopuścić wyłącznie adresy IP lub sieci. Nadal nie da się podać FQDN, czyli pełnej nazwy DNS. W przypadku serwera automatyzacji ze stałym publicznym adresem IP nie stanowi to problemu. Jeśli jednak skrypt działa za łączem ze zmiennym publicznym adresem IP, nie można po prostu wskazać jego nazwy DNS jako dozwolonego źródła. Potrzebny jest wówczas na przykład stały punkt wyjścia do Internetu albo kontrolowany dostęp przez VPN. Po interfejsie mającym ułatwiać automatyzację oczekiwalibyśmy w tym zakresie większej elastyczności.

REST API guide można otworzyć w interfejsie WebAdmin w Administration > API access. Odnośnik znajduje się po prawej stronie nad listą kluczy API, bezpośrednio obok OpenAPI.yaml. Publiczna dokumentacja Sophos Firewall API Reference opisuje endpointy, pola danych i podstawy uwierzytelniania. Przy konkretnej implementacji rozstrzygający jest plik OpenAPI z wersji zainstalowanej na firewallu. Przed zastąpieniem istniejących automatyzacji XML trzeba sprawdzić, czy wszystkie potrzebne funkcje są dostępne. Obsługa błędów, rejestrowanie działań i przetestowana procedura wycofania zmian są niezbędne także przy nowoczesnym API.

Asystent AI do reguł firewalla

Nowy asystent w Sophos Fusion odpowiada na pytania dotyczące reguł firewalla. Tworzone przez niego szkice reguł trafiają na koniec tabeli i są wyłączone; ich zatwierdzenie pozostaje w gestii administratora.

To rozsądne podejście do współpracy z AI. Polecenie takie jak „Utwórz szkic dostępu HTTPS z sieci pracowników do wewnętrznego serwera WWW” może wykonać część pracy przygotowawczej. Przed aktywacją nadal trzeba ustalić, jakie dokładnie obiekty są objęte regułą, czy należy ograniczyć użytkowników i jakie kontrole bezpieczeństwa powinny mieć zastosowanie.

Szczególnie ważne jest położenie reguły. Merytorycznie poprawne zezwolenie może być nieskuteczne, jeśli wcześniej zadziała inna reguła. Z kolei reguła umieszczona zbyt wysoko może dopuścić więcej ruchu, niż zamierzano. Asystent nie podejmuje więc decyzji o bezpieczeństwie za administratora. Jego wartość polega na przygotowaniu pracy nad zestawem reguł i ułatwieniu odnajdywania powiązań.

Selektywne dopuszczanie lub blokowanie usług AI

Do kontroli korzystania z AI dodano kategorię internetową Generative AI oraz filtry aplikacji związane z Sophos AI Defense.

W Diagnostics > URL category lookup można sprawdzić klasyfikację domeny. Dla openai.com firewall pokazuje kategorię Generative AI. Pomaga to w rozwiązywaniu problemów: jeśli usługa AI zostanie niespodziewanie zablokowana, można najpierw sprawdzić jej kategorię, a potem właściwą politykę internetową.

W firmie sensowna konfiguracja zaczyna się od prostej decyzji: które usługi AI są dozwolone do jakich zadań? Dział programistyczny może potrzebować innych narzędzi niż księgowość. Dopiero na tej podstawie da się zbudować użyteczną politykę sieciową.

Samo dopuszczenie domeny nic jednak nie mówi o tym, jakie informacje wolno do niej wprowadzać. Kontrola dostępu i ochrona danych to odrębne zadania. Również dla dozwolonej usługi potrzebne są zasady dotyczące danych klientów, kodu źródłowego i poufnych dokumentów. Filtry sieciowe mogą wspierać te zasady organizacyjne, ale nie zastąpią oceny treści każdego promptu.

Zarządzanie regułami i obsługa

Nowa tabela reguł firewalla

Widok Rules and policies > Firewall rules został gruntownie przebudowany. Zamiast rozwijanych folderów Sophos pokazuje teraz reguły w jednej ciągłej tabeli. Grupowanie pozostaje, ale jest przedstawione w kolumnie Group. Dodano także wyszukiwanie tekstowe, filtry i konfigurowalny widok kolumn.

Rozwiązuje to irytujący problem poprzedniego interfejsu: po edycji i zapisaniu reguły firewalla grupa ponownie się zwijała. Aby od razu zmodyfikować kolejną regułę z tej samej grupy, trzeba było ponownie otworzyć folder. Przy kilku kolejnych zmianach było to niepotrzebnie uciążliwe. Pokazanie grupy w kolumnie eliminuje ciągłe rozwijanie.

Wybór i porządkowanie kolumn

Ikona koła zębatego po prawej stronie nad tabelą pozwala ustalić, które kolumny są wyświetlane. Niepotrzebne informacje można ukryć, dodatkowe szczegóły wyświetlić, a kolejność kolumn zmienić. Kolumny można również przypinać, dzięki czemu na przykład nazwa reguły pozostaje widoczna podczas przeglądania szerokiej tabeli.

Co szczególnie cieszy, w naszym teście wybrany widok pozostał zapisany także po wylogowaniu i ponownym zalogowaniu. Nie trzeba więc odtwarzać odpowiedniego układu przy każdej sesji.

Do szybkiego przeglądu często wystarczą nazwa, grupa, akcja, status i ruch. Przy diagnozowaniu problemów istotniejsze są sieci źródłowe i docelowe, usługi oraz logowanie. Jeśli na przykład trzeba usunąć dostęp do starego serwera aplikacyjnego, warto widzieć obok siebie cele wszystkich powiązanych reguł. Brak konieczności otwierania każdej reguły osobno oszczędza czas i ułatwia porównanie.

Dostępne są poniższe kolumny. Nazwy odpowiadają angielskiej wersji interfejsu; dla przejrzystości podzieliliśmy je tematycznie:

• Reguła i przegląd: Name, Type, Group, ID, Features, Traffic (In/Out), Status, Action, Schedule, Description.
• Sieci i usługi: Src networks, Src zones, Dst zones, Dst networks, Services.
• Użytkownicy i logowanie: Users, Exclude users from accounting, Web authentication for unknown users, Log.
• Funkcje ochrony i polityki: Email, Web policy, IPS policy, Application policy.
• Pasmo i priorytety: Traffic shaping policy, Traffic shaping (applications), Traffic shaping (web category), DSCP marking.
• Security Heartbeat: Source HB, Block client with no source HB, Destination HB, Block client with no destination HB.
• Wyjątki: Excluded source address, Excluded destination address, Excluded source zone, Excluded destination zone, Excluded service.

Stary widok na razie pozostaje dostępny

Przełącznik New design pozwala jeszcze wrócić do poprzedniego widoku. Kto nie odnajduje się w nowej tabeli, ma więc na razie alternatywę. Nie wiadomo, jak długo Sophos będzie oferował oba widoki równolegle.

Reguły NAT: nadal bez grupowania i klonowania

Niestety Sophos nie przeniósł nowego widoku na reguły NAT. Również w v23 są one traktowane inaczej: reguł NAT nadal nie można grupować ani klonować. Klonowanie reguł firewalla jest możliwe, ale tej funkcji wciąż brakuje przy regułach NAT.

Byłoby to szczególnie przydatne przy publikowaniu kilku podobnych usług. Jeśli dla kolejnego serwera WWW potrzebne jest prawie takie samo przekierowanie, chciałoby się skopiować istniejącą regułę NAT, a następnie zmienić cel i usługę. Zamiast tego trzeba utworzyć regułę od nowa. Zajmuje to czas i zwiększa ryzyko przypadkowego odstępstwa w innych ustawieniach.

Pisaliśmy już o tych potrzebach w artykule o Sophos Firewall v22. Nowy widok reguł firewalla jest mile widzianym postępem. Tym bardziej szkoda, że obsługa NAT nadal pozostaje w tyle pod względem podstawowych funkcji administracyjnych.

WebAdmin, numer seryjny i stan klastra

Interfejs WebAdmin wykorzystuje HTTP/2, aby przyspieszyć przesyłanie elementów stron. Numer seryjny oraz stan klastra HA pozostają też widoczne podczas przechodzenia między stronami ustawień.

HTTP/2 może pomóc w ładowaniu wielu elementów strony, szczególnie przez połączenia o większych opóźnieniach. Odczuwalna szybkość konkretnego widoku zależy jednak również od przetwarzania na firewallu. Powolne zapytanie do bazy danych albo zapisywanie złożonej konfiguracji nie stanie się szybkie wyłącznie dzięki innemu protokołowi transportowemu. W moim pierwszym teście wzrost szybkości był niewielki: zapis reguły firewalla nadal trwał kilka sekund.

Stale widoczna tożsamość urządzenia ma od razu zrozumiałą zaletę: przy kilku otwartych sesjach firewalli łatwiej sprawdzić, na którym systemie się pracuje. Przed zmianami w klastrze HA warto też spojrzeć na role i stan uczestniczących urządzeń.

Osoby wspierające kilka bardzo podobnych środowisk klientów znają moment niepewności przed zapisaniem zmiany. Numer seryjny, który zawsze widać, ułatwia porównanie z ticketem bez opuszczania bieżącej strony ustawień. To niewielka zmiana o bardzo konkretnym pożytku.

Wysoka dostępność: szybsze wykrywanie, bardziej świadome przełączanie

Stan sprzętu jako powód przełączenia

Klaster HA monitoruje teraz nie tylko połączenia i usługi, lecz także stan wybranych komponentów sprzętowych, w tym dysku SSD. Jeśli stan dysku się pogorszy, klaster może przełączyć obsługę na drugi firewall.

Klaster HA może skutecznie zareagować tylko na usterkę, którą rozpozna. Urządzenie bywa nadal osiągalne przez interfejsy sieciowe, choć ma już wewnętrzne problemy. Dodatkowe monitorowanie sprzętu ma więc znaczenie dla niezawodnej pracy.

Uszkodzony dysk SSD może na przykład zakłócać zapis danych, gdy łącze HA wciąż działa. Samo monitorowanie połączeń nie wykryłoby stanu nośnika. Dodatkowy nadzór sprzętowy pozwala zareagować, zanim osłabiony węzeł całkowicie przestanie działać.

Po takim przełączeniu trzeba mimo wszystko zbadać przyczynę. Drugi węzeł utrzymuje usługę, ale nie naprawi uszkodzonego SSD. Procedura operacyjna powinna więc obejmować kontrolę urządzenia, ocenę pozostałej redundancji i w razie potrzeby wymianę sprzętu.

Krótszy czas wykrywania

Dzięki szybszemu monitorowaniu klaster HA rozpoznaje awarię drugiego firewalla w ciągu 300 ms zamiast dotychczasowych czterech sekund.

Te 300 ms oznacza czas potrzebny firewallowi na wykrycie awarii drugiego urządzenia w klastrze. Zanim aplikacja wróci do normalnej pracy, mogą być konieczne dalsze kroki: pozostały firewall musi przejąć obsługę, sąsiednie urządzenia sieciowe muszą skierować ruch właściwą drogą, a istniejące połączenia muszą zostać utrzymane lub zestawione ponownie.

Dlatego miarodajny test powinien obejmować coś więcej niż ping. Trwająca rozmowa telefoniczna, transfer pliku i dostęp VPN pokażą różne skutki. Dopiero takie pomiary pozwolą ocenić, czy przełączenie jest wystarczająco szybkie dla własnych procesów biznesowych.

Mniej niepotrzebnych przełączeń przy dużym obciążeniu

Oba firewalle regularnie wymieniają krótkie komunikaty o stanie, nazywane HA heartbeat. Teraz są one przetwarzane priorytetowo i oddzielnie od zwykłego ruchu danych.

Zmiana dotyczy problemu występującego przy dużym obciążeniu: gdy system jest mocno zajęty, spóźniona odpowiedź może wyglądać jak awaria. Spowodowane tym przełączenie wprowadza dodatkowe zamieszanie w środowisku, które i tak jest już przeciążone.

Podczas odbioru warto więc sprawdzić dwie sytuacje: czy klaster wykrywa prawdziwą awarię i czy pozostaje stabilny przy dużym obciążeniu bez faktycznej awarii urządzenia? Prosty test funkcjonalny w spoczynku odpowiada tylko na pierwszą część tego pytania.

Bezpieczeństwo DNS, Hotfixes i firmware

DNS over HTTPS i DNSSEC

Firewall może teraz wysyłać zapytania DNS do resolvera przez szyfrowane połączenie HTTPS oraz weryfikować odpowiedzi DNS za pomocą DNSSEC. Łatwiej można też aktywować Sophos DNS Protection.

Te dwie techniki DNS rozwiązują różne problemy. DNS over HTTPS, czyli DoH, szyfruje transmisję do resolvera. DNSSEC służy do weryfikacji podpisanych danych DNS. Samo szyfrowane połączenie nie potwierdza jeszcze autentyczności odpowiedzi DNS, a prawidłowy podpis nie ukrywa zapytania przed obserwatorami drogi transmisji.

Przed wdrożeniem trzeba najpierw zrozumieć obecny przepływ zapytań DNS. Czy klient pyta firewall, wewnętrzny serwer DNS Windows, czy bezpośrednio publiczny resolver? Nazwy wewnętrzne muszą nadal być rozwiązywane we właściwym miejscu. Dlatego nadal istotne są na przykład DNS Request Routes.

Uwagę należy poświęcić także przeglądarkom z własnymi ustawieniami DoH. Jeśli klient używa innego resolvera, jego rzeczywista droga DNS może odbiegać od przewidzianej konfiguracji centralnej. Test funkcjonalny powinien więc objąć nazwy wewnętrzne, rozwiązywanie nazw zewnętrznych i oczekiwane decyzje filtrowania.

Widoczne poprawki Hotfix i aktualizacje zabezpieczeń

Przeglądając interfejs, zauważyliśmy kolejną zmianę: w Backup & firmware ponownie znajduje się osobna sekcja dotycząca Hotfixes. Karta nosi nazwę Hotfix: Security updates. Dawniej ustawienie Hotfixes było dostępne w sekcji Firmware. Zaznaczenie pola wyboru pozwalało określić, czy ważne Hotfixes mają instalować się automatycznie. Po tym, jak ustawienie zniknęło z interfejsu, Hotfixes znów mają w nim widoczne miejsce.

Nowy widok przedstawia stan aktualizacji zabezpieczeń. Na pokazanym ekranie nie widać dawnego przełącznika włączającego i wyłączającego. Przejściowy brak tego ustawienia nie oznaczał też, że firewall przestał otrzymywać Hotfixes: funkcja automatycznej instalacji nadal istnieje.

Do czego służą Hotfixes

Hotfixes to ukierunkowane poprawki pilnych problemów, zwłaszcza luk bezpieczeństwa. Mogą być udostępniane poza regularnymi wydaniami firmware. Dzięki temu ważna poprawka nie musi czekać na następne Maintenance Release ani na zaplanowanie w firmie pełnej aktualizacji firmware.

Jeśli na przykład zostanie odkryta luka w usłudze administracyjnej, odpowiedni Hotfix może skorygować komponent, którego dotyczy problem. Automatyczna instalacja skraca czas między udostępnieniem poprawki a jej zastosowaniem na firewallu. Jest domyślnie włączona i powinna pozostać aktywna podczas normalnej pracy. Hotfixes nie zastępują jednak regularnych aktualizacji firmware, które wprowadzają także inne poprawki błędów, zmiany komponentów i nowe funkcje.

Bezpośrednia kontrola stanu poprawek

Interfejs pokazuje teraz, które luki bezpieczeństwa zostały usunięte przez zainstalowane Hotfixes. Przy każdej pozycji podane są identyfikator CVE, poziom zagrożenia, data instalacji i odnośnik do odpowiedniego komunikatu bezpieczeństwa. Informacje te są dostępne również w raportach.

Pomaga to odpowiedzieć na częste pytanie operacyjne: czy konkretna luka została już załatana na tym właśnie firewallu? Sam numer wersji firmware nie zawsze daje pełną odpowiedź, jeśli dodatkowo dystrybuowane są Hotfixes.

Gdy klient pyta o nowe Security Advisory, lokalny stan można dzięki temu lepiej udokumentować. Zamiast wnioskować o poziomie ochrony jedynie z wersji firmware, można sprawdzić daną CVE oraz datę instalacji Hotfix i zapisać je w tickecie.

W dokumentacji wyświetlany stan poprawek należy oceniać razem z odpowiednim Advisory. Zainstalowana poprawka odpowiada na pytanie o daną lukę. Nie dowodzi ani bezpiecznej konfiguracji całego systemu, ani tego, że nie doszło wcześniej do ataku. Do takiej oceny nadal potrzebne są przegląd konfiguracji, analiza logów i ewentualnie dochodzenie.

Cykliczne aktualizacje firmware

W Sophos Fusion można wyznaczyć cykliczne okna serwisowe, w których firewalle automatycznie instalują nowe wersje firmware. Nie trzeba przy tym aktualizować wszystkich urządzeń jednocześnie. Najpierw można zaktualizować wybrane firewalle, a pozostałe później. Dla pojedynczych urządzeń można ustawić wyjątki, na przykład gdy lokalizacja wymaga własnego okna serwisowego.

Jest to szczególnie pomocne w firmie z wieloma oddziałami. Przykładowo aktualizacja trafia najpierw na firewall w małym biurze. Następnie sprawdza się tam połączenia VPN, logowanie użytkowników i opublikowane usługi. Dopiero gdy kontrole zakończą się powodzeniem, aktualizowane są kolejne lokalizacje. Nie trzeba uruchamiać każdej instalacji osobno, a jednocześnie zachowuje się kontrolę nad kolejnością.

Wcześniej trzeba ustalić, kto sprawdza wyniki i w razie problemów zatrzymuje następne aktualizacje. Automatyczna instalacja nie zastępuje kopii zapasowej ani przygotowanej procedury powrotu. Niezbędne czynności opisujemy w instrukcjach dotyczących aktualizacji firmware oraz kopii zapasowych i przywracania.

Tożsamość i logowanie

Entra ID z Synchronized User ID

Dzięki Synchronized Security firewall może teraz identyfikować również użytkowników korzystających z Entra ID. Pozwala to wspólnie obsługiwać urządzenia połączone z lokalnym AD oraz urządzenia korzystające z tożsamości chmurowej. Identyfikacja wymaga Sophos Endpoint na odpowiednich urządzeniach i właściwej licencji Endpoint.

Praktyczne pytanie brzmi: skąd firewall wie, jaki użytkownik stoi za danym połączeniem? Sam adres IP nie zawsze wystarcza do sensownego zastosowania reguły przypisanej do użytkownika. Podczas przechodzenia z lokalnej domeny na tożsamość chmurową to przypisanie także musi nadal działać niezawodnie.

Typowy przykład to firma, która podłącza nowe notebooki tylko do Entra ID, podczas gdy starsze urządzenia nadal należą do lokalnej domeny AD. Dla polityki internetowej księgowości ten techniczny etap przejściowy nie powinien mieć znaczenia: decydująca jest grupa użytkownika. Taka ciągłość ma znaczenie przy stopniowej migracji do chmury.

Przy planowaniu ważne jest odróżnienie tej funkcji od znanego już logowania przez Entra ID w Captive Portal. Tu chodzi o współpracę z Sophos Endpoint. Samo istnienie środowiska Entra ID nie zapewnia więc poprawnej identyfikacji użytkowników przez firewall. W pilotażu trzeba sprawdzić, jaki użytkownik jest faktycznie wyświetlany i która reguła grupowa zostaje następnie zastosowana.

Google Workspace jako Identity Provider

Użytkownicy mogą logować się za pomocą konta Google Workspace do Captive Portal, VPN Portal, Sophos Connect i interfejsu WebAdmin. Google Workspace pełni wówczas rolę Identity Provider i podczas logowania może też wymagać uwierzytelniania wieloskładnikowego.

Dla organizacji, których centralnym katalogiem użytkowników jest Google, to ważne uzupełnienie. Konta i wymogi logowania powinny, o ile to możliwe, być zarządzane tam, gdzie obsługiwane są także pozostałe dostępy firmowe.

Na przykład szkoła korzystająca z Google Workspace nie musi utrzymywać na firewallu niezależnego zestawu haseł dla nauczycieli korzystających z VPN. Ogranicza to podwójne administrowanie i ułatwia zabezpieczenie logowania przez centralnego dostawcę tożsamości.

Pomyślne logowanie to jednak tylko jedna część integracji. Później muszą zostać przyznane właściwe uprawnienia. Zwykły pracownik nie może otrzymać dostępu administracyjnego tylko dlatego, że logowanie SSO działa. Testy muszą więc obejmować atrybuty użytkownika, przypisanie do grup, dozwolone usługi oraz odbieranie uprawnień.

Konfiguracja MFA przez e-mail

Podczas konfiguracji uwierzytelniania wieloskładnikowego firewall może wysłać potrzebny kod QR pocztą elektroniczną. Jeśli rejestracja nie zostanie zakończona w ciągu 24 godzin, niewykorzystany kod wygasa. W istniejących instalacjach dotychczasowa konfiguracja przez portal pozostaje początkowo dostępna.

Zmienia to proces wdrażania nowych użytkowników. Przed rozpoczęciem wdrożenia należy sprawdzić adresy e-mail i dostarczanie poczty. W przeciwnym razie pierwsze logowanie do VPN może zakończyć się zgłoszeniem do pomocy technicznej, mimo że samo uwierzytelnianie zostało skonfigurowane prawidłowo.

Kod QR do rejestracji zawiera informacje istotne dla bezpieczeństwa. Skrzynka odbiorcza musi więc również być zabezpieczona. Helpdesk potrzebuje ponadto jasnej procedury postępowania z wygasłymi rejestracjami i błędnie zapisanymi adresami. Ponowne wysłanie kodu nie może oznaczać pominięcia weryfikacji tożsamości osoby zgłaszającej się po pomoc.

SSO na Chromebookach

Nowe rozszerzenie do Chromebooków może przekazać dane logowania użytkownika do firewalla, dzięki czemu nie musi on ponownie logować się w Captive Portal. Rozszerzenie obsługuje wszystkie nadal wspierane wersje SFOS.

Zwłaszcza w szkołach powtarzające się logowanie do portalu jest uciążliwe. Istotne jest tam jednak nie tylko pierwsze udane logowanie, lecz także zmiana użytkowników i urządzeń. Test na współdzielonych Chromebookach powinien wykazać, że po zmianie użytkownika stare przypisanie nie jest nadal wykorzystywane.

Ponieważ rozszerzenie ma działać z różnymi wersjami, jego wdrożenie należy zaplanować osobno od aktualizacji do v23. Równoczesne wprowadzenie nowego komponentu klienta i nowego firmware firewalla utrudnia znalezienie przyczyn ewentualnych błędów.

Serwery terminalowe: przypisywanie użytkowników przez XDR Sensor

Dla Sophos Authentication for Thin Client, w skrócie SATC, można zastosować lekki XDR Sensor. Pomaga on firewallowi przypisywać ruch sieciowy na współdzielonym serwerze poszczególnym użytkownikom i może działać obok istniejącego rozwiązania ochrony stacji końcowych.

Na serwerze terminalowym wiele sesji korzysta z tego samego adresu IP serwera. Zezwolenie oparte na adresie IP nie odróżnia więc księgowości od zewnętrznego pracownika używającego tego samego hosta. Reguły internetowe lub firewallowe przypisane do użytkownika wymagają dodatkowego mechanizmu identyfikacji.

Możliwość pracy sensora obok obecnego produktu ochronnego jest interesująca w środowiskach mieszanych. Nie wynika z tego jednak ogólna gwarancja zgodności każdej kombinacji. Licencję, system operacyjny i wspieraną współpracę trzeba sprawdzić wcześniej. W testach funkcjonalnych co najmniej dwaj równocześnie zalogowani użytkownicy powinni podlegać różnym regułom. Wpływ na sam serwer terminalowy należy ocenić oddzielnie od decyzji podejmowanych przez firewall.

WAF: większa kontrola nad publikowanymi aplikacjami

Różne akcje dla poszczególnych ścieżek URL

Web Application Firewall otrzymuje akcje przypisywane ścieżkom: Protect, Block, Redirect i Passthrough. Ostatnia z nich służy do obsługi WebSocketów bez inspekcji WAF.

Protect pozostawia ścieżkę pod kontrolą WAF. Block odrzuca dostęp z kodem HTTP 403. Redirect kieruje przeglądarkę pod inny adres. Passthrough jest więc świadomie wybranym wyjątkiem dla odpowiedniego ruchu WebSocket, a nie dodatkowym etapem kontroli.

Pozwala to dokładniej dopasować sposób obsługi aplikacji do jej struktury. Po zmianie portalu można na przykład przekierować /altes-portal na /kundenportal, a wyłączony obszar pod /legacy zablokować kodem HTTP 403. Główna część aplikacji pozostaje chroniona przez WAF. Zarządzanie takimi decyzjami bezpośrednio w punkcie dostępu przed aplikacją może ograniczyć potrzebę zmian w backendzie.

Cel przekierowania musi być precyzyjny. Błędna ścieżka może zakłócić logowanie lub zapisane linki, a nieprzemyślane przekierowanie może spowodować pętlę. Z kolei przy wyjątku bez inspekcji WAF trzeba ustalić, jaka ochrona pozostaje w samej aplikacji. Działające połączenie nie dowodzi równoważnego poziomu kontroli bezpieczeństwa.

Więcej ścieżek i reguł

Dla każdego wpisu ścieżki przewidziano do 128 ścieżek. Domyślny limit reguł WAF wynosi 100 i można go zwiększyć do 200.

Podczas planowania należy osobno traktować limit reguł i wydajność. Możliwość skonfigurowania większej liczby reguł nie znaczy automatycznie, że urządzenie obsłuży dowolną liczbę aktywnych aplikacji z takim samym czasem odpowiedzi. Na zapotrzebowanie na zasoby wpływają także przetwarzanie TLS, inspekcja, przesyłanie plików i szybkość serwerów backendowych.

Dlatego przy odbiorze należy wykorzystać typowe zapytania rzeczywistych aplikacji. Sama statyczna strona testowa słabo odwzorowuje na przykład portal obsługujący wysyłanie dużych plików.

Nowy sposób przetwarzania z Apache Event MPM

WAF przechodzi na Apache Event MPM, aby lepiej obsługiwać jednoczesne żądania.

W uproszczeniu chodzi o lepsze wykorzystanie mocy obliczeniowej, gdy niektóre połączenia czekają na dalsze przetwarzanie. Przy wielu równoczesnych dostępach ten podział ma znaczenie: nie każde otwarte połączenie powinno niepotrzebnie blokować zasoby potrzebne innym żądaniom. Wydajność backendu pozostaje jednak osobnym ograniczeniem.

Decydujący wskaźnik operacyjny to zachowanie pod obciążeniem. Aplikacja może być technicznie dostępna, lecz odpowiadać tak wolno, że użytkownicy rezygnują z pracy. W testach obciążeniowych trzeba więc oceniać nie tylko udane połączenia, ale też czasy odpowiedzi i odsetek błędów.

Do rzetelnego porównania stanu przed zmianą i po niej sprzęt, profil bezpieczeństwa, backend oraz ruch testowy muszą pozostać takie same. Dopiero wtedy można ocenić wpływ nowego sposobu przetwarzania we własnym środowisku. Sama zmiana architektury nie pozwala wyznaczyć uniwersalnej przepustowości.

DHCP, routing i usługi sieciowe

DHCP na nowej Control Plane

Usługa DHCP działa teraz na nowej Control Plane i może obsłużyć większe pule adresów oraz więcej rezerwacji. Ponadto firewall sprawdza ruch DHCP jeszcze przed przekazaniem go do usługi, aby ograniczyć skutki zalewu zapytań. Ustawienia, które wcześniej wymagały wiersza poleceń, są teraz dostępne w interfejsie.

Dotyczy to podstawowej zależności całej sieci. Jeśli klienci nie otrzymują adresów, wiele innych usług również wydaje się niesprawnych. Po aktualizacji serwer DHCP należy więc sprawdzić równie świadomie jak VPN czy dostęp do Internetu.

Skalowanie ma znaczenie na przykład w szkole, gdy rano wiele urządzeń niemal równocześnie dołącza do Wi-Fi i prosi o adres. Z perspektywy użytkowników powolne przydzielanie adresów szybko wygląda jak problem z siecią bezprzewodową. Sprawne przetwarzanie dzierżaw pomaga w obszarze, który podczas diagnozy łatwo przeoczyć.

Testy powinny objąć nowe dzierżawy, odnowienia istniejących i zarezerwowane adresy. Prawidłowe muszą być również przekazywane wartości, takie jak brama, serwery DNS i indywidualne opcje DHCP. Właśnie rzadko używane ustawienia często ujawniają się dopiero po ponownym uruchomieniu specjalnego urządzenia.

Usprawniono również przeglądanie przydzielonych adresów. Opcje DHCP są przetwarzane w sposób bardziej jednolity i zgodny z podstawowymi standardami. Dlatego istniejące konfiguracje specjalne zasługują na celowe porównanie przed aktualizacją i po niej.

Do ustawień przeniesionych do interfejsu należą negatywne potwierdzenia oraz ograniczenie do jednej dzierżawy na klienta. Negatywne potwierdzenie informuje klienta, że nie może użyć żądanego adresu i musi ponownie uzgodnić konfigurację IP. Takie ustawienia należy oceniać w kontekście własnego projektu sieci, zwłaszcza jeśli działa w niej kilka usług DHCP.

mDNS Reflector dla Bonjour i wykrywania urządzeń

Dzięki mDNS Reflector urządzenia mogą odkrywać usługi także w innych wybranych sieciach. Działa to zarówno z IPv4, jak i IPv6. Do późniejszego połączenia z odnalezionym urządzeniem nadal potrzebna jest odpowiednia reguła firewalla.

Przydaje się to na przykład wtedy, gdy drukarki i pracownicy znajdują się w różnych VLAN-ach. Drukarka może mieć prawidłowy adres i być zasadniczo osiągalna, a mimo to nie pojawiać się podczas automatycznego wyszukiwania urządzeń. Odkrycie usługi i późniejsze połączenie danych to dwa odrębne kroki.

W konfiguracji należy dopuścić wyłącznie potrzebne pary sieci i usługi. Sieć gościnna nie musi odkrywać wszystkich urządzeń infrastruktury wewnętrznej. Po konfiguracji warto sprawdzić zarówno pożądany efekt, jak i granice: wskazana drukarka jest znajdowana i działa, a inne usługi wewnętrzne pozostają niedostępne.

Silnik routingu i eksperymentalne BFD

Firewall wykorzystuje zaktualizowaną wersję oprogramowania routingu FRR. Różnymi protokołami routingu można zarządzać przez wspólną konsolę. Dochodzi eksperymentalna obsługa BFD dla BGP i tras statycznych na firewallach działających samodzielnie.

BFD, czyli Bidirectional Forwarding Detection, służy do szybkiego wykrywania utraty połączenia między sąsiadami routingu. To inne zadanie niż zmiana roli w klastrze HA firewalli. Szybsze wykrycie problemu może pomóc wcześniej skierować ruch na alternatywną trasę.

Bardzo krótkie interwały monitorowania nie są jednak celem samym w sobie. Jeśli urządzenie po drugiej stronie lub droga transmisji nie odpowiada niezawodnie pod obciążeniem, agresywne ustawienia mogą powodować niepotrzebne zmiany stanu. Eksperymentalny status funkcji należy więc potraktować poważnie i najpierw ocenić BFD w odpowiednim środowisku testowym.

Interesujący przypadek to dwa routowane połączenia między lokalizacjami: lokalny interfejs może pozostać aktywny, chociaż sąsiad nie jest już osiągalny przez preferowaną drogę. Sam stan łącza nie wystarcza wtedy do wykrycia awarii. Odpowiednie użycie BFD może pomóc w takiej architekturze wcześniej zauważyć problem.

IPv6 IPoE i 4in6

Firewall obsługuje kolejne warianty połączeń wykorzystujące IPv6 IPoE oraz tunele 4in6. Dotyczy to także japońskiej usługi internetowej Xpass.

W 4in6 ruch IPv4 jest przenoszony przez połączenie IPv6. Funkcje te są istotne przede wszystkim wtedy, gdy dostawca Internetu wymaga właśnie takiego modelu dostępu. W przypadku tradycyjnego łącza sama ich dostępność nie jest powodem do przebudowy konfiguracji WAN.

Rozszerzenia dotyczą też dynamicznych adresów, końcówek tuneli i MTU/MSS. Podczas diagnozy ważne jest ich współdziałanie: udane zestawienie tunelu nie gwarantuje jeszcze prawidłowego działania dużych pakietów ani wszystkich aplikacji. Parametry dostawcy, rozwiązywanie nazw i wielkość pakietów należy więc sprawdzać łącznie.

Wdrożenie w IONOS Cloud

Sophos Firewall można teraz uruchomić również w IONOS Cloud przy użyciu oficjalnego obrazu SFOS. Instalacja odbywa się ręcznie przez własny obraz, a nie przez gotową pozycję w Marketplace.

Przy planowaniu architektury trzeba więc ustalić, jak podłączyć sieci publiczne i wewnętrzne, zabezpieczyć dostęp administracyjny oraz kto będzie odpowiadał za cykl życia maszyny wirtualnej. Obsługiwana lokalizacja instalacji nie odpowiada jeszcze na pytania o redundancję, przywracanie i monitorowanie.

W szczególności we własnym modelu operacyjnym nie można milcząco zakładać funkcji w pełni zarządzanej usługi chmurowej. Wirtualny firewall również wymaga planowej konserwacji i weryfikowalnych kopii zapasowych.

Alerty o zagrożeniach i mniejsze zmiany

Alerty NDR bez automatycznej izolacji

Wykrycia przez NDR Essentials i NDR Active Threat Intelligence mogą wywołać alert bez automatycznego izolowania danego urządzenia od sieci.

Wyraźniej oddziela to wykrywanie od reagowania. Może pomóc przy wprowadzaniu nowych źródeł detekcji: najpierw ocenia się jakość alertów, a dopiero potem określa, które zdarzenia powinny powodować blokadę. Różnice między tymi rozwiązaniami omawiamy w artykule o NDR Active Threat Intelligence.

Sam alert przynosi jednak korzyść tylko wtedy, gdy ktoś się nim zajmie. Muszą być określone odpowiedzialność, czas reakcji i droga eskalacji. Osobno należy też sprawdzić, które działania blokujące pozostają skonfigurowane w Active Threat Response. Zmiana sposobu alarmowania nie oznacza wyłączenia wszystkich działań ochronnych.

Listy zawartości poczty i kategorie internetowe

Pozostałe zmiany dotyczą odwołań opartych na identyfikatorach dla list zawartości poczty elektronicznej oraz wersjonowania kategorii internetowych.

W przypadku list zawartości poczty, czyli Content Control Lists, odwołanie jest oddzielone od widocznej nazwy. Nazwa pomaga ludziom zorientować się w konfiguracji, a stały identyfikator zapewnia jednoznaczne przypisanie. Wersjonowanie kategorii internetowych dotyczy natomiast synchronizacji definicji kategorii używanych w tle z Sophos.

Te punkty są mniej widoczne niż nowy interfejs, ale należą do pełnego przeglądu wydania. Przy zmianach konfiguracji i jej przywracaniu ważne jest, aby polityka nadal korzystała z zamierzonego obiektu. Z kolei dla filtrów internetowych znane dozwolone i zablokowane strony testowe powinny po aktualizacji nadal prowadzić do oczekiwanych decyzji.

Koniec obsługi eDirectory

Sophos Firewall v23 nie obsługuje już natywnego typu serwera eDirectory. Istniejące nadal połączenie z eDirectory uniemożliwia więc aktualizację. Alternatywami są Entra ID SSO, Active Directory, RADIUS albo połączenie LDAP z dotychczasowym serwerem eDirectory.

Ważne jest rozróżnienie między logowaniem a automatycznym rozpoznawaniem użytkowników: LDAP może uwierzytelniać użytkowników względem obecnego katalogu, ale nie zastępuje natywnego eDirectory SSO. Dotychczasowe połączenie z eDirectory nie zostanie również przeniesione przy przywracaniu kopii zapasowej lub imporcie konfiguracji.

Migrację i jej skutki dla użytkowników, grup oraz usług opisujemy w instrukcji Sophos Firewall: migracja eDirectory przed SFOS 23.

Podsumowanie

Moim zdaniem REST API to jedna z najbardziej użytecznych nowości w Sophos Firewall v23. Ułatwia powtarzalne zmiany i daje dobrą podstawę do analizy konfiguracji własnymi narzędziami. API pomaga także w analizach z użyciem AI: reguły i obiekty można odczytywać w uporządkowanej postaci, porównywać i badać pod kątem nieprawidłowości. O wynikających z tego zmianach nadal musi decydować administrator. Już samo zebranie i przygotowanie informacji może jednak oszczędzić wiele ręcznej pracy.

Podoba mi się także nowy przegląd reguł firewalla. Przynależność do grupy w kolumnie, swobodny wybór szczegółów i trwale zapisany widok ułatwiają pracę. Szkoda, że nie rozszerzono tej przebudowy na reguły NAT. Właśnie tam nadal brakuje grupowania i klonowania, choć przy tworzeniu i utrzymywaniu większych konfiguracji obie funkcje byłyby bardzo przydatne.

Chciałbym również zobaczyć więcej funkcji Sophos Firewall Config Studio bezpośrednio w firewallu: porównywanie kilku wersji konfiguracji, łączenie szablonów konfiguracji oraz raporty, które dla reguł firewall, NAT i TLS pokazują także wartości obiektów, do których te reguły się odwołują. Takie narzędzia pomagają rozumieć i przygotowywać zmiany. W tej postaci pozostają jednak dostępne tylko w osobnym Config Studio.

Jeśli chodzi o szybkość, w pierwszym teście nie zauważyłem istotnej poprawy. Zapisanie reguły firewalla nadal trwa kilka sekund. Przy pojedynczej zmianie nie ma to dużego znaczenia. Gdy jednak porządkuje się zestaw reguł i edytuje wiele z nich po kolei, czasy oczekiwania się sumują i stale przerywają pracę. Usprawnienia interfejsu są mile widziane. W codziennej pracy chciałbym przede wszystkim, aby częste zadania dało się wykonać szybciej, a regułami firewalla i NAT można było zarządzać w bardziej jednolity sposób.

FAQ

Źródła

• Sophos Firewall v23: zapowiedź wydania, ogłoszenie z 28 września 2026 r.
• Sophos Firewall OS v23: Key New Features, techniczny przewodnik po funkcjach, stan na 28 września 2026 r.
• Sophos Firewall v23: opinie i doświadczenia, bieżące opinie społeczności.