Sophos SFOS v18 – nowe funkcje w skrócie

Wraz z wersją SFOS v18 firma Sophos znacząco rozbudowała i przeprojektowała oprogramowanie układowe. W różnych obszarach dodano wiele nowych funkcji.

Warto zaznaczyć, że v18 nadal znajduje się w fazie wczesnego dostępu i część funkcji już uległa zmianie. Dzięki opiniom wielu użytkowników i partnerów Sophos rozwiązanie jest stale optymalizowane. W związku z tym część zrzutów ekranu w wersji GA może wyglądać nieco inaczej.

W tym wpisie skupiamy się wyłącznie na nowych funkcjach Sophos XG Firewall v18 i jedynie krótko wspominamy o konsoli webowej. Więcej informacji na ten temat znajduje się w innym artykule na blogu: Sophos Central Firewall Management – funkcje w SFOS v18

Deep Packet Inspection i architektura Xstream

Najważniejszą zmianą w Sophos Firewall SFOS v18 jest wprowadzenie Deep Packet Inspection (DPI). Do tej pory ruch – zwłaszcza webowy – był analizowany za pomocą proxy. Był to częsty punkt krytyki, zwłaszcza w świecie UTM, ponieważ XG Firewall nie filtrował ruchu HTTP/HTTPS bezpośrednio na zaporze, lecz za pośrednictwem oddzielnego proxy. Klienci, którzy już przeszli na XG, obserwowali, że użytkownicy byli blokowani, ponieważ proxy próbował uzyskać dostęp do uwierzytelniania użytkowników. Choć problem ten był widoczny głównie w większych środowiskach, często stanowił powód odkładania migracji z UTM na XG.

Ważne: proxy nadal istnieje w oprogramowaniu układowym i nie znika wraz z v18. Dzięki silnikowi DPI pojawia się jednak nowa możliwość inspekcji ruchu webowego.

Czym jest Deep Packet Inspection?

Bez Deep Packet Inspection zapora działa jak klasyczna zapora typu stateful inspection i sprawdza przede wszystkim informacje nagłówka oraz stan połączenia. Dzięki Deep Packet Inspection analizowana jest cała zawartość pakietu, co umożliwia dużo dokładniejsze filtrowanie ataków i złośliwego oprogramowania.

Silnik Xstream SSL/TLS Inspection

W ostatnich latach SSL/TLS zyskał ogromne znaczenie. Projekt „Let’s Encrypt” uprościł wydawanie darmowych certyfikatów i sprawił, że nawet prywatne strony internetowe są zazwyczaj szyfrowane. Wiele przeglądarek ostrzega już, gdy użytkownik otwiera stronę niezabezpieczoną.

Sophos zaleca zatem inspekcję ruchu SSL/TLS, aby zapewnić kompleksową ochronę HTTP. W obecnej formie funkcję tę należałoby raczej nazwać „SSL/TLS Inspection” niż „SSL (TLS) Inspection”, ale w branży wciąż często mówi się po prostu o SSL.

Zewnętrzne materiały na temat inspekcji SSL/TLS:

• Dlaczego inspekcja SSL jest obowiązkowa? – Część 1
• Dlaczego inspekcja SSL jest obowiązkowa? – Część 2
• Why Host a CA on Your XG Firewall with SFOS v18?

W wersji v18 inspekcja SSL jest obecnie zarządzana centralnie za pomocą profili deszyfrowania, a inspekcja jest wymuszana przez dedykowane reguły zapory.

Najważniejsze ustawienia można skonfigurować osobno dla każdego profilu deszyfrowania. Obejmuje to m.in. opcje pomijania określonego ruchu, na przykład gdy między klientem a serwerem skonfigurowano uwierzytelnianie wzajemne i zapora nie może zinspekcjonować certyfikatu.

Na pierwszy rzut oka ten obszar może wydawać się dość skomplikowany. Dla osób, które lubią zaglądać do dokumentacji, pomocny będzie artykuł w społeczności XG Firewall: SFOS v18: HTTPS Scanning and Xstream SSL Inspection

Niestety, w momencie pisania tego artykułu nie było jeszcze polskojęzycznej dokumentacji Sophos XG Firewall v18 w Central Partner Portal ani w pomocy przeglądarkowej Sophos XG (HV System). Można się jednak spodziewać, że w momencie publikacji tego wpisu będzie dostępnych więcej materiałów po angielsku: \https://docs.sophos.com

Silnik DPI

Oprócz silnika inspekcji SSL/TLS nowy silnik DPI stanowi drugi filar architektury Xstream. Przenosi on kilka kontroli bezpieczeństwa na poziom zapory, w tym Advanced Threat Protection, IPS oraz filtr aplikacji.

W przypadku ruchu webowego w wersji v18 można zdecydować, czy ma on być obsługiwany przez silnik DPI, czy przez proxy. W przypadku ruchu e‑mailowego konieczne jest na razie dalsze korzystanie z proxy. W przyszłych wersjach oprogramowania układowego Sophos planuje przeniesienie kolejnych grup przepływów z proxy do silnika DPI. Przynajmniej w przypadku SFOS v18 nacisk położono na ruch HTTP i HTTPS.

Silnik DPI przynosi również szereg korzyści wydajnościowych. Kilka przykładów przedstawiono w następnej sekcji.

Xstream FastPath

Architektura Xstream została zaprojektowana tak, aby zwiększyć wydajność. Zapora sprzętowa ma zawsze ograniczoną przepustowość, dlatego tak ważne jest, aby optymalizować ją we właściwych miejscach.

Urządzenie Sophos XG Firewall to tylko hardware – kluczowe jest to, jak efektywnie oprogramowanie układowe wykorzystuje ten appliance.

W architekturze Xstream każdy pakiet trafia najpierw do silnika DPI, niezależnie od tego, czy pochodzi z LAN, czy z WAN. Następnie przepływ sieciowy jest przekazywany do „FastPath”, zaimplementowanego w jądrze Linuksa. Jeśli silnik DPI stwierdzi, że dany przepływ można uznać za bezpieczny, przenosi go do FastPath i przekazuje dalej bezpośrednio przez kernel.

Patrząc na diagram architektury, pojawia się naturalne pytanie, jak dokładnie działa to w praktyce. Ustalenie, czy ruch jest zasadniczo dozwolony, można przeprowadzić stosunkowo szybko – nie trzeba powtarzać tego kroku dla każdego pakietu pochodzącego z tego samego źródła i portu. Jak jednak silnik DPI rozpoznaje, kiedy może przenieść przepływ do FastPath? Jeżeli na przykład aktywna jest inspekcja SSL/TLS, nie jest to możliwe, ponieważ ruch nie byłby już wówczas sprawdzany. Natomiast w przypadku IPS lub kontroli aplikacji wykorzystywane są znane listy, na podstawie których można zdecydować, czy dany strumień danych jest nieszkodliwy.

Threat Intelligence Analysis

Jeżeli moduł Sophos Sandstorm jest licencjonowany dla zapory, pliki są analizowane w sandboxie jeszcze przed ich pobraniem. Osoby zainteresowane szczegółami mogą zajrzeć do dokumentu PDF Sophos Sandstorm z najczęściej zadawanymi pytaniami. Dzięki inspekcji SSL/TLS zapora ma głębszy wgląd w ruch i może jeszcze dokładniej kontrolować pobierane pliki z sieci. Dodatkowo ochrona endpoint pozostaje ostatnią linią obrony.

W wersji v18 nowy moduł Threat Intelligence Analysis uzupełnia istniejący moduł Sandstorm. Podczas gdy Sophos Sandstorm analizuje pobierane pliki oraz załączniki e‑mail, Threat Intelligence bada pliki z wykorzystaniem uczenia maszynowego. Wykorzystywana jest również analiza SophosLabs, ta sama technologia, która stoi za Sophos Intercept X z EDR.

Podobnie jak w EDR, generowany jest szczegółowy raport analityczny. W SFOS v18 EAP2 raport taki może wyglądać na przykład tak:

Nieco bardziej dopracowana wizualnie wersja raportu będzie dostępna dopiero od EAP3.

Enterprise NAT

Oprócz architektury Xstream gruntownie przeprojektowano także reguły NAT. Do wersji 17.5 istniało menu „Firewall”, w którym grupowano wszystkie reguły zapory, NAT i WAF. W regule zapory można było zdefiniować m.in. interfejs wyjściowy lub adres IP używany jako źródło dla ruchu.

W wersji v18 reguły NAT są teraz zarządzane w osobnej zakładce, co znacznie zwiększa elastyczność administracji.

Na tę zmianę czekało wielu klientów: teraz możliwe jest na przykład blokowanie wszystkich zapytań DNS lub NTP kierowanych do publicznych serwerów i przekierowanie ich do serwera wewnętrznego. Rozwiązuje to również problem osób, którym brakuje serwera NTP w XG, jaki był wbudowany w UTM.

Temat NAT jest dodatkowo omówiony w poniższym materiale wideo:

Zarządzanie regułami zapory

Wraz z każdą główną wersją oprogramowania Sophos usprawnia obsługę reguł zapory. W wersji v18 można teraz zaznaczyć kilka reguł jednocześnie, aby je usunąć, włączyć lub wyłączyć, bądź dodać do grupy lub z niej usunąć. Dodatkowo reguły zapory są teraz numerowane, dzięki czemu łączna liczba jest od razu widoczna. ID reguły pozostaje niezmienione. Zmieniono również nazwę menu „Firewall” na „Rules and policies”.

Można także definiować filtry, co znacznie ułatwia wyszukiwanie konkretnych reguł. Filtr pozostaje aktywny nawet po przełączeniu do innych sekcji menu i powrocie do widoku reguł.

Ci, którzy mieli nadzieję, że Sophos pozostawi teraz grupy reguł otwarte po zapisaniu reguły, będą niestety rozczarowani. W tym zakresie nic się nie zmieniło. 😖

Dodano również często oczekiwaną funkcję: licznik ruchu przetworzonego przez daną regułę zapory można teraz zresetować do zera.

Przy tworzeniu nowej reguły zapory istnieje teraz możliwość zapisania jej początkowo w stanie wyłączonym.

Ponadto w regułach zapory można teraz definiować wykluczenia. Pomaga to utrzymać zestaw reguł w zwięzłej formie i uniknąć zbędnych dodatkowych wpisów.

Log Viewer

Osoby, które przeczytały artykuł 7 powodów, dla których zapora XG (SFOS) jest lepsza niż UTM, wiedzą, jak przydatny jest Log Viewer. W nowej wersji narzędzie to otrzymało kilka dodatkowych, praktycznych funkcji.

Jedno kliknięcie na wpis w Log Viewerze pozwala od razu ustawić filtr, zdefiniować wyjątek SSL/TLS lub dostosować politykę IPS, kontroli aplikacji czy filtra WWW.

Alerty i powiadomienia

W menu „Administration” > „Notification settings” można było dotychczas włączyć tylko dwie opcje powiadomień e-mail:

• IPsec tunnel up/down
• Email alert notifications

Jeżeli RED była niedostępna lub użytkownik zbyt często wpisywał błędne hasło, nie było do tej pory sposobu, by otrzymać o tym powiadomienie.

Usprawnienia: obecnie można szybciej i łatwiej łączyć urządzenia w klastry. Możliwe jest także wykonanie rollbacku oprogramowania układowego.

• Obsługa SNMPv3: wyraźnie wyższy poziom bezpieczeństwa niż w SNMPv1 i SNMPv2 – o ile w ogóle można mówić o „bezpieczeństwie” w przypadku tych wersji. Plik MIB jest, jak zwykle, dostępny do pobrania.
• Zmiana nazw interfejsów: dotychczas interfejsy nazywały się Port1, Port2 itd., bez możliwości ich zmiany. W wersji v18 można już dostosować te nazwy. W dalszym ciągu nie można natomiast zmieniać nazw IPsec, IPS, sieci bezprzewodowych itd.
• Aktualizacje bazy danych GeoIP: baza danych adresów IP krajów może być teraz aktualizowana niezależnie od aktualizacji oprogramowania układowego.
• Aktualizacja VMware Tools: VMware Tools są obecnie dostępne w wersji 10.3.10 i wspierają również Site Recovery Manager (SRM).

Aktualizacja do SFOS v18

Wymagania

Zastanawiają się Państwo nad aktualizacją do v18? Jeśli używają Państwo już XG Firewall lub SG z SFOS, potrzebują Państwo co najmniej wersji v17.5 MR6, aby przejść na v18. Tradycyjnie wspierany jest również rollback. Jeśli po aktualizacji do v18 coś nie będzie działało zgodnie z oczekiwaniami, zawsze mogą Państwo wrócić do poprzedniej wersji.

SG do XG

Jeśli nadal korzystają Państwo z zapory UTM, również mogą Państwo przejść na SFOS. Odpowiednią instrukcję znajdą Państwo tutaj: Instalacja Sophos XG Firewall OS na urządzeniu SG

Jeżeli potrzebują Państwo wsparcia przy migracji, chętnie pomożemy. Mamy na koncie wiele udanych migracji z systemów UTM. 😎

XG 85 i XG 105

Do instalacji v18 potrzebne są co najmniej 4 GB RAM. Nadchodząca wersja SFOS nie będzie już działać na modelach XG 85 i XG 105. Użytkownicy własnego sprzętu z 2 GB RAM staną przed tym samym problemem. Cyberoam również nie będzie już wspierany.

Właściciele XG 85 lub XG 105 powinni zainteresować się następcami tych modeli: Sophos XG 86 i XG 106. Obecnie (do 30.09.2020) trwa promocja Sophos, w ramach której przy odnowieniu licencji można otrzymać 50% rabatu na nowe urządzenie.

Sophos Central Firewall Reporting and Management

Na ten temat przygotowano osobny artykuł: Sophos Central Firewall Management – funkcje w SFOS v18

FAQ

Więcej informacji

• XG Firewall: What’s New in v18