Konfigurowanie ochrony sieci Web Sophos Firewall za pomocą zasad sieci Web

Ochrona sieci Web Sophos Firewall kontroluje, które strony internetowe, kategorie i treści internetowe mogą być dostępne dla użytkowników. W praktyce ochrona sieci Web nie jest po prostu jednym zaznaczeniem. Zasada sieci Web musi być fachowo zaplanowana, aktywowana w odpowiedniej regule zapory, a następnie przetestowana z rzeczywistym ruchem.

Wiele błędów wynika z tego, że zasada sieci Web istnieje, ale nie jest stosowana do żadnej aktywnej reguły zapory. Inne problemy związane są z HTTPS, inspekcją TLS, QUIC, rozpoznawaniem użytkowników, kolejnością reguł lub zbyt ogólnymi wyjątkami. Dlatego sensowny przebieg to: planowanie zasad, budowanie reguły, aktywacja, testowanie i monitorowanie w działaniu.

Który artykuł o ochronie sieci Web jest odpowiedni?

Ochrona sieci Web pokrywa się z regułami zapory, inspekcją TLS, QUIC, raportowaniem i wyjątkami. W zależności od zadania lepiej pasuje bardziej szczegółowy artykuł:

• Podstawowe konfigurowanie ochrony sieci Web i zasad sieci Web: Ten artykuł.
• Zrozumienie Single lub Dual Engine, błędów skanowania, limitów rozmiaru i rzeczywistego testu malware: Konfigurowanie i testowanie skanowania malware w Sophos Firewall.
• Analiza kategorii sieci Web, grup URL i alertów natychmiastowych: Wykorzystanie kategorii sieci Web Sophos Firewall i alertów natychmiastowych.
• Deszyfrowanie i sprawdzanie ruchu HTTPS: Wprowadzenie inspekcji TLS Sophos Firewall.
• Dystrybucja certyfikatu CA dla zarządzanych klientów: Dystrybucja certyfikatu CA Sophos Firewall dla inspekcji TLS.
• Klasyfikacja QUIC i HTTP/3 przy problemach z filtrowaniem sieci Web: Blokowanie protokołu QUIC i HTTP/3 w Sophos Firewall.
• Ustalanie, która reguła zapory i zasada faktycznie obowiązuje: Testowanie reguł Sophos Firewall za pomocą Log Viewer, Policy tester i Packet Capture.
• Dłuższa analiza zdarzeń sieci Web i bezpieczeństwa: Central Firewall Reporting lub Wysyłanie Syslog do SIEM.

W ten sposób analiza pozostaje czysta: najpierw musi być jasne, czy reguła zapory pasuje. Następnie sprawdza się zasadę sieci Web, kategorię, kontekst użytkownika, QUIC, inspekcję TLS i logowanie.

Co kontroluje ochrona sieci Web

Ochrona sieci Web składa się z kilku elementów. Nie każdy element musi być używany w każdym środowisku, ale zależności powinny być jasne.

• Zasada sieci Web: Zasady dotyczące dozwolonych, ostrzeganych, blokowanych lub opartych na kwotach dostępów do sieci Web.
• Kategorie sieci Web: Kategorie Sophos i własne kategorie dla stron internetowych.
• Grupy URL: Własne listy domen do precyzyjnych reguł zezwalania lub blokowania.
• Typy plików: Kontrola określonych typów pobierania lub plików.
• Filtry treści: Terminy lub wzorce do kontroli treści.
• Wyjątki: Precyzyjne wyjątki od zachowań sieci Web, TLS lub skanowania.
• Search engine enforcement: SafeSearch i ograniczenia YouTube.
• Advanced settings: ograniczenia domen logowania Google Apps i Microsoft Entra ID Tenant Restrictions.
• Logowanie i raportowanie: Śledzenie w Log Viewer, raportowanie, Central lub SIEM.

Ochrona sieci Web nie zastępuje solidnej bazy reguł zapory. Reguła zapory decyduje najpierw, jaki ruch z której strefy do której strefy docelowej jest dozwolony. Zasada sieci Web uzupełnia tę regułę o kontrolę sieci Web. Podstawy dotyczące kolejności reguł, źródła, celu, usług i profili bezpieczeństwa znajdują się w Zrozumienie i budowanie reguł Sophos Firewall.

Wymagania wstępne

Przed wdrożeniem należy wyjaśnić następujące kwestie:

• Ochrona sieci Web jest licencjonowana lub zawarta w używanym pakiecie.
• Dotknięte sieci klientów mają własne reguły zapory.
• Logowanie jest aktywne w odpowiednich regułach.
• DNS i czas na zaporze działają poprawnie.
• Rozpoznawanie użytkowników jest wyjaśnione, jeśli zasady mają obowiązywać dla użytkowników lub grup.
• Inspekcja TLS jest planowana, jeśli treści HTTPS mają być dokładniej sprawdzane.
• QUIC/HTTP/3 jest świadomie dozwolony lub blokowany.
• Istnieje grupa pilotażowa i ścieżka powrotna dla krytycznych stron biznesowych.

Szczególnie ważne jest rozdzielenie według grup docelowych. Zasada sieci Web dla zwykłych klientów, serwerów, gości, użytkowników VPN i systemów zarządzania nie powinna być taka sama. Serwery często potrzebują mniej kontroli przeglądania, ale bardziej rygorystycznych list celów i aktualizacji. Goście często potrzebują kategorii i ograniczeń przepustowości, ale nie dostępu do zasobów wewnętrznych.

Jeśli zasady sieci Web mają reagować na użytkowników lub grupy, rozpoznawanie użytkowników musi działać. AD SSO, Captive Portal, STAS, SATC lub inne metody nie powinny być odkrywane dopiero podczas wdrażania zasady sieci Web. W Log Viewer musi być widoczne, czy żądanie oceniono jako znanego użytkownika, grupę albo jako Anybody lub nieznanego użytkownika.

Kryteria użytkownika w pasującej regule zapory mają pierwszeństwo przed Users w zasadzie WWW; zasada może zawęzić zakres, ale nie doda użytkownika wykluczonego przez regułę.

Minimalna ścieżka skutecznej zasady

Utwórz zasadę w Web > Policies i włącz w niej co najmniej jedną precyzyjną decyzję Allow/Block.

Następnie edytuj rzeczywistą regułę w Rules and policies > Firewall rules, ustawiając Action: Accept, właściwe Source Zone i Source Network, Destination Zone i Destination Network oraz wymagane Services. Włącz Log firewall traffic i przypisz zasadę w Web filtering. Sprawdź jedynie, czy istniejący NAT odpowiada dotychczasowej ścieżce internetowej; nie twórz nowego zachowania NAT wyłącznie dla tej zasady. Przed zmianą zapisz Rule ID oraz wyniki tych samych świadomie dozwolonych i blokowanych żądań, a po zmianie powtórz je w rzeczywistym kontekście źródła i użytkownika. Odbierz zmianę dopiero, gdy Log Viewer pokaże oczekiwane Rule ID, zasadę oraz rzeczywiste wyniki Allow i Block.

Planowanie zasady sieci Web

Dobra zasada sieci Web nie zaczyna się w interfejsie, ale od kilku decyzji fachowych.

Definiowanie grup docelowych

Najpierw określa się, dla kogo zasada obowiązuje:

• Standardowi klienci w LAN
• Zarządzane notebooki przez VPN
• Sieć WLAN dla gości
• Sale szkoleniowe lub środowiska szkolne
• Serwery z wychodzącym dostępem HTTP/HTTPS
• Uprzywilejowane stanowiska administracyjne

Jeśli ta sama reguła zapory obejmuje kilka bardzo różnych grup, ochrona sieci Web staje się trudna do zrozumienia. Lepsze są oddzielne reguły i zasady, na przykład LAN_USERS_WEB, GUEST_WEB lub SERVER_UPDATES_WEB.

Ustalanie kategorii i grup URL

Kategoria highly objectionable criminal activity jest zawsze blokowana. Ani reguły zasad, ani wyjątki nie mogą zezwolić na tę kategorię; SFOS ukrywa też domenę w logach i raportach.

Kategorie sieci Web Sophos są dobre do szerokiej kontroli: złośliwe oprogramowanie, phishing, treści dla dorosłych, anonimizatory, streaming, media społecznościowe lub gry. Grupy URL są lepsze, gdy pojedyncze domeny mają być precyzyjnie dozwolone lub blokowane.

Typowe zastosowanie:

• Blokowanie znanych kategorii ryzyka: Kategoria sieci Web.
• Zezwalanie na określone domeny SaaS: Grupa URL.
• Obsługa pojedynczej błędnie sklasyfikowanej domeny: Grupa URL lub własna kategoria.
• Ograniczenie czasowe streamingu: Zasada sieci Web z harmonogramem lub kwotą.
• Strona ostrzegawcza zamiast twardego blokowania: Zasada sieci Web z akcją ostrzegawczą.

Grupy URL nie powinny stać się niesortowaną listą zbiorczą. Jeśli wiele domen jest wpisanych, lista potrzebuje właściciela, celu i daty przeglądu. Dla bardzo dużych lub dynamicznych list często bardziej sensowne są Sophos Firewall Threat Feeds lub inne elementy architektury.

Artykuł Tworzenie i bezpieczne używanie URL Groups wyjaśnia zależność między poprawnymi domenami, logiką OR, użyciem w Web Policy i wykluczeniami TLS.

Przy czystych dopasowaniach domenowych grupy URL są zwykle lepsze niż własne Web Categories. Sophos wskazuje, że grupy URL są wydajniejsze i mogą powodować mniej fałszywych trafień. Własne kategorie są przydatne, gdy domena ma dodatkowo występować w indywidualnej logice polityki obok standardowej kategorii Sophos.

Słów kluczowych we własnych kategoriach należy używać bardzo ostrożnie. Keywords są sprawdzane względem całego URL, łącznie ze ścieżką i zapytaniem. Zezwolenie oparte na słowie kluczowym może więc zadziałać niezamierzenie, jeśli słowo pojawi się w parametrze zapytania na innej domenie. Dla decyzji Allow zwykle czystsze są konkretne domeny lub grupy URL; reguły keyword pasują raczej do wąskich przypadków blokowania.

Ostrożne ustawianie reguł zezwalania

Reguły zezwalania w zasadach sieci Web powinny być wąskie. Reguła zezwalania wysoko w hierarchii może unieważnić późniejsze reguły blokowania, ponieważ zasady sieci Web Sophos są oceniane od góry do dołu. Jest to szczególnie istotne, gdy grupa URL, reguła typu pliku lub wyjątek kategorii znajduje się powyżej innych reguł.

Praktyczne podejście:

1. Specyficzne dozwolone wyjątki biznesowe na górze.
2. Krytyczne kategorie blokowania następnie.
3. Reguły ostrzegawcze lub kwotowe dla szarych obszarów.
4. Ogólnie dozwolony ruch sieci Web dopiero na końcu.

Tworzenie zasady sieci Web

Zasada sieci Web jest tworzona w następującym menu:

Web > Policies

Podstawowy przebieg:

1. Wybierz Add policy.
2. Nadaj nazwę opisową, na przykład LAN_USERS_STANDARD_WEB.
3. Dodaj reguły.
4. Sprawdź search engine enforcement, na przykład SafeSearch lub YouTube restrictions.
5. Ustaw policy quota status, jeśli używane są akcje Quota.
6. Sprawdź Advanced settings, zwłaszcza logging, reporting, duże pobrania, Google Apps oraz Microsoft Entra ID Tenant Restrictions.
7. Zapisz zasadę.

Regułę w ramach zasady sieci Web tworzy się przez Add rule. Zapora najpierw tworzy wyłączoną regułę domyślną, która blokuje HTTP dla Anybody. Następnie pola trzeba świadomie dostosować:

1. Otwórz Users i ustaw świadomie Anybody, konkretnych użytkowników lub grupy.
2. Otwórz Activities i wybierz All web traffic, User activities, Categories, URL Groups lub File types.
3. Dla treści wybierz oddzielną kartę Content filters, filtr, włącz and with content i pozostaw HTTPS jako Use action.
4. Ustaw Action dla HTTP: Allow, Warn, Block lub Quota.
5. Sprawdź akcję HTTPS: Use action, Allow HTTPS, Warn HTTPS, Block HTTPS lub Quota HTTPS.
6. Ustaw Constraints, jeśli reguła ma obowiązywać tylko według harmonogramu.
7. Sprawdź pozycję reguły w ramach zasady.
8. Włącz status reguły.
9. Zapisz zasadę.

Poprawne importowanie list filtrów treści

Content filters są zarządzane w Web > Content filters, a następnie wybierane w Activities w regule zasady sieci Web. W przypadku większych list terminów Sophos obsługuje prosty plik .txt. Plik może zawierać maksymalnie 2,000 wierszy, a każdy wpis może mieć najwyżej 80 znaków, łącznie ze spacjami i znakami interpunkcyjnymi.

Plik importu zawiera jeden termin w każdym wierszu, a każdy wiersz jest oceniany jako exact match. Nie należy umieszczać nagłówków, komentarzy, metadanych ani dodatkowych kolumn; użyj kodowania UTF-8.

Bezpieczny przebieg:

1. Oczyść terminy w edytorze tekstu i umieść dokładnie jeden wpis w każdym wierszu.
2. Zapisz plik jako .txt z kodowaniem UTF-8.
3. Zaimportuj listę w Web > Content filters i nadaj jej opisową nazwę.
4. W Activities otwórz Content filters, wybierz filtr, włącz and with content i zachowaj Use action.
5. Za pomocą klienta pilotażowego przetestuj jeden dozwolony termin i jeden celowo pasujący termin, a następnie sprawdź akcję w Log Viewer.

Jeśli import zostanie odrzucony lub poszczególne terminy nie zadziałają, najpierw sprawdź liczbę wierszy, długość znaków, kodowanie i niewidoczne znaki dodatkowe. Szeroka reguła Allow nad regułą Content filter nie może omijać listy.

Tworzenie własnych typów plików internetowych

Sophos Firewall rozpoznaje File types na podstawie rozszerzenia pliku lub nagłówka MIME. Wbudowanych typów nie można edytować. Własny typ tworzy się w Web > File types > Add z odpowiedniego szablonu, dodając wymagane rozszerzenia bez początkowej kropki albo nagłówki MIME. Ten sam obiekt można następnie stosować w zasadach ochrony stron internetowych i poczty elektronicznej.

W oknie Add należy podać nazwę. Pole Template jest opcjonalne i wstawia typowe rozszerzenia oraz nagłówki MIME danej kategorii; wartości dla własnego typu można uzupełnić. Następnie trzeba zapisać obiekt przyciskiem Save. Rozszerzenia wpisuje się bez początkowej kropki: pdf jest poprawne, a .pdf nie. Typy wbudowane służą jako wzorce i nie można ich edytować; zmiany wymagają utworzenia własnego typu.

SFOS udostępnia wbudowane kategorie All executable files, Audio files, Backup files, Compressed files, Configuration files, Database files, Developer files, Disk image files, Document files, Dynamic files, Encoded files, Executable files, Image files, Page layout files, Plugin files, System files, Video files i Web files. Widok szczegółów w Web > File types jest operacyjnym źródłem aktualnie zapisanych rozszerzeń i nagłówków MIME. Przykładowo Compressed files obejmuje między innymi 7z, gz, rar, tar.gz i zip, a Document files między innymi docx, xlsx, pptx, odt, rtf i pdf. Przed zezwoleniem na kategorię należy więc otworzyć konkretny typ wbudowany we własnej wersji SFOS i porównać go z rzeczywistym zastosowaniem, zamiast polegać wyłącznie na nazwie kategorii.

Nowy typ pliku sam w sobie nie wywołuje żadnego działania. Trzeba go wybrać w Activities > File types w odpowiedniej regule zasady sieci Web. Następnie należy sprawdzić akcję, stan i kolejność reguły oraz upewnić się, że zasada sieci Web nadal jest przypisana do reguły zapory, która rzeczywiście obsługuje ruch.

Walidacja obejmuje reprezentatywne pobranie oraz celowo podobny plik, który nie powinien zostać dopasowany. W Log Viewer sprawdza się zasadę sieci Web i akcję. Dopasowanie na podstawie rozszerzenia lub nagłówka MIME jest klasyfikacją zasad, a nie dowodem obecności malware ani wykonania analizy Zero-Day. W przypadku HTTPS wymagana widoczność zależy również od ścieżki TLS Inspection. Jeśli typ nie jest dopasowywany, należy najpierw porównać stan i kolejność reguły, faktycznie wybrany File Type, odpowiedź Content-Type serwera, widoczne rozszerzenie pliku oraz stan TLS Inspection. Błędny lub ogólny typ MIME zwracany przez serwer może sprawić, że wynik testu będzie inny, niż sugeruje nazwa pliku.

Przejrzyste łączenie User Activities

W Web > User activities > Add obiekt User activity łączy Web Categories, File types i URL Groups w aktywność wielokrotnego użytku. Elementy te są oceniane za pomocą OR; wystarczy jedno dopasowanie. Nazwa nie oznacza więc zalogowanego użytkownika, lecz zestaw kryteriów internetowych.

Następnie User Activity wybiera się w Activities w regule zasady sieci Web. Jest to przydatne, gdy ta sama kombinacja występuje w kilku zasadach. Podczas walidacji należy sprawdzić co najmniej jedno dopasowanie dla każdego zawartego typu obiektu oraz jeden podobny przypadek, który nie powinien pasować.

Sprawdzanie kolejności reguł i migrowanych zasad

Reguły zasad sieci Web są oceniane od góry do dołu. Jeśli na przykład reguła Allow dla typu pliku .mdb znajduje się nad regułą blokowania kategorii, pobieranie plików .mdb z tej kategorii pozostaje dozwolone. W trybie DPI początkowe połączenie z kategorią może zostać dopuszczone, dopóki typ pliku nie zostanie rozpoznany; jeśli plik następnie nie pasuje, zapora odrzuca połączenie bez wyświetlania strony blokady. Jeżeli kategoria ma być zawsze blokowana, jej reguła musi znajdować się nad regułą Allow typu pliku.

Dla migrowanych starych zasad obowiązuje również twardy limit 128 reguł na zasadę. Jeśli źródło zawiera więcej reguł, SFOS używa tylko pierwszych 128. Sąsiadujące reguły dla User Activities, Categories, URL Groups, File types i Dynamic Categories należy więc świadomie połączyć w kombinowane Activities przed migracją lub po niej. Liczba i kolejność reguł oraz rzeczywiste testy Allow i Block są częścią walidacji migracji.

Cykliczne przedziały czasu tworzy się jako osobny harmonogram. Przebieg i różnicę względem reguły zapory sterowanej czasem opisano w artykule Konfiguracja harmonogramów reguł i zasad na Sophos Firewall.

Sama zasada sieci Web jeszcze nie działa. Zasada musi być następnie użyta w regule zapory. To jeden z najczęstszych błędów konfiguracyjnych.

Aktywacja zasady sieci Web w regule zapory

Reguła zapory znajduje się pod:

Rules and policies > Firewall rules

Dla normalnego ruchu internetowego klientów zazwyczaj odpowiedzialna jest reguła z LAN lub strefy klienta do WAN. Tam w sekcji Web filtering wybiera się odpowiednią zasadę sieci Web.

Punkty kontrolne w regule zapory:

• Strefa źródłowa i sieci źródłowe pasują do sieci klienta.
• Strefa docelowa to zazwyczaj WAN.
• Usługi zawierają HTTP/HTTPS lub pożądane usługi sieci Web.
• Log firewall traffic jest aktywne.
• W sekcji Web filtering ustawiona jest właściwa zasada sieci Web.
• Scan HTTP and decrypted HTTPS jest aktywne, jeśli ma działać skanowanie malware lub treści web.
• Use Zero-day protection ma sens tylko wtedy, gdy pliki są skanowane przez HTTP lub odszyfrowany HTTPS.
• Block QUIC protocol jest świadomie ustawione.
• Na przezroczystej ścieżce reguły zapory opcja Use web proxy instead of DPI engine jest włączona dla SafeSearch, YouTube Restrictions i ograniczeń Google Apps; dla innych funkcji oraz Direct Proxy tryb wybiera się świadomie według potrzeb.
• Inspekcja TLS jest planowana oddzielnie i nie mylona z zasadą sieci Web.

Sophos Firewall domyślnie ustawia Block QUIC protocol, gdy w regule wybrano zasadę sieci Web albo włączono Scan HTTP and decrypted HTTPS. Często ma to sens, ponieważ QUIC nie może być skanowany jak klasyczny ruch HTTPS. Mimo to opcję trzeba przetestować świadomie: przeglądarki, usługi Google, narzędzia współpracy i pojedyncze aplikacje SaaS mogą zmienić zachowanie po zablokowaniu QUIC.

Jeśli w tej samej regule zapory używany jest również Application Control, istnieje ważne nakładanie się funkcji: niektóre Micro Apps, na przykład przesyłanie lub pobieranie w Dropbox albo Gmail, są rozpoznawane przez szczegóły URL. W środowiskach DPI wymaga to odpowiedniej reguły SSL/TLS Inspection z deszyfrowaniem. Application Control może wtedy oceniać takie Micro Apps nawet wtedy, gdy sama zasada sieci Web nie jest głównym punktem decyzji.

Jeśli bardziej ogólna reguła znajduje się powyżej pożądanej reguły sieci Web, ruch nie osiąga zasady sieci Web. W takich przypadkach pomocne jest Testowanie reguł Sophos Firewall za pomocą Log Viewer i Packet Capture.

Klasyfikacja HTTPS, inspekcji TLS i QUIC

Duża część ruchu sieci Web to HTTPS. Bez inspekcji TLS zapora widzi mniej treści. Kategorie, SNI, certyfikaty, adresy IP docelowe, informacje o domenach i metadane pomagają, ale nie zastępują pełnej inspekcji treści.

DPI czy Web Proxy?

Przy ochronie sieci Web trzeba wcześnie zdecydować, czy dotknięta reguła zapory używa DPI Engine czy Web Proxy. Ta decyzja wpływa na to, które funkcje działają i które logi są później istotne.

• Tryb DPI: nowoczesny standard dla wielu reguł internetowych klientów. Inspekcja TLS działa przez reguły inspekcji SSL/TLS, kwoty nie są obsługiwane.
• Tryb Web Proxy: Środowiska z zachowaniem proxy lub kwotą polityki. Zachowanie proxy, kompatybilność przeglądarek/klientów i logi proxy należy świadomie sprawdzić.

W wielu instalacjach tryb DPI jest lepszym punktem wyjścia. Jeśli jednak potrzebne są limity czasowe przez Quota, sama reguła DPI nie wystarczy. Wtedy tryb Web Proxy musi być świadomie zaplanowany i przetestowany. Ta decyzja powinna zapaść przed wdrożeniem, ponieważ późniejsza zmiana może generować inne problemy, logi i doświadczenia użytkowników.

W przezroczystej regule zapory Transparent Web Proxy obsługuje tylko klasyczne porty 80 i 443. Na innych portach DPI Engine może sprawdzać ruch HTTP i SSL/TLS, jeśli pasują zarówno reguła zapory, jak i reguły SSL/TLS Inspection. Direct Proxy jest natomiast osobną, jawną ścieżką wybieraną przez klienta i nie musi wymagać opcji Use web proxy instead of DPI engine. Dlatego przy każdym teście należy zapisać, czy klient używa ścieżki przezroczystej, czy jawnej konfiguracji proxy.

Pełny wybór funkcji, migrację pilotażową i testy właściwe dla danego trybu opisano w artykule Prawidłowe porównanie DPI Engine i Web Proxy.

Artykuł Konfiguracja Direct Web Proxy z plikiem PAC wyjaśnia, jak połączyć listener, plik PAC, Device Access i działającą regułę proxy.

Klienci tylko IPv6 uzyskujący dostęp do celów WWW tylko IPv4 korzystają z osobnej ścieżki dwóch reguł. NAT64 z Direct Web Proxy oddziela Web Policy w regule IPv6 od Application Control i IPS w egressie IPv4.

Jeśli Sophos Firewall ma przekazywać Web Requests do parent proxy, konfiguracja upstream proxy w WAN lub LAN/DMZ prowadzi przez właściwą ścieżkę reguł i NAT dla każdej topologii.

Gdy wielu użytkowników RDS współdzieli ten sam adres IP serwera, Per-Connection AD SSO dla hostów wielu użytkowników może rozróżniać poszczególne połączenia HTTP i HTTPS przez proxy. Metoda nie obejmuje ruchu spoza proxy, dlatego trzeba ją świadomie rozgraniczyć względem SATC.

Inspekcja TLS

Jeśli pobieranie, skanowanie złośliwego oprogramowania, określone kategorie sieci Web lub kontrola treści mają być niezawodnie sprawdzane, inspekcja TLS musi być zaplanowana. Wymaga to zaufanego certyfikatu CA na klientach, odpowiednich reguł TLS, wyjątków i czystego pilota.

Wdrożenie opisano w Stopniowe wdrażanie inspekcji TLS na Sophos Firewall. Do dystrybucji i walidacji certyfikatu CA pasuje Instalacja certyfikatu CA Sophos Firewall dla skanowania HTTPS.

QUIC i HTTP/3

Nowoczesne przeglądarki często używają QUIC lub HTTP/3 przez UDP 443. Może to zakłócać oczekiwania dotyczące filtrowania sieci Web, inspekcji TLS i skanowania, jeśli chce się faktycznie sprawdzać klasyczny ruch HTTPS przez TCP.

W wielu środowiskach korporacyjnych warto blokować QUIC w regułach internetowych klientów, aby przeglądarki wracały do HTTPS przez TCP. Szczegóły znajdują się w Blokowanie protokołu QUIC i HTTP/3 w Sophos Firewall.

SafeSearch, YouTube i ograniczenia Tenant

SafeSearch i YouTube znajdują się w Search engine enforcement, a Google Apps i Entra w Advanced settings.

Typowe opcje:

• Enforce SafeSearch dla Google, Yahoo i Bing.
• Enforce YouTube restrictions dla ograniczonych treści YouTube.
• Restrict login domains for Google Apps dla dozwolonych domen Google.
• Apply Microsoft Entra ID tenant restrictions dla kontroli tenantów w chmurze Microsoft.

Na przezroczystej ścieżce reguły zapory SafeSearch, YouTube Restrictions i Google Apps wymagają Use web proxy instead of DPI engine; jawny Direct Proxy może realizować te funkcje bez tej opcji reguły zapory. Bing i Yahoo przez HTTPS wymagają dodatkowo HTTPS scanning. Entra Tenant Restrictions należy traktować osobno, testować przy użyciu rzeczywistych logowań Microsoft i zachować odrębne zarządzanie tożsamością oraz aplikacjami chmurowymi w Microsoft 365 lub Google Workspace.

W Bing i Yahoo SafeSearch można wymusić na połączeniach HTTPS tylko wtedy, gdy HTTPS scanning jest aktywny w danej regule zapory. Ograniczenia logowania Google Apps dotyczą tylko domen hostowanych przez Google. Microsoft Entra ID Tenant Restrictions wymagają poprawnych wartości tenantów i powinny być testowane z rzeczywistymi logowaniami do chmury Microsoft, nie tylko z przykładowym URL.

Kwoty i strony ostrzegawcze

Zasady sieci Web mogą nie tylko blokować lub zezwalać. Dzięki akcjom ostrzegawczym lub kwotowym można świadomie informować użytkowników lub zezwalać na dostęp czasowy.

Przykłady zastosowań:

• Użytkownicy mogą świadomie potwierdzić ostrzeżenie dla określonych szarych obszarów.
• Streaming lub zakupy są dozwolone tylko czasowo.
• Środowiska szkolne lub laboratoryjne zezwalają na określone kategorie tylko w określonych godzinach.

Ważne: kwoty polityki nie są obsługiwane w trybie DPI. Jeśli potrzebne są limity czasowe, należy użyć trybu Web Proxy. Decyzję tę trzeba podjąć na wczesnym etapie, ponieważ tryby DPI i Web Proxy mają różne właściwości i ograniczenia.

Allowed time quota ustawia się na poziomie zasady sieci Web i obowiązuje ona wszystkie reguły w tej zasadzie, które używają akcji Quota. Jeśli dwie kategorie wymagają różnych limitów czasu, oddzielne zasady sieci Web są czystsze niż jedna zasada z mieszanymi oczekiwaniami dotyczącymi kwot. Kwoty resetują się lokalnie o północy i nie można ustawić ich na zero.

Policy Quota nie dotyczy Content filters ani Dynamic Categories i nie działa w DPI. Zmiana nie zadziała przy nieważnej zasadzie, braku pozostałego czasu ani aktywnej sesji Quota.

Ta Policy Quota dotyczy kategorii WWW i nie jest opartym na użytkowniku limitem Surfing Quota. Tworzenie, przypisywanie i kontrola zużycia Surfing Quota i Network Traffic Quota odbywają się w osobnej procedurze.

Sprawdzanie Policy Quota podczas pracy

W Web > Policy quota status SFOS pokazuje dla poszczególnych użytkowników czas pozostały w odpowiednich Web Policies w okresie 24 godzin. Wybranego użytkownika można tam zresetować przyciskiem Reset. Jest to celowa zmiana stanu, a nie przycisk diagnostyczny: najpierw dokumentuje się użytkownika, politykę, pozostały czas, powód i godzinę.

Ten reset dotyczy czasowej Policy Quota kategorii internetowej. Nie jest tym samym co Reset user accounting dla Surfing Quota lub Network Traffic Quota. Reset nie naprawia błędnej kolejności reguł ani braku identyfikacji użytkownika.

Dostosowanie stron ostrzeżeń i blokad

W Web > User notifications można skonfigurować własne obrazy oraz komunikaty blokady, override, quota i ostrzeżenia. Symbole zastępcze {category}, {user} i {url} wstawiają kategorię internetową, nazwę użytkownika i zablokowany URL. Preview sprawdza wygląd i tekst, ale nie potwierdza, że właściwa Web Policy i reguła firewalla pasują do produkcyjnego żądania.

Komunikat powinien krótko wyjaśniać, dlaczego dostęp został zablokowany lub objęty ostrzeżeniem i gdzie zgłosić uzasadnioną potrzebę biznesową. Nazwy użytkowników i adresy URL mogą zawierać wrażliwe informacje, dlatego strona nie powinna zawierać wewnętrznych tajemnic, haseł ani zbędnych danych kontaktowych.

Bezpieczne ograniczenie Policy Overrides

Policy Overrides to inne narzędzie niż kwoty. Po włączeniu Enable policy override uprawnieni użytkownicy mogą w User Portal utworzyć tymczasowy dostęp do normalnie blokowanych stron. Authorized users and groups ogranicza osoby uprawnione, a Blocked websites and categories definiuje cele, których nigdy nie można obejść. Allow manual access code entry włącza się tylko wtedy, gdy kody tworzone przez użytkowników pasują do procesu zatwierdzania.

W Web > General settings > Policy overrides najpierw udokumentować poprzedni stan i uprawnionych użytkowników. Uprawniony użytkownik określa w User Portal strony lub kategorie, ograniczony przedział czasu i kod dostępu dla override. Przy żądaniu pasującego zablokowanego celu strona blokady zawiera dodatkowe pole na ten kod. Gdy Allow manual access code entry jest włączone, wskazani użytkownicy mogą tworzyć własne kody; gdy opcja jest wyłączona, muszą korzystać z kodów generowanych. Nie należy mylić tej decyzji z wpisywaniem już ważnego kodu na stronie blokady.

View overrides pozwala wyświetlać, włączać, wyłączać i usuwać istniejące overrides. W ramach odbioru uprawniony użytkownik testowy powinien otworzyć pasujący cel w określonym przedziale czasu z ważnym kodem; bez kodu, poza tym przedziałem i dla celu, którego nigdy nie wolno udostępnić przez override, nadal musi działać normalna blokada. W Log Viewer porównać użytkownika, Rule ID, politykę WWW, akcję i czas. W HTTPS strona blokady musi dać się wyświetlić; samo przerwanie połączenia nie zapewnia pola na kod.

Przy wycofaniu wyłączyć pilotażowy override przez View overrides i nowym żądaniem sprawdzić pierwotną blokadę. Dopiero potem usunąć niepotrzebny override i przywrócić wyłącznie globalne wartości zmienione w pilotażu do udokumentowanego stanu poprzedniego. Nie usuwać zbiorczo istniejących overrides innych użytkowników.

Dla użytkowników AD funkcja My policy overrides uwzględnia tylko grupę główną i poszczególnych użytkowników, a nie inne członkostwa w grupach. Pasująca reguła inspekcji SSL/TLS z Action > Deny nadal ma pierwszeństwo. Jeśli zatwierdzony override musi w takiej sytuacji działać, planuje się wąsko ograniczoną Web Exception pomijającą deszyfrowanie HTTPS i osobno testuje przypadek negatywny; reguła TLS nie jest ogólnie osłabiana.

Web Exceptions i wyjątki TLS

Pominięcie HTTPS decryption usuwa zależne kontrole i dopuszcza nieważne certyfikaty serwera; Malware and content scanning automatycznie pomija Zero-day protection. Konkretny wzorzec nazwy hosta może zostać dopasowany już w kontekście TLS, natomiast sama ścieżka URL jest widoczna tylko w HTTP lub w już odszyfrowanym HTTPS. URL Group nie jest kryterium Web Exception.

Web Exceptions są silnym narzędziem i dlatego są niebezpieczne jako szybka naprawa. Wyjątek pod Web > Exceptions może pomijać kontrole ochrony dla pasującego ruchu niezależnie od aktualnie obowiązującej zasady sieci Web. W zależności od wyboru pomijane są HTTPS decryption, HTTPS certificate validation, Malware and content scanning, Zero-day protection lub Policy checks.

W środowiskach DPI obowiązuje ważne ograniczenie: Web Exceptions działają tylko wtedy, gdy ustawiona jest zasada sieci Web, aktywne jest Malware and content scanning albo aktywny jest ATP. SSL/TLS Exclusion Rules są natomiast właściwym miejscem, gdy chodzi wyłącznie o niewykonywanie deszyfrowania określonych połączeń TLS. Różnica operacyjna jest istotna:

• SSL/TLS Exclusion Rule: celowo wyłącza połączenia TLS z deszyfrowania, zwykle z powodu Certificate Pinning lub niezgodności.
• Web Exception: może pominąć kontrole zasady sieci Web, skanowanie malware, analizę Zero-Day lub walidację certyfikatów.
• URL Group in Web Policy: steruje Allow, Warn, Block lub Quota w normalnej logice zasady.

Dla wyjątków unikaj domen głównych i zbyt szerokich wzorców regex. Używaj konkretnych hostnames i jasnego zakresu według źródła, celu, kategorii lub grupy użytkowników; grupy URL pozostają w normalnej logice zasady WWW.

Wyjątki łączą różne kryteria przez AND. W ramach jednego typu kryterium, na przykład kilku URL Patterns, obowiązuje natomiast OR. Jest to praktyczne, ale podatne na błędy: wyjątek z URL Pattern i Source IP działa tylko wtedy, gdy pasują oba elementy. Wyjątek z wieloma URL Patterns może natomiast działać znacznie szerzej niż oczekiwano.

Szczególną ostrożność należy zachować przy Policy checks. Jeśli Web Exception pomija Policy checks, może pośrednio osłabiać także inne decyzje reguł. W połączeniu z Synchronized Security Heartbeat taki wyjątek może sprawić, że żądania web nie będą blokowane zgodnie z oczekiwaniem, mimo że kontrole Heartbeat są ustawione w regule zapory.

Testowanie ochrony sieci Web

Po zapisaniu nie należy tylko sprawdzać, czy zasada istnieje. Kluczowe jest, czy działa dla rzeczywistego ruchu.

1. Użycie Policy Tester

Dokładna ścieżka to Diagnostics > Tools > Pop-out tools > Policy tester. Tryb Firewall, SSL/TLS, and web testuje połączoną ścieżkę przezroczystą, a Web policy only izoluje decyzję zasady sieci Web. Test obejmuje wyłącznie przezroczysty dostęp do sieci Web, nie uwzględnia tras SD-WAN i nie przyjmuje Source Networks z adresami MAC. Jeśli protokół nie zostanie podany, używa HTTP; jeśli nie zostanie podany port, używa standardowego portu wybranego protokołu.

Przed zmianą uruchom oba odpowiednie tryby jako punkt odniesienia i zapisz wynik oraz oczekiwane Rule ID, a po zmianie powtórz identyczne testy. Policy Tester pozostaje testem wstępnym i nie zastępuje rzeczywistych prób Allow i Block z klienta pilotażowego, ponieważ NAT, inspekcja TLS, QUIC, routing lub jawna ścieżka Direct Proxy mogą inaczej obsłużyć rzeczywisty przepływ.

2. Test rzeczywisty z klientem pilotażowym

Z klientem pilotażowym sprawdź:

• dozwolona strona biznesowa
• zablokowana kategoria
• ostrzegana kategoria
• URL Group Allow
• URL Group Block
• strona HTTPS z i bez inspekcji TLS
• pobieranie nieszkodliwego typu pliku testowego
• zachowanie z aktywnym lub zablokowanym QUIC

3. Sprawdzenie Log Viewer

W Log Viewer powinno być widoczne:

• która reguła zapory została trafiona
• który użytkownik został rozpoznany, jeśli to istotne
• która kategoria sieci Web lub grupa URL była zaangażowana
• czy HTTPS, inspekcja TLS lub skanowanie złośliwego oprogramowania były zaangażowane
• czy akcja była dozwolona, ostrzegana czy zablokowana
• czy zadziałał Web Exception lub TLS Exclusion
• czy pobieranie zostało potraktowane inaczej z powodu rozmiaru, błędu skanowania malware lub analizy Zero-Day

W przypadku Syslog lub SIEM sam URL i action nie wystarczają. Do wiarygodnej analizy potrzebne są również Firewall Rule ID, użytkownik, kategoria, zasada sieci Web, metoda HTTP, status, wynik skanowania, wskazanie wyjątku i odniesienie SSL/TLS. Jeśli tych pól brakuje w SIEM albo są źle normalizowane, ochrona sieci Web w raportach szybko wygląda mniej jasno niż rzeczywiście działa na zaporze.

Dla głębszego rozwiązywania problemów istotne są również pliki dziennika. Przypisanie znajduje się w Rozwiązywanie problemów z Sophos Firewall: Usługi i logi.

Alerty natychmiastowe i raportowanie

Jeśli określone kategorie mają być nie tylko blokowane, ale także aktywnie zgłaszane, alerty natychmiastowe mogą być przydatne. Jest to szczególnie użyteczne w szkołach, ściśle regulowanych środowiskach lub obszarach z jasną polityką korzystania z Internetu.

Trzy ścieżki analizy odpowiadają na różne pytania:

• Szybki e-mail przy kilku wrażliwych kategoriach sieci Web: Alerty natychmiastowe.
• Powtarzające się raporty, trendy i analizy użytkowników lub kategorii: Central Firewall Reporting.
• Dłuższe przechowywanie, korelacja z innymi systemami lub procesy SOC: Syslog lub SIEM.

Przed alertami natychmiastowymi powinno być jasne, kto otrzymuje powiadomienie, które kategorie naprawdę wywołują reakcję, jak traktowane są fałszywe alarmy i kiedy przeglądana jest lista kategorii. Szeroka lista alertów bez właściciela szybko generuje szum e-mailowy, ale nie poprawia bezpieczeństwa.

Do technicznej aktywacji i triage pasuje Wykorzystanie kategorii sieci Web Sophos Firewall i alertów natychmiastowych. Dla długoterminowych analiz warto sprawdzić Central Firewall Reporting lub Wysyłanie Syslog do SIEM Sophos Firewall.

Zarządzanie zmianami i wyjątkami w działaniu

Ochrona sieci Web zmienia się w działaniu na bieżąco. Pojawiają się nowe usługi SaaS, pojedyncze domeny są błędnie klasyfikowane, działy potrzebują tymczasowego dostępu, a zachowanie przeglądarek się zmienia. Bez jasnego przebiegu szybko powstają szerokie wyjątki, których później nikt nie potrafi wyjaśnić.

Dla każdej zmiany należy przynajmniej zanotować:

• Kto potrzebuje dostępu? zapobiega globalnym wyjątkom dla kilku użytkowników.
• Jaka domena, kategoria lub typ pliku jest dotknięty? oddziela grupę URL, kategorię sieci Web i typ pliku czysto.
• Czy to wyjątek tymczasowy czy trwały? wymusza przegląd zamiast trwałych cieniowych zezwoleń.
• Która reguła zapory i zasada sieci Web są dotknięte? zapobiega zmianom w niewłaściwej regule.
• Jak będzie testowane? czyni sukces widocznym w Log Viewer.

Sprawdzony mały przebieg zmian:

1. Zarejestruj żądanie z użytkownikiem, URL, czasem, powodem biznesowym i zrzutem ekranu lub komunikatem o błędzie.
2. W Log Viewer sprawdź, która reguła zapory, zasada sieci Web, kategoria i akcja zadziałały.
3. Zdecyduj, czy kategoria jest zasadniczo błędna, czy tylko pojedyncza domena ma być zwolniona, czy żądanie ma być odrzucone.
4. Jeśli potrzebny jest wyjątek, pracuj jak najwężej: pojedyncza grupa URL zamiast całej kategorii, pojedyncza grupa użytkowników zamiast całego LAN.
5. Sprawdź zmianę w regule testowej lub grupie pilotażowej.
6. Po zapisaniu przeprowadź test rzeczywisty i udokumentuj Log Viewer, kategorię, ID reguły i kontekst użytkownika.
7. Ustaw datę przeglądu, szczególnie dla tymczasowych wyjątków biznesowych.

Tymczasowe wyjątki powinny być jasno nazwane, na przykład TMP_ALLOW_vendor-portal_until_2026-07-31. Trwałe wyjątki biznesowe również potrzebują właściciela. Jeśli nikt nie jest odpowiedzialny za wyjątek, nie powinien on pozostawać trwale w zasadzie.

Jeśli wiele pojedynczych domen powstaje dla tej samej usługi, problemem często nie jest zasada sieci Web, ale architektura usługi. Wtedy warto sprawdzić, czy lepiej pasuje własna reguła zapory, własna zasada sieci Web, starannie utrzymana grupa URL lub inny punkt kontrolny. Dla dynamicznych list IOC lub blokad wyjątki w zasadach sieci Web są zazwyczaj niewłaściwym miejscem; lepiej pasują Sophos Firewall Threat Feeds.

Wycofanie i awaryjne zezwolenie

Zmiana zasady sieci Web może natychmiast wpłynąć na produktywną pracę. Dlatego przed większymi zmianami należy ustalić, jak przywrócić stary stan.

Praktyczne opcje wycofania:

• zduplikuj lub udokumentuj dotkniętą zasadę sieci Web przed zmianą
• najpierw przetestuj zmianę w regule pilotażowej lub małej grupie użytkowników
• nie usuwaj od razu starej reguły zapory lub starej zasady sieci Web
• zdefiniuj okno czasowe, użytkowników testowych i kryterium powrotu
• po zapisaniu sprawdź Log Viewer, ID reguły i decyzję kategorii

W przypadku nagłych blokad nie należy odruchowo wstawiać szerokiej reguły zezwalania na górze. Lepiej jest zastosować wąski, czasowo ograniczony wyjątek z jasną grupą URL, grupą użytkowników i datą przeglądu. Jeśli presja jest wysoka, tymczasowy wyjątek może ustabilizować działanie, ale musi być później ponownie oceniony.

Typowe błędy

Zasada sieci Web nie działa

Najczęściej zasada nie jest aktywowana w odpowiedniej regule zapory, reguła nie jest trafiona, reguła wyżej pozwala na ruch lub kontekst użytkownika nie pasuje. Najpierw sprawdź Log Viewer i ID reguły.

HTTPS nie jest blokowany zgodnie z oczekiwaniami

Bez inspekcji TLS zapora widzi mniej szczegółów. W zależności od celu decyzja dotycząca domeny lub kategorii może działać, podczas gdy inspekcja treści, typy plików lub określone funkcje wyszukiwania są ograniczone.

Jeśli połączenie nie jest deszyfrowane, zapora nadal może używać informacji SNI lub domenowych do decyzji polityki. Strony blokady, strony ostrzegawcze, typy plików, Content Filters, skanowanie malware i analiza Zero-Day wymagają jednak większej widoczności. Dlatego w Log Viewer należy sprawdzić nie tylko akcję zasady sieci Web, ale także status SSL/TLS Inspection.

QUIC omija oczekiwania

Jeśli przeglądarki używają UDP 443, ruch może być przetwarzany inaczej niż klasyczny HTTPS przez TCP. W regułach klientów należy świadomie zdecydować, czy QUIC jest blokowany.

Reguła zezwalania jest zbyt wysoko

Szeroka reguła zezwalania na początku zasady sieci Web może unieważnić późniejsze reguły blokowania. Kolejność reguł w ramach zasady sieci Web jest równie ważna jak kolejność reguł na liście reguł zapory.

Zbyt wiele wyjątków

Wyjątki szybko rozwiązują pojedynczy problem, ale mogą osłabić ochronę. Każdy wyjątek potrzebuje celu, właściciela i daty przeglądu. Jeśli powstaje wiele wyjątków, często struktura zasady jest błędna lub aplikacja biznesowa potrzebuje własnej reguły.

Szczególnie ryzykowne są Web Exceptions, które pomijają Policy checks albo Malware and content scanning. Jeśli problemem jest tylko HTTPS decryption, SSL/TLS Exclusion jest zwykle węższe i bardziej zrozumiałe.

Raportowanie nic nie pokazuje

Wtedy należy sprawdzić logowanie, raportowanie, wybór reguły zapory, zasady lub przekazywanie logów. Zasada bez logowania jest trudna do oceny w działaniu.

Lista kontrolna operacyjna

• Sprawdzono status licencji ochrony sieci Web.
• Oddzielnie oceniono ruch klientów, serwerów, gości i VPN.
• Utworzono zasadę sieci Web z opisową nazwą.
• Świadomie zaplanowano krytyczne kategorie i grupy URL.
• Sprawdzono kolejność reguł w ramach zasady sieci Web.
• Aktywowano zasadę sieci Web w odpowiedniej regule zapory.
• Log firewall traffic, logowanie zasady sieci Web i Reporting są aktywne.
• Reguły zasady sieci Web są włączone i we właściwej kolejności.
• Sprawdzono inspekcję TLS i certyfikat CA dla grupy pilotażowej.
• Zdefiniowano strategię QUIC.
• Web Exceptions i TLS Exclusions są udokumentowane oddzielnie.
• Przeprowadzono testy Policy Tester i rzeczywiste.
• Skontrolowano Log Viewer i raportowanie.
• Zdefiniowano proces zmian dla wyjątków w zasadach sieci Web.
• Tymczasowe wyjątki oznaczone datą wygaśnięcia.
• Udokumentowano wyjątki z właścicielem i datą przeglądu.

FAQ