Hoppa till innehållet
Avanet

Blockera QUIC och HTTP/3 korrekt med Sophos Firewall

QUIC är ett modernt, krypterat transportprotokoll över UDP; HTTP/3 använder QUIC som transport. Begreppen är därför nära förbundna, men inte identiska. Webbläsare och webbtjänster använder vanligtvis HTTP/3 över UDP 443. För administratören är det avgörande att detta inte är den klassiska HTTPS-vägen över TCP.

På Sophos Firewall är detta viktigt eftersom SFOS 22-dokumentationen anger att webbfiltret inte kan skanna QUIC och att QUIC kringgår Web Filtering. Om en klientregel ska framtvinga en Web Policy, malware-skanning eller TCP-baserad TLS-inspektion är Block QUIC protocol därför den dokumenterade standardmetoden. Alternativet väntar inte på att identifiera en QUIC-handshake: inom den matchande brandväggsregelns omfattning stoppas alla utgående UDP-paket till destinationsportarna 80 och 443.

Vilken webbskyddsartikel passar?

QUIC är oftast inte det egentliga målet, utan en störfaktor i webbskydds-, TLS-inspektions- eller felsökningsscenarier. Beroende på uppgift passar en annan ingång:

Denna artikel svarar främst på frågan när och hur man blockerar QUIC respektive HTTP/3 i den passande brandväggsregeln och sedan validerar korrekt.

Vad QUIC betyder för brandväggen

Klassisk HTTPS körs oftast över TCP 443. Brandväggen kan beroende på regel, webbpolicy, DPI-motor, webbproxy och SSL/TLS-inspektion avgöra om trafik bara tillåts, kategoriseras, dekrypteras, skannas eller blockeras.

HTTP/3 flyttar denna webbtrafik till QUIC över UDP. För brandväggen betyder det:

  • Webbtrafik ser inte längre ut som klassisk HTTPS över TCP.
  • QUIC kan kringgå SFOS Web Filtering och kan inte skannas av detta webbfilter.
  • TLS-inspektion fungerar inte som vid normal HTTPS över TCP.
  • Felsökning blir svårare när webbläsare automatiskt växlar mellan TCP och QUIC.
  • Policy Tester, Log Viewer och Packet Capture måste medvetet jämföras med protokoll och port.

Alternativet Block QUIC protocol stoppar utgående UDP-paket till destinationsportarna 80 och 443 när trafiken uppfyller regelns kriterier. Om klienten använder en annan regel har alternativet ingen effekt. Eftersom blockeringen är portbaserad kan även en icke-QUIC-applikation som använder UDP 80 eller 443 påverkas. Vanliga webbläsare försöker normalt HTTPS över TCP när HTTP/3 misslyckas, men denna fallback måste verifieras för varje verksamhetskritisk applikation.

HTTPS dekrypteras inte automatiskt av detta. QUIC-blockeringen flyttar bara trafiken till en mer kontrollerbar TCP-väg. Om web policy, malware scan, application control eller TLS-inspektion sedan griper beror på resten av regel- och inspektionskonfigurationen.

När man bör blockera QUIC

I många produktiva klientnätverk är det meningsfullt att blockera QUIC om ett eller flera av dessa uttalanden stämmer:

  • Webbfiltrering ska fungera pålitligt.
  • Malware-skanning för webbnedladdningar är viktigt.
  • TLS-inspektion används för utvalda kategorier eller användargrupper.
  • Applikationskontroll ska bättre känna igen webbapplikationer.
  • Webbtillgångar ska kunna spåras i Log Viewer.
  • Helpdesk och säkerhetsteam ska kunna genomföra reproducerbara tester.

Att tillåta QUIC kan vara ett medvetet val på gäst-Wi-Fi utan Web Filtering eller innehållsinspektion; dokumentera då att SFOS-webbfiltret inte skannar UDP-vägen. För hanterade nät eller compliance-scope är regelblockeringen oftast lättare att motivera. Testa servrar och specialapplikationer separat eftersom inte varje QUIC-klient garanterar TCP-fallback.

Kontrollera inställning i brandväggsregeln

Den vanliga platsen är den utgående brandväggsregeln, till exempel LAN_to_WAN_Clients. I SFOS 22 finns alternativet under Security features > Web filtering > Block QUIC protocol.

Menypath:

Rules and policies > Firewall rules

Förfarande:

För en pilot kan den befintliga internetregeln kopieras eller en snäv regel skapas ovanför den. Ett dokumenterbart exempel använder Source zones: LAN, Source networks and devices: CLIENT-WEB-01 med 10.20.30.50, Destination zones: WAN, Destination networks: Any samt de Services och Security Policies som redan behövs i produktion. Ersätt IP och objektnamn med en entydig testklient; låt Destination, NAT och skyddsprofiler vara oförändrade inledningsvis.

  1. Öppna den berörda klient-internetregeln.
  2. Gå till Security features > Web filtering.
  3. Aktivera Log firewall traffic så att tester syns i Log Viewer.
  4. Kontrollera avsedd Web Policy och Scan HTTP and decrypted HTTPS.
  5. Låt Block QUIC protocol vara aktiverat eller aktivera medvetet.
  6. Aktivera Scan HTTP and decrypted HTTPS endast om det också är klart hur HTTPS dekrypteras.
  7. I DPI Mode, kontrollera att Use web proxy instead of DPI engine inte råkar vara aktivt.
  8. I Web Proxy Mode, kontrollera om Decrypt HTTPS during web proxy filtering och CA-distributionen passar målet.
  9. Spara regeln.
  10. Kontrollera testklienten och Log Viewer.

SFOS 22 väljer Block QUIC protocol som standard när en Web Policy väljs eller Scan HTTP and decrypted HTTPS aktiveras. Det är ett standardvärde i gränssnittet för denna regel, inte en global policy. Efter migration, kopiering eller ändrad regelordning kontrolleras den regel som faktiskt matchar igen.

Sophos Firewall-regel med alternativet Block QUIC protocol aktiverat
Alternativet Block QUIC protocol finns i brandväggsregeln under Security features > Web filtering och gäller bara trafik som matchar denna regel.

Mer om de enskilda alternativen för en brandväggsregel finns i Förstå och konfigurera Sophos Firewall-regler korrekt.

Inaktivera inte bara QUIC via webbläsaren

Tidigare var det vanligt att inaktivera QUIC direkt i webbläsaren eller via Chrome Flags. Det kan hjälpa för tester, men är inget hållbart säkerhetskoncept:

  • Webbläsarinställningar ändras.
  • Inte bara Chrome kan använda QUIC eller HTTP/3.
  • Användare eller uppdateringar kan återställa inställningar.
  • BYOD-, gäst- och ohanterade enheter kan knappast kontrolleras med detta.
  • Säkerhetspolicyer bör vara centralt spårbara på brandväggen.

För produktiva miljöer är brandväggsregeln den bättre platsen. Webbläsarbaserade tester kan vara användbara som komplement när man vill avgränsa ett fel.

Placera Application Control och egna UDP-regler rätt

Förutom Block QUIC protocol finns det andra sätt att begränsa QUIC-trafik.

  • Block QUIC protocol i brandväggsregeln: Standardfall för webbfiltrering och skanning Gäller endast för trafik som matchar denna regel
  • Application Control: signaturbaserad identifiering och loggning kan komplettera blockeringen. Kontrollera under Applications > Application list om aktuell patternversion har en lämplig QUIC-post; en historisk skärmbild bevisar inte dagens katalog. Ett Application Filter fungerar först när det tilldelats den matchande regeln under Other security features > Identify and control applications (App control).
  • Egen drop-regel för UDP 80/443: Mycket tydlig teknisk blockering Måste placeras korrekt och begränsas till klientnätverk
  • Webbläsarkonfiguration: Korttest eller hanterad specialmiljö Inte robust nog som enda brandväggspolicy

Om en egen drop-regel används bör den placeras ovanför allmänna klient-internetregler och loggas ordentligt. Annars är det senare inte tydligt om QUIC medvetet blockerades eller om trafiken fastnade någon annanstans.

Om ändringen kräver en separat blockeringsregel skapas exempelvis QUIC_UDP_80_443 under Hosts and services > Services > Add med Type of service: UDP och Destination port: 80,443. Lämna standardvärdet Source port: 1:65535 oförändrat. Regeln ovanför generell Allow använder Action: Drop, Source zones: LAN, pilotobjektet under Source networks and devices, Destination zones: WAN, Destination networks: Any, denna Service och Log firewall traffic. Anpassa namn, Source-scope och position; håll UDP-destinationsportarna snäva och validera eventuell påverkan på icke-QUIC-trafik separat.

Application Control är inte en likvärdig ersättning för det dokumenterade portbaserade alternativet när TCP-webbfiltervägen ska framtvingas. Signaturer ändras med patternuppdateringar och URL-baserade micro apps kräver att DPI Engine ser den dekrypterade URL:en. Korrelera därför Application-, Firewall-, Web- och SSL/TLS-inspektionsloggar.

Sophos Firewall applikationskontrollfilter med QUIC
Applikationskontroll kan dessutom känna igen och blockera QUIC, men ersätter inte kontrollen av brandväggsregeln.
Sophos Firewall brandväggsregel med applikationskontrollfilter för QUIC
Applikationskontrollpolicyer måste vara aktiva i den passande brandväggsregeln för att påverka klienttrafiken.

Samband med TLS-inspektion

Block QUIC protocol är ingen ersättning för TLS-inspektion. Inställningen säkerställer bara att webbläsare vid passande trafik inte fortsätter över QUIC, utan normalt faller tillbaka på HTTPS över TCP.

Först därefter uppstår den egentliga TLS-frågan:

  • Finns det en passande SSL/TLS-inspektionsregel?
  • Är CA-certifikatet distribuerat på klienterna?
  • Dekrypteras trafiken eller dekrypteras den medvetet inte?
  • Är Scan HTTP and decrypted HTTPS aktiv i brandväggsregeln?
  • Finns det undantag för applikationer med certifikatspinning?

Om HTTPS-innehåll ska granskas behövs en planerad TLS-utbyggnad. Detaljerna finns i Inför Sophos Firewall TLS-inspektion korrekt.

Regelns driftläge är viktigt. I DPI Mode gäller SSL/TLS Inspection Rules under Rules and policies > SSL/TLS inspection rules. I Web Proxy Mode styrs HTTPS-Decryption via web proxy-inställningarna och alternativet Decrypt HTTPS during web proxy filtering. Om dessa två modeller blandas ihop ser QUIC snabbt ut som huvudproblemet, trots att inspektionsarkitekturen egentligen är oklar.

Välj DPI Engine eller Web Proxy korrekt förklarar funktions- och migreringsvalet mellan dessa trafikvägar.

Bevisa effekten med positivt och negativt test

Att webbplatsen är nåbar bevisar inte fallback. Valideringen skiljer på tre frågor: stoppade den förväntade regeln UDP 443, upprättades därefter en ny TCP-anslutning och tillämpades avsett Web- eller TLS-beslut på den vägen?

Praktisk testprocedur:

  1. Notera tidigare tillstånd, Rule ID, klient-IP, testmål och tid. Bekräfta först att målet genererar ett UDP-443-försök; annars säger testet inget om QUIC.
  2. Aktivera Log firewall traffic och återställ valfritt pilotregelns Usage Counter.
  3. Klicka på Configure under Diagnostics > Packet capture och ange host 10.20.30.50 and proto UDP and dst port 443 i Enter BPF string. Ersätt IP-adressen, starta capture, stäng och öppna webbläsaren helt och anropa det förberedda målet.
  4. Under Diagnostics > Packet capture > Display filter, filtrera på Source IP, Destination port: 443, Reason: Firewall och förväntad Rule ID. Ett UDP-paket med status Violation i regeln är positivt bevis; enbart frånvaro av UDP är det inte.
  5. Ändra filtret till host 10.20.30.50 and proto TCP and dst port 443 och skapa en ny anslutning. TCP-handshake och förväntad Rule ID bevisar nätverksvägen.
  6. Korrelera tid, Source IP, destination, Rule ID, protokoll och port i Log viewer > Firewall. Sessioner visas ofta först vid Connection Destroy event; kontrollera även en öppen anslutning under Current activities > Live connections.
  7. För Web Protection görs från samma scope en tillåten begäran och en som blockeras av Web Policy. För TLS-inspektion kontrolleras även SSL/TLS inspection, Decryption Rule och synlig certifikatsutfärdare. Scan HTTP and decrypted HTTPS bevisar inte i sig dekryptering.
  8. I negativtestet tas pilotklienten tillfälligt ur scope eller återställs tidigare läge för Block QUIC protocol. Skapa en session och bekräfta att UDP 443 åter syns på förväntad väg. Återställ sedan godkänt tillstånd.

För regeltester passar instruktionen Testa Sophos Firewall-regel med Log Viewer och Packet Capture.

Typiska fel

  • QUIC-block endast aktiverat i en gammal eller felaktig regel: Den aktuella klienttrafiken går genom en annan regel
  • Regel står under en mer allmän tillåtelse-regel: QUIC tillåts tidigare
  • Loggning är inaktiverad: I Log Viewer är det inte synligt vad som händer
  • Befintlig webbläsarsession återanvänds: Starta om webbläsaren eller använd en testprofil innan loggar utvärderas
  • Endast Chrome anpassad lokalt: Andra webbläsare eller enheter använder fortfarande QUIC
  • TLS-inspektion förväntas men är inte konfigurerad: HTTPS-innehåll dekrypteras inte trots QUIC-block
  • Scan HTTP and decrypted HTTPS missförstås: Alternativet skannar endast redan dekrypterad HTTPS
  • DPI Mode och Web Proxy Mode blandas ihop: Den sökta inställningen kan då finnas på en annan plats
  • UDP 443 blockeras globalt: Specialapplikationer kan oväntat påverkas

Felsökning och SFOS 22-versioner

Om webbfiltrering eller skanning inte fungerar som förväntat bör man kontrollera denna ordning:

  1. Vilken brandväggsregel matchar klienttrafiken verkligen?
  2. Är Block QUIC protocol aktiv i just denna regel?
  3. Använder klienten UDP 443 eller TCP 443?
  4. Är Log firewall traffic aktiverat?
  5. Greppar en mer specifik regel ovanför?
  6. Finns det en applikationskontrollpolicy som behandlar QUIC annorlunda?
  7. Finns det en SSL/TLS-inspektionsregel om HTTPS-innehåll ska granskas?
  8. Används DPI Mode eller Web Proxy Mode?
  9. Visar Packet Capture utgående UDP 443-paket trots förväntad blockering?

Om capture fortfarande visar Forwarded-paket kontrolleras först Rule ID, Source-objekt, IPv4-/IPv6-väg, Services och regelordning. Paketet kan matcha en annan regel; en markering i en regel som inte matchar är inget globalt block. Om inget UDP-försök finns används ett annat HTTP/3-kompatibelt testmål.

Om Web Policy inte fungerar efter TCP-fallback är QUIC inte automatiskt orsaken. För regler med flera användare eller grupper spelar även build roll: de officiella Release Notes anger i SFOS 22.0 MR1 Build 490 fix NC-176376 för Web Policy-regler med mer än en grupp eller användare som slutade fungera efter uppgradering till 22.0 GA. Kontrollera build, Rule ID och användarkontext före ändringar av QUIC eller TLS; uppgradering följer ordinarie backup- och changeprocess.

Om regeln inte matchar är inte QUIC huvudproblemet, utan regelordning, källzon, källnätverk, destination, tjänst eller undantag. För detta hjälper Brandväggsregel matchar inte: Kontrollera orsaker.

Driftschecklista

  • Berörd klient-internetregel tydligt identifierad.
  • Webbpolicy, malware-skanning eller TLS-inspektion i just denna regel kontrollerad.
  • Block QUIC protocol medvetet aktiverat eller motiverat inaktiverat.
  • DPI Mode eller Web Proxy Mode medvetet valt.
  • Regelordning och mer allmänna tillåtelse-regler kontrollerade.
  • Log firewall traffic aktiv.
  • Test med webbläsare och verklig målsida genomförd.
  • Log Viewer kontrollerad för UDP 443, TCP 443, regel-ID och webbhändelser.
  • Vid TLS-inspektion, kontrollera dessutom SSL/TLS-inspektionsloggar.
  • Undantag eller egna UDP-regler dokumenterade.
  • Helpdesk vet att webbplatser normalt bör fungera vidare efter QUIC-block.

Återställning

Före piloten dokumenteras regelstatus och position, Block QUIC protocol, Web Policy, Application Filter, loggning, NAT och TLS-/proxyläge. För återställning inaktiveras pilotregeln eller återställs exakt tidigare alternativ och policies. Stäng webbläsare och sessioner och verifiera med en ny anslutning tidigare Rule ID och UDP-/TCP-beteende. Först därefter tas enbart pilotobjekt bort; delade Services, filter och NAT-regler raderas inte.

Vanliga frågor

Är QUIC osäkert?

QUIC är inte generellt osäkert. Begränsningen i SFOS 22 är att webbfiltret inte kan skanna QUIC och att QUIC kringgår Web Filtering; det inaktiverar inte automatiskt alla andra brandväggskontroller.

Räcker det att blockera UDP 443?

En drop-regel för UDP 443 stoppar den vanliga HTTP/3-vägen men blockerar också icke-QUIC-trafik på porten. Block QUIC protocol är bättre dokumenterat för SFOS-webbfiltret och omfattar även UDP 80. Båda alternativen måste passa faktisk regel, klientscope och negativtest.

Dekrypteras HTTPS automatiskt när QUIC blockeras?

Nej. QUIC-block säkerställer bara att webbläsare normalt faller tillbaka på HTTPS över TCP. För HTTPS-dekryptering behövs dessutom SSL/TLS-inspektionsregler och ett distribuerat CA-certifikat.

Bör man blockera QUIC i varje nätverk?

Inte nödvändigtvis. För hanterade klientnätverk är det oftast meningsfullt. För gäst-WLAN, testnätverk eller mycket enkla internetanslutningar kan man besluta annorlunda. Viktigt är att beslutet medvetet passar webbfilter-, loggnings- och inspektionsstrategin.

Varför fungerar en webbplats fortfarande efter blockering?

Det är oftast önskat. Webbläsare faller ofta automatiskt från QUIC till vanlig HTTPS över TCP. Sidan fungerar vidare, men brandväggen kan bättre placera trafiken i den normala webbfilter- och skanningsvägen.