Sophos Firewall QUIC en HTTP/3 correct blokkeren

QUIC is een modern, versleuteld transportprotocol via UDP; HTTP/3 gebruikt QUIC als transport. De termen zijn dus nauw verwant, maar niet identiek. Browsers en webdiensten gebruiken HTTP/3 doorgaans via UDP 443. Voor beheerders is vooral van belang dat dit niet het klassieke HTTPS-pad via TCP is.

Op Sophos Firewall is dit belangrijk omdat de SFOS 22-documentatie aangeeft dat het webfilter QUIC niet kan scannen en dat QUIC Web Filtering omzeilt. Moet een clientregel een Web Policy, malware-scanning of TCP-gebaseerde TLS Inspection afdwingen, dan is Block QUIC protocol de gedocumenteerde standaardmethode. De optie wacht niet op herkenning van een QUIC-handshake: binnen de scope van de matchende firewallregel worden alle uitgaande UDP-pakketten naar doelpoorten 80 en 443 verworpen.

Welk webbeschermingsartikel past?

QUIC is meestal niet het eigenlijke doel, maar een storende factor in webbeschermings-, TLS-inspectie- of probleemoplossingsscenario’s. Afhankelijk van de taak past een andere benadering:

• Web Policy, URL-groepen, SafeSearch en webfiltering in het algemeen plannen: Sophos Firewall Web Protection met Web Policies instellen.
• Webcategorieën en directe waarschuwingen beheren: Sophos Firewall Webcategorieën en directe waarschuwingen gebruiken.
• HTTPS-verkeer ontsleutelen en gecontroleerd uitrollen: Sophos Firewall TLS Inspection correct invoeren.
• Controleren welke firewallregel daadwerkelijk overeenkomt: Sophos Firewall Regel testen met Log Viewer en Packet Capture.

Dit artikel beantwoordt vooral de vraag wanneer en hoe je QUIC of HTTP/3 in de juiste firewallregel blokkeert en daarna correct valideert.

Wat QUIC voor de firewall betekent

Klassiek HTTPS werkt meestal via TCP 443. De firewall kan daarbij, afhankelijk van de regel, webbeleid, DPI-engine, webproxy en SSL/TLS-inspectie, beslissen of verkeer alleen is toegestaan, gecategoriseerd, ontsleuteld, gescand of geblokkeerd wordt.

HTTP/3 verplaatst dit webverkeer naar QUIC via UDP. Voor de firewall betekent dit:

• Webverkeer ziet er niet meer uit als klassiek HTTPS via TCP.
• QUIC kan SFOS Web Filtering omzeilen en kan niet door dit webfilter worden gescand.
• TLS Inspection grijpt niet zoals bij normaal HTTPS via TCP.
• Probleemoplossing wordt moeilijker als browsers automatisch tussen TCP en QUIC wisselen.
• Policy Tester, Log Viewer en Packet Capture moeten bewust met protocol en poort worden vergeleken.

De optie Block QUIC protocol verwerpt uitgaande UDP-pakketten naar doelpoorten 80 en 443 wanneer het verkeer aan de criteria van die regel voldoet. Gebruikt de client een andere regel, dan heeft de optie geen effect. Omdat de blokkade poortgebaseerd is, kan ook een niet-QUIC-toepassing worden geraakt die UDP 80 of 443 gebruikt. Gangbare browsers proberen na een mislukte HTTP/3-verbinding meestal HTTPS via TCP, maar deze fallback moet voor elke bedrijfskritische toepassing worden gecontroleerd.

Daarbij wordt HTTPS niet automatisch ontsleuteld. QUIC-blokkering brengt het verkeer alleen in een beter controleerbaar TCP-pad. Of daarna Web Policy, Malware Scan, Application Control of TLS Inspection ingrijpen, wordt bepaald door de overige regel- en inspectieconfiguratie.

Wanneer je QUIC moet blokkeren

In veel productieve clientnetwerken is het blokkeren van QUIC zinvol als een of meer van deze uitspraken van toepassing zijn:

• Webfiltering moet betrouwbaar zijn.
• Malware-scanning voor webdownloads is belangrijk.
• TLS Inspection wordt voor geselecteerde categorieën of gebruikersgroepen ingezet.
• Application Control moet webapplicaties beter herkennen.
• Webtoegang moet in de Log Viewer traceerbaar zijn.
• Helpdesk en beveiligingsteam moeten reproduceerbare tests kunnen uitvoeren.

QUIC toestaan kan een bewuste keuze zijn op gast-Wi-Fi zonder Web Filtering of inhoudsinspectie; documenteer dan dat het SFOS-webfilter dit UDP-pad niet scant. Voor beheerde netwerken of compliance-scope is de regelgebonden blokkade meestal beter te onderbouwen. Test servers en specialistische toepassingen apart, want niet elke QUIC-client garandeert TCP-fallback.

Instelling in de firewallregel controleren

De normale locatie is de uitgaande firewallregel, bijvoorbeeld LAN_to_WAN_Clients. In SFOS 22 staat de optie onder Security features > Web filtering > Block QUIC protocol.

Menupad:

Rules and policies > Firewall rules

Stappen:

Kopieer voor een pilot de bestaande internetregel of maak erboven een smalle regel. Een documenteerbaar voorbeeld gebruikt Source zones: LAN, Source networks and devices: CLIENT-WEB-01 met 10.20.30.50, Destination zones: WAN, Destination networks: Any en de Services en Security Policies die productie al nodig heeft. Vervang IP en objectnamen door een eenduidig herkenbare testclient; laat Destination, NAT en beschermingsprofielen aanvankelijk ongewijzigd.

1. Open de betreffende client-internetregel.
2. Ga naar Security features > Web filtering.
3. Activeer Log firewall traffic, zodat tests in de Log Viewer zichtbaar worden.
4. Controleer de bedoelde Web Policy en Scan HTTP and decrypted HTTPS.
5. Laat Block QUIC protocol geactiveerd of activeer het bewust.
6. Activeer Scan HTTP and decrypted HTTPS alleen als ook duidelijk is hoe HTTPS wordt ontsleuteld.
7. Controleer bij DPI Mode dat Use web proxy instead of DPI engine niet per ongeluk actief is.
8. Controleer bij Web Proxy Mode of Decrypt HTTPS during web proxy filtering en de CA-distributie bij het doel passen.
9. Sla de regel op.
10. Controleer de testclient en controleer de Log Viewer.

SFOS 22 selecteert Block QUIC protocol standaard zodra een Web Policy wordt gekozen of Scan HTTP and decrypted HTTPS wordt ingeschakeld. Dit is een standaardwaarde in de interface voor die regel, geen globaal beleid. Controleer na migraties, kopieën en wijzigingen in de regelvolgorde opnieuw de regel die werkelijk matcht.

Meer over de afzonderlijke opties van een firewallregel staat in Sophos Firewall-regels begrijpen en correct configureren.

QUIC niet alleen via de browser uitschakelen

Vroeger was het gebruikelijk om QUIC direct in de browser of via Chrome Flags uit te schakelen. Dit kan helpen bij tests, maar is geen betrouwbaar beveiligingsconcept:

• Browserinstellingen veranderen.
• Niet alleen Chrome kan QUIC of HTTP/3 gebruiken.
• Gebruikers of updates kunnen instellingen resetten.
• BYOD-, gast- en onbeheerde apparaten zijn hiermee nauwelijks te controleren.
• Beveiligingsbeleid moet centraal op de firewall traceerbaar zijn.

Voor productieve omgevingen is de firewallregel de betere locatie. Browsertests kunnen aanvullend nuttig zijn als je een fout wilt beperken.

Application Control en eigen UDP-regels juist plaatsen

Naast Block QUIC protocol zijn er andere manieren om QUIC-verkeer te beperken.

• Block QUIC protocol in de firewallregel: Standaardgeval voor webfiltering en scanning. Beperking: de instelling werkt alleen voor verkeer dat deze regel matched.
• Application Control: detectie en logging op basis van signatures kunnen de blokkade aanvullen. Controleer onder Applications > Application list of de huidige patternversie een geschikte QUIC-entry biedt; een historische screenshot bewijst de actuele catalogus niet. Een Application Filter werkt pas nadat het onder Other security features > Identify and control applications (App control) aan de matchende firewallregel is toegewezen.
• Eigen drop-regel voor UDP 80/443: Zeer duidelijke technische blokkade. Beperking: de regel moet correct gepositioneerd en tot clientnetwerken beperkt worden.
• Browserconfiguratie: Nuttig voor korte tests of beheerde speciale omgevingen. Beperking: niet robuust genoeg als enige firewall-policy.

Als een eigen drop-regel wordt gebruikt, moet deze boven algemene client-internetregels staan en correct worden gelogd. Anders is later niet te zien of QUIC bewust is geblokkeerd of dat het verkeer ergens anders vastloopt.

Als een wijziging een aparte blokkeerregel vereist, maak je bijvoorbeeld QUIC_UDP_80_443 onder Hosts and services > Services > Add met Type of service: UDP en Destination port: 80,443. Laat de standaardwaarde Source port: 1:65535 ongewijzigd. De regel boven de algemene Allow gebruikt Action: Drop, Source zones: LAN, het pilotobject onder Source networks and devices, Destination zones: WAN, Destination networks: Any, deze Service en Log firewall traffic. Pas naam, Source-scope en positie aan; houd de UDP-doelpoorten beperkt en valideer mogelijke effecten op niet-QUIC-verkeer apart.

Application Control is geen gelijkwaardige vervanging voor de gedocumenteerde poortgebaseerde optie wanneer het TCP-webfilterpad moet worden afgedwongen. Signatures wijzigen met patternupdates en URL-gebaseerde micro apps vereisen dat de DPI Engine de ontsleutelde URL ziet. Correleer daarom Application-, Firewall-, Web- en SSL/TLS-Inspection-logs.

Verband met TLS Inspection

Block QUIC protocol is geen vervanging voor TLS Inspection. De instelling zorgt er alleen voor dat browsers bij passend verkeer niet via QUIC blijven communiceren, maar normaal gesproken terugvallen op HTTPS via TCP.

Pas daarna komt de eigenlijke TLS-vraag:

• Is er een passende SSL/TLS Inspection Rule?
• Is het CA-certificaat op de clients verspreid?
• Wordt het verkeer ontsleuteld of bewust niet ontsleuteld?
• Is Scan HTTP and decrypted HTTPS in de firewallregel actief?
• Zijn er uitzonderingen voor applicaties met Certificate Pinning?

Als HTTPS-inhoud moet worden gecontroleerd, is een geplande TLS-uitrol nodig. De details staan in Sophos Firewall TLS Inspection correct invoeren.

Belangrijk is de bedrijfsmodus van de regel. In DPI Mode gelden SSL/TLS Inspection Rules onder Rules and policies > SSL/TLS inspection rules. In Web Proxy Mode wordt HTTPS-decryption via de Web Proxy-instellingen en de optie Decrypt HTTPS during web proxy filtering gestuurd. Als je deze twee modellen door elkaar haalt, lijkt QUIC al snel het hoofdprobleem, terwijl eigenlijk de inspectiearchitectuur onduidelijk is.

DPI Engine of Web Proxy correct kiezen legt de functie- en migratiekeuze tussen deze verkeerspaden uit.

Werking aantonen met een positieve en negatieve test

Dat de website bereikbaar is, bewijst de fallback niet. De validatie behandelt drie vragen afzonderlijk: verwierp de verwachte regel UDP 443, kwam daarna een nieuwe TCP-verbinding tot stand en werd op dat pad de bedoelde Web- of TLS-beslissing toegepast?

Praktische testprocedure:

1. Noteer uitgangssituatie, Rule ID, client-IP, testdoel en tijdstip. Bevestig eerst dat het doel een UDP-443-poging genereert; anders zegt de test niets over QUIC.
2. Activeer Log firewall traffic en reset desgewenst de Usage Counter van de pilotregel.
3. Klik onder Diagnostics > Packet capture op Configure en voer host 10.20.30.50 and proto UDP and dst port 443 in bij Enter BPF string. Vervang het IP, start de capture, sluit en heropen de browser volledig en roep het voorbereide doel op.
4. Filter onder Diagnostics > Packet capture > Display filter op Source IP, Destination port: 443, Reason: Firewall en de verwachte Rule ID. Een UDP-pakket met status Violation in die regel is positief bewijs; alleen het ontbreken van UDP is dat niet.
5. Wijzig het filter in host 10.20.30.50 and proto TCP and dst port 443 en maak een nieuwe verbinding. De TCP-handshake en verwachte Rule ID bewijzen het netwerkpad.
6. Correleer in Log viewer > Firewall tijd, Source IP, bestemming, Rule ID, protocol en poort. Sessies verschijnen vaak pas bij het Connection Destroy event; controleer een open verbinding ook onder Current activities > Live connections.
7. Voer voor Web Protection vanuit dezelfde scope een toegestane en een door de Web Policy geblokkeerde request uit. Controleer voor TLS Inspection ook SSL/TLS inspection, de Decryption Rule en de zichtbare certificaatuitgever. Scan HTTP and decrypted HTTPS bewijst op zichzelf geen ontsleuteling.
8. Verwijder voor de negatieve test de pilot tijdelijk uit de scope of herstel de eerdere stand van Block QUIC protocol, maak een nieuwe sessie en controleer of UDP 443 terugkeert op het verwachte pad. Herstel daarna de goedgekeurde toestand.

Voor regeltests past de handleiding Sophos Firewall Regel testen met Log Viewer en Packet Capture.

Typische fouten

• QUIC-blokkering alleen in een oude of verkeerde regel geactiveerd: Het huidige clientverkeer loopt via een andere regel.
• Regel staat onder een algemenere toestaan-regel: QUIC wordt eerder toegestaan.
• Logging is uitgeschakeld: In de Log Viewer is niet zichtbaar wat er gebeurt.
• Bestaande browsersessie wordt hergebruikt: Herstart de browser of gebruik een testprofiel voordat je logs beoordeelt.
• Alleen Chrome lokaal aangepast: Andere browsers of apparaten gebruiken nog steeds QUIC.
• TLS Inspection wordt verwacht, maar niet geconfigureerd: HTTPS-inhoud wordt ondanks QUIC-blokkering niet ontsleuteld.
• Scan HTTP and decrypted HTTPS wordt verkeerd begrepen: De optie scant alleen al ontsleuteld HTTPS.
• DPI Mode en Web Proxy Mode worden door elkaar gehaald: De gezochte instelling bevindt zich dan mogelijk op een andere plek.
• UDP 443 wordt wereldwijd geblokkeerd: Speciale toepassingen kunnen onverwacht worden beïnvloed.

Probleemoplossing en SFOS 22-versies

Als webfiltering of scanning niet zoals verwacht werkt, moet je deze volgorde controleren:

1. Welke firewallregel matched het clientverkeer echt?
2. Is Block QUIC protocol in precies deze regel actief?
3. Gebruikt de client UDP 443 of TCP 443?
4. Is Log firewall traffic geactiveerd?
5. Grijpt een specifiekere regel erboven?
6. Is er een Application-Control-Policy die QUIC anders behandelt?
7. Is er een SSL/TLS Inspection Rule aanwezig als HTTPS-inhoud moet worden gecontroleerd?
8. Wordt DPI Mode of Web Proxy Mode gebruikt?
9. Toont Packet Capture uitgaande UDP 443-pakketten ondanks verwachte blokkade?

Toont de capture nog Forwarded-pakketten, controleer dan eerst Rule ID, Source-object, IPv4-/IPv6-pad, Services en regelvolgorde. Het pakket kan een andere regel matchen; een vinkje in een niet-matchende regel is geen globale blokkade. Ontbreekt elke UDP-poging, gebruik dan eerst een ander HTTP/3-geschikt testdoel.

Werkt de Web Policy na TCP-fallback niet, dan is QUIC niet automatisch de oorzaak. Bij regels met meerdere gebruikers of groepen telt ook de build: de officiële Release Notes vermelden in SFOS 22.0 MR1 Build 490 fix NC-176376 voor Web Policy-regels met meer dan één groep of gebruiker die na een upgrade naar 22.0 GA niet werkten. Controleer build, Rule ID en gebruikerscontext vóór wijzigingen aan QUIC of TLS; een upgrade volgt het normale backup- en wijzigingsproces.

Als de regel niet matched, is niet QUIC het hoofdprobleem, maar regelvolgorde, bronzone, bronnetwerk, bestemming, service of uitsluiting. Daarvoor helpt Firewall-regel grijpt niet: Oorzaken controleren.

Bedrijfschecklist

• Betreffende client-internetregel duidelijk geïdentificeerd.
• Webbeleid, malware-scan of TLS Inspection in precies deze regel gecontroleerd.
• Block QUIC protocol bewust geactiveerd of gemotiveerd gedeactiveerd.
• DPI Mode of Web Proxy Mode bewust gekozen.
• Regelvolgorde en algemenere toestaan-regels gecontroleerd.
• Log firewall traffic actief.
• Test met browser en echte doelpagina uitgevoerd.
• Log Viewer op UDP 443, TCP 443, regel-ID en webgebeurtenissen gecontroleerd.
• Bij TLS Inspection ook SSL/TLS-inspectielogs gecontroleerd.
• Uitzonderingen of eigen UDP-regels gedocumenteerd.
• Helpdesk weet dat websites na QUIC-blokkering normaal gesproken verder moeten functioneren.

Rollback

Leg vóór de pilot regelstatus en -positie, Block QUIC protocol, Web Policy, Application Filter, logging, NAT en TLS-/proxymodus vast. Schakel voor rollback de pilotregel uit of herstel exact de eerdere opties en policies. Sluit browser en sessies en controleer met een nieuwe verbinding de eerdere Rule ID en het eerdere UDP-/TCP-gedrag. Verwijder pas daarna uitsluitend pilotobjecten; verwijder geen gedeelde Services, filters of NAT-regels.

Veelgestelde vragen