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

QUIC to nowoczesny protokół transportowy, który jest obecnie szczególnie istotny w kontekście HTTP/3. Wiele przeglądarek i usług internetowych korzysta z QUIC, aby szybciej i stabilniej nawiązywać połączenia internetowe. Dla administratorów kluczowy jest jednak inny aspekt: QUIC działa przez UDP, najczęściej przez UDP 443, i dlatego zachowuje się inaczej niż klasyczne HTTPS przez TCP.

Na Sophos Firewall jest to ważne, ponieważ filtrowanie sieci, skanowanie złośliwego oprogramowania, inspekcja TLS i kontrola aplikacji mogą być niezawodnie oceniane tylko wtedy, gdy ruch przebiega zgodnie z oczekiwaniami przez regułę. W wielu środowiskach opcja Block QUIC protocol pozostaje zatem sensownym ustawieniem w regułach internetowych dla klientów.

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.

QUIC przenosi ten ruch sieciowy na UDP. Dla użytkowników jest to często szybsze. Dla zapory oznacza to jednak:

• Ruch sieciowy nie wygląda już jak klasyczne HTTPS przez TCP.
• UDP 443 może omijać oczekiwania dotyczące filtrowania sieci i skanowania.
• 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 blokuje wychodzące pakiety UDP na port 80 i 443 dla ruchu, który pasuje do danej reguły zapory. To kluczowy punkt: jeśli klient wychodzi do internetu przez inną regułę, ustawienie w regule standardowej nie ma wpływu na ten ruch. Po blokadzie przeglądarki zazwyczaj przechodzą na HTTPS przez TCP.

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.

Dla sieci Wi-Fi dla gości bez głębszej inspekcji QUIC może być mniej krytyczny. Dla zarządzanych sieci klienckich, serwerów z wychodzącym dostępem do Internetu lub środowisk z wymaganiami zgodności należy świadomie zdecydować o QUIC, a nie pozostawiać tego przeglądarce.

Sprawdzenie ustawienia w regule zapory

Normalnym miejscem jest wychodząca reguła zapory, na przykład LAN_to_WAN_Clients.

Ścieżka menu:

Rules and policies > Firewall rules

Procedura:

1. Otwórz odpowiednią regułę internetową dla klientów.
2. Przejdź do sekcji Security features > Web filtering.
3. Aktywuj Log firewall traffic, aby testy były widoczne w Log Viewer.
4. Sprawdź politykę sieciową lub skanowanie złośliwego oprogramowania.
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.

Sophos domyślnie aktywuje Block QUIC protocol, gdy w regule wybrana jest polityka sieciowa lub skanowane są HTTP i deszyfrowane HTTPS. Niemniej jednak należy świadomie kontrolować to ustawienie w ważnych regułach internetowych, szczególnie po migracjach, starych zestawach reguł, skopiowanych regułach albo automatycznie posortowanych na nowo regułach.

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.

Alternatywa: Kontrola aplikacji lub reguła 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
• Kontrola aplikacji: Dodatkowa kontrola przez rozpoznawanie aplikacji Wymaga odpowiedniej polityki kontroli aplikacji i logów
• 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.

Application Control może dodatkowo uwidocznić QUIC, ale nie jest przepustką dla niesprawdzonego ruchu web. Niektóre web micro apps można rozpoznawać wiarygodniej, jeśli firewall potrafi ocenić kontekst URL z odszyfrowanego ruchu. Jeśli TLS Inspection nie jest aktywna albo ruch przez QUIC nie trafia na oczekiwaną ścieżkę, logi Application Control należy zawsze czytać razem z logami 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.

Test i walidacja

Po zmianie należy sprawdzić, czy klient rzeczywiście przechodzi na HTTPS przez TCP i czy pasuje do oczekiwanej reguły zapory.

Praktyczny przebieg testu:

1. Zresetuj licznik użycia dla odpowiedniej reguły zapory.
2. Całkowicie uruchom ponownie przeglądarkę na kliencie testowym, aby istniejące połączenia i stany HTTP/3 nie zafałszowały testu.
3. Otwórz stronę internetową, która wcześniej korzystała z QUIC.
4. W Log Viewer filtruj według Source IP, Rule ID, protokołu i Destination Port.
5. Sprawdź, czy UDP 443 jest blokowane lub już nie używane.
6. Sprawdź, czy HTTPS przez TCP 443 pojawia się w oczekiwanej regule.
7. Jeśli aktywne jest filtrowanie sieci lub inspekcja TLS, sprawdź odpowiednie moduły logów.
8. W przypadku niejasności użyj Packet Capture na interfejsie klienta lub zapory.

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

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

Często zadawane pytania