Prawidłowe blokowanie QUIC i HTTP/3 na Sophos Firewall

QUIC to nowoczesny, szyfrowany protokół transportowy wykorzystujący UDP; HTTP/3 używa QUIC jako transportu. Terminy są więc ściśle powiązane, ale nie są synonimami. Przeglądarki i usługi internetowe zwykle korzystają z HTTP/3 przez UDP 443. Dla administratora kluczowe jest to, że nie jest to klasyczna ścieżka HTTPS przez TCP.

W Sophos Firewall ma to znaczenie, ponieważ dokumentacja SFOS 22 podaje, że filtr internetowy nie może skanować QUIC, a QUIC omija Web Filtering. Jeśli reguła kliencka ma wymuszać Web Policy, skanowanie malware lub inspekcję TLS opartą na TCP, Block QUIC protocol jest udokumentowaną metodą standardową. Opcja nie czeka na rozpoznanie handshake QUIC: w zakresie pasującej reguły odrzuca wszystkie wychodzące pakiety UDP do portów docelowych 80 i 443.

Który artykuł o ochronie sieci pasuje?

QUIC zazwyczaj nie jest celem samym w sobie, lecz czynnikiem zakłócającym w scenariuszach ochrony sieci, inspekcji TLS lub rozwiązywania problemów. W zależności od zadania, odpowiedni jest inny punkt wyjścia:

• Planowanie polityki sieciowej, grup URL, SafeSearch i filtrowania sieci: Konfiguracja ochrony sieci na Sophos Firewall za pomocą polityk sieciowych
• Obsługa kategorii sieciowych i natychmiastowych alertów: Korzystanie z kategorii sieciowych i natychmiastowych alertów na Sophos Firewall
• Deszyfrowanie i kontrolowane wdrażanie ruchu HTTPS: Prawidłowe wprowadzenie inspekcji TLS na Sophos Firewall
• Sprawdzanie, która reguła zapory faktycznie pasuje: Testowanie reguł na Sophos Firewall za pomocą Log Viewer i Packet Capture

Ten artykuł odpowiada przede wszystkim na pytanie, kiedy i jak blokować QUIC lub HTTP/3 w odpowiedniej regule zapory i jak to poprawnie zweryfikować.

Co oznacza QUIC dla zapory

Klasyczne HTTPS zazwyczaj działa przez TCP 443. Zapora może wówczas, w zależności od reguły, polityki sieciowej, silnika DPI, proxy sieciowego i inspekcji SSL/TLS, decydować, czy ruch jest tylko dozwolony, kategoryzowany, deszyfrowany, skanowany czy blokowany.

HTTP/3 przenosi ten ruch sieciowy do QUIC przez UDP. Dla zapory oznacza to:

• Ruch sieciowy nie wygląda już jak klasyczne HTTPS przez TCP.
• QUIC może omijać Web Filtering w SFOS, a filtr internetowy nie może go skanować.
• Inspekcja TLS nie działa jak przy normalnym HTTPS przez TCP.
• Rozwiązywanie problemów staje się trudniejsze, gdy przeglądarki automatycznie przełączają się między TCP a QUIC.
• Tester polityki, Log Viewer i Packet Capture muszą być świadomie porównywane z protokołem i portem.

Opcja Block QUIC protocol odrzuca wychodzące pakiety UDP do portów docelowych 80 i 443, gdy ruch spełnia kryteria tej reguły. Jeśli klient korzysta z innej reguły, opcja nie działa. Ponieważ blokada jest oparta na portach, może też objąć aplikację inną niż QUIC, która używa UDP 80 lub 443. Popularne przeglądarki zwykle próbują HTTPS przez TCP po nieudanym HTTP/3, ale ten fallback trzeba sprawdzić dla każdej aplikacji krytycznej.

HTTPS nie jest przez to automatycznie deszyfrowany. Blokada QUIC przenosi ruch tylko na łatwiejszą do kontrolowania ścieżkę TCP. To, czy później zadziała Web Policy, Malware Scan, Application Control albo TLS Inspection, zależy od pozostałej konfiguracji reguł i inspekcji.

Kiedy należy blokować QUIC

W wielu produkcyjnych sieciach klienckich blokowanie QUIC jest sensowne, jeśli jedno lub więcej z tych stwierdzeń jest prawdziwe:

• Filtrowanie sieci powinno działać niezawodnie.
• Skanowanie złośliwego oprogramowania dla pobrań z sieci jest ważne.
• Inspekcja TLS jest stosowana dla wybranych kategorii lub grup użytkowników.
• Kontrola aplikacji powinna lepiej rozpoznawać aplikacje sieciowe.
• Dostępy do sieci powinny być możliwe do prześledzenia w Log Viewer.
• Helpdesk i zespół ds. bezpieczeństwa powinny móc przeprowadzać powtarzalne testy.

Zezwolenie na QUIC może być świadomą decyzją w gościnnym Wi-Fi bez Web Filtering i inspekcji treści; należy wtedy udokumentować, że filtr SFOS nie skanuje tej ścieżki UDP. W sieciach zarządzanych lub zakresie compliance blokada per reguła jest zwykle łatwiejsza do uzasadnienia. Serwery i aplikacje specjalistyczne testuje się osobno, bo nie każdy klient QUIC gwarantuje fallback do TCP.

Sprawdzenie ustawienia w regule zapory

Miejscem konfiguracji jest wychodząca reguła zapory, na przykład LAN_to_WAN_Clients. W SFOS 22 opcja znajduje się w Security features > Web filtering > Block QUIC protocol.

Ścieżka menu:

Rules and policies > Firewall rules

Procedura:

Dla pilota można skopiować istniejącą regułę internetową albo utworzyć nad nią wąską regułę. Udokumentowany przykład używa Source zones: LAN, Source networks and devices: CLIENT-WEB-01 z 10.20.30.50, Destination zones: WAN, Destination networks: Any oraz Services i Security Policies już wymaganych produkcyjnie. IP i nazwy zastępuje się jednoznacznym klientem testowym; Destination, NAT i profile ochrony pozostają początkowo bez zmian.

1. Otwórz odpowiednią regułę internetową dla klientów.
2. Przejdź do Security features > Web filtering.
3. Aktywuj Log firewall traffic, aby testy były widoczne w Log Viewer.
4. Sprawdź planowaną Web Policy i opcję Scan HTTP and decrypted HTTPS.
5. Pozostaw aktywowaną lub świadomie aktywuj Block QUIC protocol.
6. Scan HTTP and decrypted HTTPS aktywuj tylko wtedy, gdy jest jasne, jak deszyfrować HTTPS.
7. W DPI Mode sprawdź, czy Use web proxy instead of DPI engine nie jest przypadkowo aktywne.
8. W Web Proxy Mode sprawdź, czy Decrypt HTTPS during web proxy filtering i dystrybucja CA pasują do celu.
9. Zapisz regułę.
10. Sprawdź klienta testowego i kontroluj Log Viewer.

SFOS 22 domyślnie zaznacza Block QUIC protocol po wybraniu Web Policy albo włączeniu Scan HTTP and decrypted HTTPS. To wartość domyślna interfejsu dla tej reguły, nie globalna polityka. Po migracji, kopiowaniu lub zmianie kolejności ponownie sprawdza się faktycznie pasującą regułę.

Więcej o poszczególnych opcjach reguły zapory znajduje się w Zrozumienie i prawidłowa konfiguracja reguł Sophos Firewall.

Nie tylko dezaktywacja QUIC w przeglądarce

Wcześniej powszechne było wyłączanie QUIC bezpośrednio w przeglądarce lub za pomocą Chrome Flags. Może to pomóc w testach, ale nie jest to solidna koncepcja bezpieczeństwa:

• Ustawienia przeglądarki się zmieniają.
• Nie tylko Chrome może używać QUIC lub HTTP/3.
• Użytkownicy lub aktualizacje mogą przywrócić ustawienia.
• Urządzenia BYOD, gości i niezarządzane trudno kontrolować w ten sposób.
• Polityki bezpieczeństwa powinny być centralnie widoczne na zaporze.

Dla środowisk produkcyjnych lepszym miejscem jest reguła zapory. Testy po stronie przeglądarki mogą być przydatne jako uzupełnienie, gdy chce się zawęzić błąd.

Właściwa rola Application Control i własnych reguł UDP

Oprócz Block QUIC protocol istnieją inne sposoby ograniczenia ruchu QUIC.

• Block QUIC protocol w regule zapory: Standardowy przypadek dla filtrowania sieci i skanowania Działa tylko dla ruchu, który pasuje do tej reguły
• Application Control: wykrywanie i logowanie oparte na sygnaturach może uzupełnić blokadę. W Applications > Application list należy sprawdzić, czy bieżąca wersja wzorców zawiera odpowiednią pozycję QUIC; historyczny zrzut nie dowodzi aktualnego katalogu. Application Filter działa dopiero po przypisaniu do pasującej reguły w Other security features > Identify and control applications (App control).
• Własna reguła Drop dla UDP 80/443: Bardzo jasna techniczna blokada Musi być prawidłowo umieszczona i ograniczona do sieci klienckich
• Konfiguracja przeglądarki: Krótkoterminowy test lub zarządzane środowisko specjalne Niewystarczająco solidne jako jedyna polityka zapory

Jeśli używana jest własna reguła Drop, powinna być umieszczona powyżej ogólnych reguł internetowych dla klientów i dobrze logowana. W przeciwnym razie później nie będzie wiadomo, czy QUIC został świadomie zablokowany, czy ruch utknął w innym miejscu.

Jeśli zmiana wymaga osobnej reguły blokującej, w Hosts and services > Services > Add tworzy się na przykład QUIC_UDP_80_443 z Type of service: UDP i Destination port: 80,443. Domyślna wartość Source port: 1:65535 pozostaje bez zmian. Reguła nad ogólnym Allow używa Action: Drop, Source zones: LAN, obiektu pilota w Source networks and devices, Destination zones: WAN, Destination networks: Any, tej Service i Log firewall traffic. Nazwę, Source scope i pozycję dopasowuje się do środowiska; porty UDP pozostają wąskie, a wpływ na ruch inny niż QUIC jest walidowany osobno.

Application Control nie jest równoważnym zamiennikiem udokumentowanej opcji portowej, gdy trzeba wymusić ścieżkę TCP filtra internetowego. Sygnatury zmieniają się wraz z aktualizacjami wzorców, a micro apps oparte na URL wymagają, by DPI Engine widział odszyfrowany URL. Dlatego koreluje się logi Application, Firewall, Web i SSL/TLS Inspection.

Związek z inspekcją TLS

Block QUIC protocol nie zastępuje inspekcji TLS. Ustawienie to jedynie zapewnia, że przeglądarki przy odpowiednim ruchu nie będą kontynuować komunikacji przez QUIC, lecz zazwyczaj przejdą na HTTPS przez TCP.

Dopiero potem pojawia się właściwe pytanie dotyczące TLS:

• Czy istnieje odpowiednia reguła inspekcji SSL/TLS?
• Czy certyfikat CA jest rozprowadzony na klientach?
• Czy ruch jest deszyfrowany czy świadomie nie deszyfrowany?
• Czy Scan HTTP and decrypted HTTPS jest aktywne w regule zapory?
• Czy istnieją wyjątki dla aplikacji z pinningiem certyfikatów?

Jeśli treści HTTPS mają być sprawdzane, potrzebne jest zaplanowane wdrożenie TLS. Szczegóły znajdują się w Prawidłowe wprowadzenie inspekcji TLS na Sophos Firewall.

Ważny jest tryb pracy reguły. W DPI Mode działają SSL/TLS Inspection Rules pod Rules and policies > SSL/TLS inspection rules. W Web Proxy Mode HTTPS-Decryption jest sterowane przez ustawienia web proxy i opcję Decrypt HTTPS during web proxy filtering. Jeśli pomiesza się te dwa modele, QUIC szybko wygląda jak główny problem, choć w rzeczywistości niejasna jest architektura inspekcji.

Prawidłowy wybór DPI Engine lub Web Proxy wyjaśnia wybór funkcji i migrację między tymi ścieżkami ruchu.

Potwierdzenie działania testem pozytywnym i negatywnym

Sama dostępność witryny nie dowodzi fallbacku. Walidacja rozdziela trzy pytania: czy oczekiwana reguła odrzuciła UDP 443, czy następnie powstało nowe połączenie TCP i czy na tej ścieżce zadziałała planowana decyzja Web lub TLS?

Praktyczny przebieg testu:

1. Zanotuj stan wyjściowy, Rule ID, IP klienta, cel i godzinę. Najpierw potwierdź, że cel generuje próbę UDP 443; inaczej test niczego nie dowodzi o QUIC.
2. Włącz Log firewall traffic i opcjonalnie wyzeruj Usage Counter reguły pilota.
3. W Diagnostics > Packet capture kliknij Configure i w polu Enter BPF string wpisz host 10.20.30.50 and proto UDP and dst port 443, zastępując IP. Uruchom capture, całkowicie zamknij i otwórz przeglądarkę i wywołaj przygotowany cel.
4. W Diagnostics > Packet capture > Display filter filtruj po Source IP, Destination port: 443, Reason: Firewall i oczekiwanej Rule ID. Pakiet UDP ze statusem Violation w tej regule jest pozytywnym dowodem; sam brak UDP nim nie jest.
5. Zmień filtr na host 10.20.30.50 and proto TCP and dst port 443 i utwórz nowe połączenie. Handshake TCP i oczekiwana Rule ID potwierdzają ścieżkę.
6. W Log viewer > Firewall skoreluj czas, Source IP, cel, Rule ID, protokół i port. Sesje często pojawiają się dopiero przy Connection Destroy event; otwarte połączenie sprawdza się też w Current activities > Live connections.
7. Dla Web Protection wykonaj z tego samego zakresu jedno żądanie dozwolone i jedno blokowane przez Web Policy. Dla TLS Inspection sprawdź także SSL/TLS inspection, Decryption Rule i widocznego wystawcę certyfikatu. Scan HTTP and decrypted HTTPS samo nie dowodzi deszyfrowania.
8. W teście negatywnym tymczasowo usuń pilota z zakresu lub przywróć wcześniejszy stan Block QUIC protocol, utwórz sesję i potwierdź powrót UDP 443 na oczekiwanej ścieżce. Następnie przywróć zatwierdzony stan.

Dla testów reguł pasuje instrukcja Testowanie reguł na Sophos Firewall za pomocą Log Viewer i Packet Capture.

Typowe błędy

• Blokada QUIC aktywowana tylko w starej lub niewłaściwej regule: Aktualny ruch kliencki przebiega przez inną regułę
• Reguła znajduje się poniżej ogólniejszej reguły Allow: QUIC jest wcześniej dozwolony
• Logowanie jest wyłączone: W Log Viewer nie widać, co się dzieje
• Istniejąca sesja przeglądarki jest używana dalej: Uruchom ponownie przeglądarkę albo użyj profilu testowego, zanim oceniasz logi
• Tylko Chrome lokalnie dostosowany: Inne przeglądarki lub urządzenia nadal używają QUIC
• Oczekiwana inspekcja TLS, ale nie skonfigurowana: Treści HTTPS nie są deszyfrowane mimo blokady QUIC
• Scan HTTP and decrypted HTTPS źle zrozumiane: Opcja skanuje tylko już deszyfrowane HTTPS
• DPI Mode i Web Proxy Mode są mieszane: Szukane ustawienie może wtedy znajdować się w innym miejscu
• UDP 443 globalnie zablokowane: Specjalne aplikacje mogą być nieoczekiwanie dotknięte

Rozwiązywanie problemów i wersje SFOS 22

Jeśli filtrowanie sieci lub skanowanie nie działa zgodnie z oczekiwaniami, należy sprawdzić tę kolejność:

1. Która reguła zapory faktycznie pasuje do ruchu klienckiego?
2. Czy Block QUIC protocol jest aktywne w tej właśnie regule?
3. Czy klient używa UDP 443 czy TCP 443?
4. Czy Log firewall traffic jest aktywne?
5. Czy powyżej znajduje się bardziej szczegółowa reguła?
6. Czy istnieje polityka kontroli aplikacji, która inaczej traktuje QUIC?
7. Czy istnieje reguła inspekcji SSL/TLS, jeśli treści HTTPS mają być sprawdzane?
8. Czy używany jest DPI Mode czy Web Proxy Mode?
9. Czy Packet Capture pokazuje wychodzące pakiety UDP 443 mimo oczekiwanej blokady?

Jeśli capture nadal pokazuje pakiety Forwarded, najpierw sprawdź Rule ID, obiekt Source, ścieżkę IPv4/IPv6, Services i kolejność reguł. Pakiet może pasować do innej reguły; zaznaczenie opcji w niepasującej regule nie jest blokadą globalną. Jeśli brak jakiejkolwiek próby UDP, użyj innego celu obsługującego HTTP/3.

Jeśli Web Policy nie działa po fallbacku TCP, QUIC nie musi być przyczyną. Dla reguł z wieloma użytkownikami lub grupami ważna jest też kompilacja: oficjalne Release Notes podają w SFOS 22.0 MR1 Build 490 poprawkę NC-176376 dla reguł Web Policy z więcej niż jedną grupą lub użytkownikiem, które nie działały po aktualizacji do 22.0 GA. Przed zmianą QUIC lub TLS sprawdza się build, Rule ID i kontekst użytkownika; aktualizacja podlega normalnej procedurze backupu i zmian.

Jeśli reguła nie pasuje, głównym problemem nie jest QUIC, lecz kolejność reguł, strefa źródłowa, sieć źródłowa, miejsce docelowe, usługa lub wykluczenie. W tym celu pomocne jest Sprawdzenie przyczyn, dlaczego reguła zapory nie pasuje.

Lista kontrolna operacyjna

• Wyraźnie zidentyfikowana odpowiednia reguła internetowa dla klientów.
• Sprawdzona polityka sieciowa, skanowanie złośliwego oprogramowania lub inspekcja TLS w tej właśnie regule.
• Block QUIC protocol świadomie aktywowane lub uzasadnione dezaktywowane.
• Świadomie zdecydowano o DPI Mode albo Web Proxy Mode.
• Sprawdzona kolejność reguł i ogólniejsze reguły Allow.
• Log firewall traffic aktywne.
• Przeprowadzony test z przeglądarką i rzeczywistą stroną docelową.
• Sprawdzony Log Viewer pod kątem UDP 443, TCP 443, ID reguły i zdarzeń sieciowych.
• Przy inspekcji TLS dodatkowo sprawdzone logi inspekcji SSL/TLS.
• Udokumentowane wyjątki lub własne reguły UDP.
• Helpdesk wie, że strony internetowe po blokadzie QUIC powinny zazwyczaj dalej działać.

Wycofanie zmian

Przed pilotem zapisuje się stan i pozycję reguły, Block QUIC protocol, Web Policy, Application Filter, logowanie, NAT i tryb TLS/proxy. Aby wycofać zmianę, wyłącza się regułę pilota albo dokładnie przywraca wcześniejsze opcje i polityki. Po zamknięciu przeglądarki i sesji nowe połączenie musi pokazać wcześniejszą Rule ID i zachowanie UDP/TCP. Dopiero potem usuwa się obiekty wyłącznie pilotażowe; nie usuwa się współdzielonych Services, filtrów ani reguł NAT.

Często zadawane pytania