Przejdź do treści

Co dzieje się z pakietem po przejściu reguły? Jak Sophos XGS chroni ruch warstwa po warstwie

Nowoczesny firewall nie odpowiada tylko na pytanie „czy połączenie jest dozwolone?”. Musi też ocenić, co jest w środku, jaka aplikacja to generuje i czy sam wzorzec komunikacji nie wygląda podejrzanie.

Rafał Zieliński (Pre-Sales Cybersecurity Engineer, FEN)Opublikowano: Czas czytania: 8 min
Okładka artykułu: strumień ruchu sieciowego przechodzący przez pięć kolejnych warstw inspekcji, z jedną warstwą oznaczoną jako wykryte ryzyko.

Użytkownik otwiera stronę HTTPS. Reguła firewalla zezwala na połączenie z sieci biurowej do Internetu. Ruch przechodzi. Czy w tym momencie firewall skończył pracę?

W Sophos XGS decyzja o dopuszczeniu połączenia jest dopiero pierwszym pytaniem z kilku. Kolejne dotyczą tego, co znajduje się w środku sesji, jaka aplikacja ją wygenerowała, czy ktoś próbuje wykorzystać podatność, czy pobierany plik jest bezpieczny — i czy sam sposób komunikacji nie przypomina działania przeciwnika.

W tej części cyklu prześledzę te warstwy po kolei. Nie jako listę modułów, tylko jako sekwencję pytań zadawanych temu samemu przepływowi.

Zaszyfrowany strumień sieciowy przechodzący kolejno przez warstwy polityki dostępu, inspekcji TLS, IPS, aplikacji, ochrony WWW, analizy malware i detekcji zachowania.
Jedno połączenie może być oceniane przez kilka niezależnych mechanizmów — każdy odpowiada na inne pytanie o bezpieczeństwo ruchu.

1. Reguła firewall: czy ta komunikacja w ogóle może się odbyć?

Pierwsza warstwa jest najlepiej znana. XGS sprawdza źródło i cel, strefę, usługę, porę, a często również użytkownika, po czym dopasowuje regułę i ewentualnie wykonuje translację adresu.

Kluczowe jest jednak co innego — świadomość, że to pytanie ma ograniczony zakres. Reguła odpowiada wyłącznie na pytanie o uprawnienie do komunikacji. Nie mówi nic o zawartości sesji ani o intencji strony, która ją nawiązuje.

„Dozwolone” opisuje decyzję sieciową. Nie jest synonimem „bezpieczne”.

2. TLS Inspection: najpierw trzeba w ogóle zobaczyć ruch

Zdecydowana większość ruchu wychodzącego jest dziś szyfrowana. To dobra wiadomość dla poufności i zła dla widoczności: jeśli firewall nie może zajrzeć do sesji, kolejne warstwy analizy nie mają czego oceniać. Zostaje im adres docelowy, certyfikat i metadane połączenia.

TLS Inspection rozwiązuje ten problem modelem decrypt → inspect → re-encrypt. Ruch jest kontrolowanie odszyfrowywany, udostępniany pozostałym mechanizmom, a następnie ponownie zabezpieczany przed wysłaniem dalej.

Praktyka wymaga tu jednak rozsądku. Część ruchu nie powinna lub nie może być odszyfrowywana: bankowość, zdrowie, systemy używające pinningu certyfikatów czy aplikacje, których producent tego nie wspiera. Dlatego lista wyjątków jest równie ważnym elementem polityki jak sama inspekcja — i powinna być świadomą decyzją, a nie efektem kolejnych zgłoszeń do helpdesku.

Warto też właściwie ustawić ramy pojęciowe. TLS Inspection nie jest osobnym „produktem ochronnym”. Nic samodzielnie nie blokuje. Otwiera widoczność dla mechanizmów, które blokują.

Porównanie nieprzejrzystego tunelu HTTPS z ruchem po kontrolowanej inspekcji TLS, w którym widoczne są aplikacja, plik i sygnał próby ataku.
Szyfrowanie chroni poufność komunikacji, ale bez kontrolowanej inspekcji może również ukrywać to, co firewall powinien ocenić.

3. IPS: dozwolony port nie oznacza bezpiecznej sesji

Intrusion Prevention System odpowiada na inne pytanie: czy w dopuszczonym ruchu nie ma próby wykorzystania konkretnej podatności lub nadużycia protokołu.

Najprostszy przykład to serwer WWW publikowany na zewnątrz. Musi przyjmować połączenia HTTPS — to jego zadanie. Nie powinien natomiast przyjmować żądania skonstruowanego tak, by wywołać błąd w bibliotece, którą się posługuje. Z punktu widzenia reguły firewalla oba przypadki wyglądają identycznie. Dopiero IPS potrafi je rozróżnić.

Ta warstwa ma szczególne znaczenie tam, gdzie łatanie systemów jest trudne: przy systemach produkcyjnych, urządzeniach OT, starszych aplikacjach biznesowych. IPS nie zastępuje aktualizacji, ale bywa jedynym sensownym zabezpieczeniem w oknie między publikacją podatności a możliwością jej usunięcia.

4. Application Control: port 443 nie mówi już nic o aplikacji

Kontrola oparta na portach straciła znaczenie wtedy, gdy praktycznie wszystko przeniosło się na HTTPS. Dziś przez ten sam port przechodzi system ERP, komunikator, transfer plików do prywatnej chmury i narzędzie generative AI.

Application Control przenosi decyzję z pytania „jaki port?” na pytanie „jaka aplikacja i kto jej używa?”. To otwiera kilka praktycznych scenariuszy:

  • rozpoznanie Shadow IT — usług używanych w firmie bez wiedzy działu IT,
  • ograniczenie wybranych klas aplikacji, np. transferu plików czy zdalnego dostępu,
  • polityki różne dla różnych grup użytkowników zamiast jednej reguły dla całej sieci,
  • świadome decyzje wobec narzędzi AI — dopuszczenie wybranych, ograniczenie pozostałych.

Osobno warto wspomnieć Synchronized Application Control. Część ruchu nie daje się jednoznacznie zidentyfikować na podstawie samych pakietów. Informacja z Sophos Endpoint może uzupełnić ten obraz o wiedzę, jaki proces na stacji faktycznie wygenerował połączenie. Do tego, co dzieje się z tą wiedzą dalej, wrócę w części czwartej.

5. Web Protection: dokąd użytkownik idzie i co stamtąd wraca

Web Protection zajmuje się ruchem WWW z perspektywy użytkownika: kategoryzacją stron, reputacją domen i adresów, filtrowaniem URL, skanowaniem pobieranych treści oraz politykami przypisanymi do osób i grup, a nie tylko do adresów IP.

To warstwa, która najczęściej bywa sprowadzana do „blokowania rozrywki”. W praktyce jej wartość leży gdzie indziej: w zatrzymywaniu stron dystrybuujących malware, świeżo zarejestrowanych domen używanych w kampaniach phishingowych i witryn o złej reputacji, na które użytkownik trafia przez link w wiadomości.

6. DNS Protection: zatrzymać połączenie, zanim powstanie

Zanim komputer nawiąże jakiekolwiek połączenie, musi zapytać o adres. To najtańszy moment na interwencję — nie ma jeszcze sesji, transferu ani pliku do analizy.

DNS Protection pozwala blokować zapytania o domeny złośliwe lub niedozwolone przez politykę. Działa również tam, gdzie inspekcja treści jest utrudniona, a przy okazji daje dobry materiał do analizy: lista zablokowanych zapytań bywa pierwszą przesłanką, że na jakiejś stacji dzieje się coś nietypowego.

Najtańsze połączenie z zagrożeniem to takie, które nigdy nie zostało zestawione.

7. Malware Protection i Zero-Day Protection: ocenić sam obiekt

Tu przechodzimy z oceny techniki na ocenę obiektu. IPS pyta, czy ktoś próbuje wykorzystać podatność. Warstwa antymalware pyta, czy przesyłany plik jest bezpieczny.

Klasyczne skanowanie sygnaturowe odpowiada na pytanie „czy już to znamy?”. Problem w tym, że w ukierunkowanych kampaniach plik często jest nowy. Dlatego istotne są mechanizmy, które oceniają obiekt inaczej: analiza z użyciem uczenia maszynowego, badanie właściwości pliku oraz jego uruchomienie w izolowanym środowisku i obserwacja zachowania.

Warto zapamiętać podział ról: sygnatura mówi „to jest znane zagrożenie”, analiza dynamiczna mówi „ten obiekt zachowuje się jak zagrożenie”. Zakres dostępnych mechanizmów zależy od modelu licencyjnego, więc przed decyzjami architektonicznymi warto to zweryfikować dla konkretnego środowiska.

Jeden strumień sieciowy analizowany przez pięć różnych warstw odpowiadających reputacji domeny, aplikacji, exploitom, ryzyku pliku i anomaliom zachowania.
Warstwy ochrony nie powielają tego samego zadania — każda patrzy na ruch z innej perspektywy.

8. NDR: kiedy podejrzana jest nie treść, lecz zachowanie

Wszystkie dotychczasowe warstwy mają wspólną cechę: oceniają coś konkretnego — domenę, sesję, plik, żądanie. Istnieje jednak klasa działań, które w każdym pojedynczym połączeniu wyglądają całkowicie poprawnie, a dopiero jako wzorzec zaczynają budzić wątpliwości.

Regularne odpytywanie zewnętrznego serwera co kilka minut. Stacja robocza, która nagle skanuje zakres adresów wewnętrznych. Transfer, który wychodzi o nietypowej porze i w nietypowym kierunku. Żadne z tych zdarzeń nie zawiera złośliwego pliku ani exploita.

Na tym polu działają dwa uzupełniające się mechanizmy:

  • NDR Essentials — analiza ruchu z wykorzystaniem uczenia maszynowego, nastawiona na wykrywanie wskaźników zagrożeń i podejrzanych wzorców komunikacji,
  • NDR Active Threat Intelligence — sygnały wysokiej jakości oparte na wzorcach Taegis NDR/iSensor, logowane przez firewall i przesyłane do Sophos Data Lake, gdzie mogą zostać wykorzystane w analizie XDR/MDR.

Ważne zastrzeżenie: NDR nie zastępuje IPS ani analizy plików. Odpowiada na inne pytanie. Sygnatury i skanery pytają „co to jest?”. NDR pomaga odpowiedzieć „czy ten sposób komunikacji wygląda jak działanie przeciwnika?”.

9. Jeden przepływ, pełna ścieżka decyzji

Wróćmy do sesji HTTPS z początku artykułu i zobaczmy ją w całości:

  1. DNS — czy ta domena jest dozwolona i bezpieczna?
  2. Reguła firewall — czy to źródło może komunikować się z tym celem?
  3. TLS — czy możemy uzyskać widoczność, i czy w tym przypadku powinniśmy?
  4. IPS — czy w ruchu jest próba wykorzystania podatności?
  5. Application Control — jaka aplikacja to generuje i czy ten użytkownik może jej używać?
  6. Web / Malware / Zero-Day — czy treść i pliki są bezpieczne?
  7. NDR — czy wzorzec komunikacji nie wskazuje na aktywnego przeciwnika?

Nie każde środowisko uruchamia wszystkie te warstwy i nie każde musi. Ale warto wiedzieć, na którym etapie kończy się nasza analiza — bo to jednocześnie mówi, czego nie zobaczymy.

Pozioma oś pokazująca siedem etapów oceny ruchu od zapytania DNS, przez regułę, TLS, IPS i aplikacje, po analizę treści oraz zachowania sieciowego.
Od DNS po NDR — ten sam ruch może przejść przez kilka warstw oceny, zanim zostanie uznany za bezpieczny.

Źródła

Informacje zależne od wersji SFOS, licencji lub konkretnego modelu sprzętowego wymagają ponownej weryfikacji przed publikacją.