Vai al contenuto
Avanet

Bloccare correttamente QUIC e HTTP/3 con Sophos Firewall

QUIC è un moderno protocollo di trasporto cifrato su UDP; HTTP/3 utilizza QUIC come trasporto. I termini sono quindi strettamente collegati, ma non sono sinonimi. Browser e servizi web usano normalmente HTTP/3 su UDP 443. Per l’amministratore è essenziale capire che questo percorso è diverso dal classico HTTPS su TCP.

Su Sophos Firewall ciò conta perché, secondo la documentazione SFOS 22, il filtro web non può analizzare QUIC e QUIC aggira Web Filtering. Se una regola client deve imporre una Web Policy, la scansione malware o la TLS Inspection basata su TCP, Block QUIC protocol è quindi il metodo standard documentato. L’opzione non attende di riconoscere un handshake QUIC: nell’ambito della regola firewall corrispondente scarta tutti i pacchetti UDP in uscita verso le porte di destinazione 80 e 443.

Quale articolo di protezione web è adatto?

QUIC non è solitamente l’obiettivo principale, ma un fattore di disturbo in scenari di protezione web, ispezione TLS o risoluzione dei problemi. A seconda del compito, è adatto un diverso punto di partenza:

Questo articolo risponde principalmente alla domanda su quando e come bloccare QUIC o HTTP/3 nella regola del firewall appropriata e successivamente convalidare correttamente.

Cosa significa QUIC per il firewall

Il classico HTTPS opera principalmente su TCP 443. Il firewall può decidere, a seconda della regola, della politica web, del motore DPI, del proxy web e dell’ispezione SSL/TLS, se il traffico deve essere solo consentito, categorizzato, decrittato, scansionato o bloccato.

HTTP/3 sposta questo traffico web su QUIC tramite UDP. Per il firewall, significa:

  • Il traffico web non appare più come il classico HTTPS su TCP.
  • QUIC può aggirare Web Filtering di SFOS e il relativo filtro web non può analizzarlo.
  • L’ispezione TLS non funziona come con il normale HTTPS su TCP.
  • La risoluzione dei problemi diventa più difficile quando i browser passano automaticamente tra TCP e QUIC.
  • Tester di politiche, Log Viewer e Packet Capture devono essere confrontati consapevolmente con protocollo e porta.

L’opzione Block QUIC protocol scarta i pacchetti UDP in uscita verso le porte di destinazione 80 e 443 quando il traffico soddisfa i criteri della regola. Se il client usa un’altra regola, l’opzione non ha effetto. Poiché il blocco è basato sulle porte, può colpire anche applicazioni non QUIC che usano UDP 80 o 443. I browser comuni in genere provano HTTPS su TCP dopo il fallimento di HTTP/3, ma il fallback va verificato per ogni applicazione critica.

HTTPS non viene decrittato automaticamente. Il blocco QUIC porta soltanto il traffico in un percorso TCP più controllabile. Che poi intervengano Web Policy, scansione malware, Application Control o TLS Inspection dipende dal resto della configurazione della regola e dell’ispezione.

Quando bloccare QUIC

In molte reti client produttive, bloccare QUIC è sensato se una o più di queste affermazioni sono vere:

  • Il filtraggio web deve essere affidabile.
  • La scansione malware per i download web è importante.
  • L’ispezione TLS viene utilizzata per categorie o gruppi di utenti selezionati.
  • Il controllo delle applicazioni deve riconoscere meglio le applicazioni web.
  • Gli accessi web devono essere tracciabili nel Log Viewer.
  • L’helpdesk e il team di sicurezza devono poter eseguire test riproducibili.

Consentire QUIC può essere una scelta consapevole in una Wi-Fi ospiti senza Web Filtering né ispezione dei contenuti; va allora documentato che il filtro web SFOS non analizza tale percorso UDP. Per reti gestite o scope di conformità il blocco per regola è di solito più giustificabile. Server e applicazioni specialistiche vanno testati separatamente, perché non ogni client QUIC garantisce il fallback a TCP.

Verifica dell’impostazione nella regola del firewall

La posizione normale è la regola firewall in uscita, per esempio LAN_to_WAN_Clients. In SFOS 22, l’opzione si trova in Security features > Web filtering > Block QUIC protocol.

Percorso del menu:

Rules and policies > Firewall rules

Procedura:

Per un test pilota si può copiare la regola Internet esistente o crearne una limitata sopra di essa. Un esempio documentabile usa Source zones: LAN, Source networks and devices: CLIENT-WEB-01 con 10.20.30.50, Destination zones: WAN, Destination networks: Any e i Services e le Security Policies già necessari in produzione. IP e nomi vanno sostituiti con un client identificabile senza ambiguità; Destination, NAT e profili di protezione restano inizialmente invariati.

  1. Aprire la regola di accesso a Internet del client interessato.
  2. Andare a Security features > Web filtering.
  3. Attivare Log firewall traffic, in modo che i test siano visibili nel Log Viewer.
  4. Verificare la Web Policy prevista e Scan HTTP and decrypted HTTPS.
  5. Lasciare attivato o attivare consapevolmente Block QUIC protocol.
  6. Attivare Scan HTTP and decrypted HTTPS solo se è chiaro come viene decrittato HTTPS.
  7. In DPI Mode, verificare che Use web proxy instead of DPI engine non sia attivo per errore.
  8. In Web Proxy Mode, verificare se Decrypt HTTPS during web proxy filtering e la distribuzione della CA corrispondono all’obiettivo.
  9. Salvare la regola.
  10. Verificare il client di test e controllare il Log Viewer.

SFOS 22 seleziona Block QUIC protocol per impostazione predefinita quando si sceglie una Web Policy o si attiva Scan HTTP and decrypted HTTPS. È un valore predefinito dell’interfaccia per quella regola, non una policy globale. Dopo migrazioni, copie o cambi d’ordine va ricontrollata la regola realmente corrispondente.

Regola Sophos Firewall con l'opzione Block QUIC protocol attivata
L’opzione Block QUIC protocol si trova nella regola firewall sotto Security features > Web filtering e si applica solo al traffico corrispondente a questa regola.

Maggiori dettagli sulle singole opzioni di una regola del firewall sono disponibili in Comprendere e configurare correttamente le regole del firewall di Sophos.

Non disabilitare QUIC solo tramite browser

In passato, era comune disabilitare QUIC direttamente nel browser o tramite Chrome Flags. Questo può aiutare nei test, ma non è un concetto di sicurezza affidabile:

  • Le impostazioni del browser cambiano.
  • Non solo Chrome può utilizzare QUIC o HTTP/3.
  • Gli utenti o gli aggiornamenti possono ripristinare le impostazioni.
  • I dispositivi BYOD, ospiti e non gestiti sono difficilmente controllabili in questo modo.
  • Le politiche di sicurezza dovrebbero essere tracciabili centralmente sul firewall.

Per gli ambienti produttivi, la regola del firewall è il posto migliore. I test lato browser possono essere utili come complemento quando si vuole restringere un errore.

Inquadrare correttamente Application Control e le regole UDP personalizzate

Oltre a Block QUIC protocol, ci sono altri modi per limitare il traffico QUIC.

  • Block QUIC protocol nella regola del firewall: Caso standard per filtraggio web e scansione. Limite: l’impostazione si applica solo al traffico che corrisponde a questa regola.
  • Application Control: il rilevamento e il logging basati su firme possono integrare il blocco. In Applications > Application list si verifica se l’attuale versione dei pattern offre una voce QUIC adatta; uno screenshot storico non dimostra il catalogo corrente. Un Application Filter agisce solo quando è assegnato alla regola corrispondente in Other security features > Identify and control applications (App control).
  • Regola di drop personalizzata per UDP 80/443: Blocco tecnico molto chiaro. Limite: la regola deve essere posizionata correttamente e limitata alle reti client.
  • Configurazione del browser: Utile per test brevi o ambienti speciali gestiti. Limite: non abbastanza robusta come unica policy del firewall.

Se viene utilizzata una regola di drop personalizzata, dovrebbe essere posizionata sopra le regole di accesso a Internet generali dei client e registrata correttamente. Altrimenti, non è chiaro se QUIC è stato bloccato consapevolmente o se il traffico si è bloccato altrove.

Se la modifica richiede una regola di blocco separata, si crea per esempio QUIC_UDP_80_443 in Hosts and services > Services > Add con Type of service: UDP e Destination port: 80,443. Il valore predefinito Source port: 1:65535 resta invariato. La regola sopra l’Allow generale usa Action: Drop, Source zones: LAN, l’oggetto pilota in Source networks and devices, Destination zones: WAN, Destination networks: Any, questo Service e Log firewall traffic. Nome, scope Source e posizione vanno adattati; le porte UDP restano ristrette e l’eventuale impatto non QUIC viene validato separatamente.

Application Control non sostituisce in modo equivalente l’opzione documentata basata sulle porte quando si deve imporre il percorso TCP del filtro web. Le firme cambiano con gli aggiornamenti dei pattern e le micro app basate su URL richiedono che la DPI Engine veda l’URL decrittato. Si correlano quindi i log Application, Firewall, Web e SSL/TLS Inspection.

Filtro di Controllo delle applicazioni di Sophos Firewall con QUIC
Il Controllo delle applicazioni può riconoscere e bloccare ulteriormente QUIC, ma non sostituisce la verifica della regola del firewall.
Regola del firewall di Sophos Firewall con filtro di Controllo delle applicazioni per QUIC
Le politiche di Controllo delle applicazioni devono essere attive nella regola del firewall appropriata affinché abbiano effetto sul traffico dei client.

Relazione con l’ispezione TLS

Block QUIC protocol non è un sostituto per l’ispezione TLS. L’impostazione assicura solo che i browser non continuino a comunicare tramite QUIC per il traffico appropriato, ma di solito tornino a HTTPS su TCP.

Solo dopo si pone la vera questione TLS:

  • Esiste una regola di ispezione SSL/TLS appropriata?
  • Il certificato CA è distribuito sui client?
  • Il traffico viene decrittato o consapevolmente non decrittato?
  • Scan HTTP and decrypted HTTPS è attivo nella regola del firewall?
  • Ci sono eccezioni per le applicazioni con Certificate Pinning?

Se si desidera esaminare i contenuti HTTPS, è necessario un rollout TLS pianificato. I dettagli sono disponibili in Introdurre correttamente l’ispezione TLS di Sophos Firewall.

È importante la modalità operativa della regola. In DPI Mode, si applicano le SSL/TLS Inspection Rules in Rules and policies > SSL/TLS inspection rules. In Web Proxy Mode, la decrittazione HTTPS viene gestita tramite le impostazioni del Web Proxy e l’opzione Decrypt HTTPS during web proxy filtering. Se questi due modelli vengono mescolati, QUIC sembra rapidamente il problema principale, anche se in realtà l’architettura di ispezione non è chiara.

Scegliere correttamente DPI Engine o Web Proxy spiega la scelta funzionale e la migrazione tra questi percorsi di traffico.

Dimostrare l’effetto con test positivo e negativo

Il solo fatto che il sito sia raggiungibile non dimostra il fallback. La validazione separa tre domande: la regola prevista ha scartato UDP 443, è stata poi stabilita una nuova connessione TCP e su tale percorso è stata applicata la decisione Web o TLS attesa?

Procedura di test pratica:

  1. Annotare stato iniziale, Rule ID, IP client, destinazione e ora. Confermare prima che la destinazione generi un tentativo UDP 443; altrimenti il test non prova nulla su QUIC.
  2. Attivare Log firewall traffic e, facoltativamente, azzerare il Usage Counter della regola pilota.
  3. In Diagnostics > Packet capture, fare clic su Configure e inserire host 10.20.30.50 and proto UDP and dst port 443 in Enter BPF string, sostituendo l’IP. Avviare la cattura, chiudere e riaprire completamente il browser e richiamare la destinazione preparata.
  4. In Diagnostics > Packet capture > Display filter filtrare per Source IP, Destination port: 443, Reason: Firewall e Rule ID prevista. Un pacchetto UDP con stato Violation in quella regola è la prova positiva; la sola assenza di UDP non lo è.
  5. Cambiare il filtro in host 10.20.30.50 and proto TCP and dst port 443 e creare una nuova connessione. Handshake TCP e Rule ID prevista dimostrano il percorso.
  6. In Log viewer > Firewall correlare ora, Source IP, destinazione, Rule ID, protocollo e porta. Le sessioni spesso appaiono al Connection Destroy event; una connessione aperta si controlla anche in Current activities > Live connections.
  7. Per Web Protection eseguire dallo stesso scope una richiesta consentita e una bloccata dalla Web Policy. Per TLS Inspection verificare anche SSL/TLS inspection, Decryption Rule ed emittente del certificato visibile. Scan HTTP and decrypted HTTPS da solo non prova la decrittazione.
  8. Come test negativo, togliere temporaneamente il client dallo scope o ripristinare il precedente stato di Block QUIC protocol, creare una sessione e verificare che UDP 443 ricompaia sul percorso previsto. Infine ripristinare lo stato approvato.

Per i test delle regole, si adatta la guida Testare la regola del firewall di Sophos con Log Viewer e Packet Capture.

Errori tipici

  • Blocco QUIC attivato solo in una regola vecchia o errata: Il traffico client corrente passa attraverso un’altra regola.
  • La regola è sotto una regola di autorizzazione generale: QUIC viene consentito prima.
  • Il logging è disattivato: Nel Log Viewer non è visibile cosa accade.
  • Viene riutilizzata una sessione browser esistente: Riavviare il browser o usare un profilo di test prima di valutare i log.
  • Solo Chrome modificato localmente: Altri browser o dispositivi continuano a utilizzare QUIC.
  • Si prevede l’ispezione TLS, ma non è configurata: I contenuti HTTPS non vengono decrittati nonostante il blocco QUIC.
  • Scan HTTP and decrypted HTTPS viene frainteso: L’opzione scansiona solo HTTPS già decrittato.
  • DPI Mode e Web Proxy Mode vengono mescolati: L’impostazione cercata potrebbe trovarsi in un altro punto.
  • UDP 443 viene bloccato globalmente: Applicazioni speciali possono essere inaspettatamente colpite.

Risoluzione dei problemi e versioni SFOS 22

Se il filtraggio web o la scansione non funzionano come previsto, si dovrebbe verificare questa sequenza:

  1. Quale regola del firewall corrisponde effettivamente al traffico del client?
  2. Block QUIC protocol è attivo esattamente in questa regola?
  3. Il client utilizza UDP 443 o TCP 443?
  4. Log firewall traffic è attivo?
  5. Una regola più specifica si applica sopra?
  6. Esiste una politica di controllo delle applicazioni che tratta QUIC diversamente?
  7. Esiste una regola di ispezione SSL/TLS se si desidera esaminare i contenuti HTTPS?
  8. Viene usato DPI Mode o Web Proxy Mode?
  9. Packet Capture mostra pacchetti UDP 443 in uscita nonostante il blocco previsto?

Se la cattura mostra ancora pacchetti Forwarded, verificare prima Rule ID, oggetto Source, percorso IPv4/IPv6, Services e ordine delle regole. Il pacchetto può corrispondere a un’altra regola; la selezione in una regola non corrispondente non crea un blocco globale. Se manca qualsiasi tentativo UDP, usare un’altra destinazione compatibile con HTTP/3 prima di attribuire il problema al firewall.

Se la Web Policy non interviene dopo il fallback TCP, QUIC non è automaticamente la causa. Per regole con più utenti o gruppi conta anche la build: le Release Notes ufficiali riportano in SFOS 22.0 MR1 Build 490 il fix NC-176376 per regole Web Policy con più di un gruppo o utente che non funzionavano dopo l’upgrade a 22.0 GA. Verificare build, Rule ID e contesto utente prima di cambiare QUIC o TLS; ogni upgrade segue il consueto processo di backup e change.

Se la regola non corrisponde, il problema principale non è QUIC, ma l’ordine delle regole, la zona di origine, la rete di origine, la destinazione, il servizio o l’esclusione. Per questo aiuta Verificare le cause per cui la regola del firewall non si applica.

Lista di controllo operativa

  • Regola di accesso a Internet del client interessata identificata chiaramente.
  • Politica web, scansione malware o ispezione TLS verificata esattamente in questa regola.
  • Block QUIC protocol attivato consapevolmente o disattivato con giustificazione.
  • DPI Mode o Web Proxy Mode deciso consapevolmente.
  • Ordine delle regole e regole di autorizzazione più generali verificati.
  • Log firewall traffic attivo.
  • Test eseguito con browser e sito di destinazione reale.
  • Log Viewer controllato su UDP 443, TCP 443, ID regola ed eventi web.
  • In caso di ispezione TLS, controllati anche i log di ispezione SSL/TLS.
  • Eccezioni o regole UDP personalizzate documentate.
  • L’helpdesk sa che i siti web dovrebbero continuare a funzionare normalmente dopo il blocco QUIC.

Rollback

Prima del pilota si registrano stato e posizione della regola, Block QUIC protocol, Web Policy, Application Filter, logging, NAT e modalità TLS/proxy. Per tornare indietro si disattiva la regola pilota o si ripristina esattamente lo stato precedente di opzioni e policy. Si chiudono browser e sessioni, quindi una nuova connessione deve mostrare la Rule ID e il comportamento UDP/TCP precedenti. Solo dopo si eliminano oggetti esclusivi del pilota, mai Services, filtri o regole NAT condivisi.

Domande frequenti

QUIC è insicuro?

QUIC non è intrinsecamente insicuro. Il limite di SFOS 22 è che il filtro web non può analizzare QUIC e QUIC aggira Web Filtering; ciò non disattiva automaticamente ogni altro controllo del firewall.

È sufficiente bloccare UDP 443?

Una regola di drop per UDP 443 impedisce il normale percorso HTTP/3, ma blocca anche traffico non QUIC su quella porta. Block QUIC protocol è meglio documentato per il filtro web SFOS e copre anche UDP 80. Entrambe le varianti devono corrispondere alla regola reale, allo scope client e al test negativo.

HTTPS viene decrittato automaticamente se QUIC è bloccato?

No. Il blocco QUIC assicura solo che i browser di solito tornino a HTTPS su TCP. Per la decrittazione HTTPS sono necessarie regole di ispezione SSL/TLS e un certificato CA distribuito.

Si dovrebbe bloccare QUIC in ogni rete?

Non necessariamente. Per le reti client gestite è spesso sensato. Per le reti Wi-Fi per ospiti, le reti di test o gli accessi Internet molto semplici si può decidere diversamente. È importante che la decisione si adatti consapevolmente alla strategia di filtraggio web, logging e ispezione.

Perché un sito web funziona ancora dopo il blocco?

Questo è spesso desiderato. I browser passano frequentemente automaticamente da QUIC a HTTPS normale su TCP. Il sito continua a funzionare, ma il firewall può meglio classificare il traffico nel normale percorso di filtraggio web e scansione.