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ł:

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.

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.

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:

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.

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. Świadomie wybierz użytkowników, grupy lub Anybody.
5. Wybierz Activities, Categories, URL Groups, File types lub Content filters.
6. Ustal akcję dla HTTP i HTTPS: Allow, Warn, Block lub Quota.
7. Ustaw harmonogram, jeśli reguła ma obowiązywać tylko w określonych godzinach.
8. Aktywuj regułę.
9. Sprawdź pozycję reguły w ramach zasady.
10. Aktywuj logowanie i raportowanie.
11. 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.

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.
• Skanowanie złośliwego oprogramowania jest odpowiednio aktywowane.
• Block QUIC protocol jest świadomie ustawione.
• Inspekcja TLS jest planowana oddzielnie i nie mylona z zasadą sieci Web.

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.

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.

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.

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.

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

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:

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ć:

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.

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.

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 i logowanie sieci Web są aktywne.
• Sprawdzono inspekcję TLS i certyfikat CA dla grupy pilotażowej.
• Zdefiniowano strategię QUIC.
• 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