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ł.
• 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.
• Ustawienia ogólne: SafeSearch, ograniczenia YouTube, Google Apps i ograniczenia Microsoft Entra ID Tenant.
• 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.

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

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.

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, File types lub Content filters.
3. W razie potrzeby dodaj Content filters. Dla Content filters zapora używa tej samej akcji dla HTTPS co dla HTTP.
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ę.

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.

Reguły w zasadzie sieci Web są oceniane od góry do dołu. Reguła Allow dla All web traffic umieszczona nad regułą Block praktycznie unieważnia regułę blokowania. Po każdej zmianie należy więc sprawdzić nie tylko treść reguły, ale także kolejność i przełącznik statusu.

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.
• Use web proxy instead of DPI engine jest świadomie włączone albo świadomie wyłączone.
• 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.

Web Proxy filtruje w regule zapory tylko klasyczne porty 80 i 443. DPI Engine może sprawdzać ruch HTTP i SSL/TLS także na innych portach, jeśli reguła oraz reguły SSL/TLS Inspection pasują. W projektach direct proxy trzeba dodatkowo jasno ustalić, czy klienci używają proxy jawnie, czy normalny przezroczysty ruch klienta przechodzi przez regułę. W przeciwnym razie łatwo testuje się niewłaściwą ścieżkę.

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

Sophos Firewall może w zasadach sieci Web ustawiać dodatkowe kontrole wyszukiwania i chmury.

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.

Te funkcje są pomocne, ale nie magiczne. W przypadku HTTPS ich skuteczność częściowo zależy od skanowania HTTPS lub inspekcji TLS. Ponadto nie zastępują one zarządzania tożsamością i aplikacjami chmurowymi w Microsoft 365 lub Google Workspace. Dla środowisk produkcyjnych warto sprawdzić ich działanie z rzeczywistymi użytkownikami testowymi i przeglądarkami.

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. Należy to wcześnie zdecydować, ponieważ tryb 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 Overrides to inne narzędzie niż kwoty. Pozwalają uprawnionym użytkownikom w User Portal utworzyć tymczasowy dostęp do normalnie blokowanych stron. Może to być przydatne w szkołach lub scenariuszach wsparcia, ale wymaga jasnych granic: kategorii bez możliwości obejścia, uprawnionych osób, okien czasowych i przeglądu override’ów.

Web Exceptions i wyjątki TLS

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 należy unikać domen głównych i zbyt szerokich wzorców URL regex. Wzorzec taki jak example.com może pojawić się również w ścieżkach lub parametrach zapytania innych domen. Lepsze są konkretne hostnames, odpowiednie grupy URL i jasny zakres według źródła, celu, kategorii lub grupy użytkowników.

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

W sekcji Web > Policies dostępny jest Policy tester. Można nim sprawdzić, jaka decyzja polityki jest oczekiwana dla użytkownika, URL i kontekstu.

Policy Tester to dobry wstępny test, ale nie zastępuje rzeczywistego przepływu pakietów. Reguła zapory, NAT, inspekcja TLS, QUIC lub routing mogą nadal uniemożliwić, aby oczekiwana zasada działała w rzeczywistym ruchu.

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