Sophos Firewall QUIC und HTTP/3 richtig blockieren

QUIC ist ein modernes, verschlüsseltes Transportprotokoll über UDP; HTTP/3 verwendet QUIC als Transport. Die Begriffe sind deshalb eng verbunden, aber nicht identisch. Browser und Webdienste nutzen HTTP/3 üblicherweise über UDP 443. Für Administratoren ist entscheidend, dass dieser Pfad nicht dem klassischen HTTPS-Pfad über TCP entspricht.

Auf der Sophos Firewall ist das wichtig, weil der Webfilter QUIC laut SFOS-22-Dokumentation nicht scannt und QUIC das Web Filtering umgeht. Soll eine Client-Regel Web Policy, Malware-Scanning oder TCP-basierte TLS Inspection erzwingen, ist Block QUIC protocol deshalb der dokumentierte Standardweg. Der Schalter erkennt dabei nicht erst einen QUIC-Handshake: Er verwirft innerhalb der zutreffenden Firewall-Regel alle ausgehenden UDP-Pakete zu den Zielports 80 und 443.

Welcher Web-Protection-Artikel passt?

QUIC ist meistens nicht das eigentliche Ziel, sondern ein Störfaktor in Web-Protection-, TLS-Inspection- oder Troubleshooting-Szenarien. Je nach Aufgabe passt ein anderer Einstieg:

• Web Policy, URL Groups, SafeSearch und Webfilter grundsätzlich planen: Sophos Firewall Web Protection mit Web Policies einrichten.
• Web-Kategorien und Instant Alerts betreiben: Sophos Firewall Web-Kategorien und Instant Alerts nutzen.
• HTTPS-Traffic entschlüsseln und kontrolliert ausrollen: Sophos Firewall TLS Inspection richtig einführen.
• Prüfen, welche Firewall-Regel wirklich zutrifft: Sophos Firewall Regel testen mit Log Viewer und Packet Capture.

Dieser Artikel beantwortet vor allem die Frage, wann und wie man QUIC beziehungsweise HTTP/3 in der passenden Firewall-Regel blockiert und danach sauber validiert.

Was QUIC für die Firewall bedeutet

Klassisches HTTPS läuft meistens über TCP 443. Die Firewall kann dabei je nach Regel, Web Policy, DPI Engine, Web Proxy und SSL/TLS Inspection entscheiden, ob der Datenverkehr nur erlaubt, kategorisiert, entschlüsselt, gescannt oder blockiert wird.

HTTP/3 verschiebt diesen Webtraffic auf QUIC über UDP. Für die Firewall bedeutet es:

• Webtraffic sieht nicht mehr wie klassisches HTTPS über TCP aus.
• QUIC kann das SFOS Web Filtering umgehen und kann von diesem Webfilter nicht gescannt werden.
• TLS Inspection greift nicht wie bei normalem HTTPS über TCP.
• Troubleshooting wird schwieriger, wenn Browser automatisch zwischen TCP und QUIC wechseln.
• Policy Tester, Log Viewer und Packet Capture müssen bewusst mit Protokoll und Port verglichen werden.

Die Option Block QUIC protocol verwirft ausgehende UDP-Pakete zu den Zielports 80 und 443, sofern der Datenverkehr die Kriterien der betreffenden Firewall-Regel erfüllt. Wenn ein Client über eine andere Regel ins Internet geht, hat die Einstellung in der Standardregel keine Wirkung. Weil der Schalter portbasiert arbeitet, kann er auch eine Nicht-QUIC-Anwendung treffen, die UDP 80 oder 443 verwendet. Übliche Browser versuchen nach erfolglosem HTTP/3-Aufbau meist HTTPS über TCP; diese Rückfalleigenschaft muss jedoch für jede geschäftskritische Anwendung geprüft werden.

Dabei wird HTTPS nicht automatisch entschlüsselt. Die QUIC-Sperre bringt den Datenverkehr nur in einen besser kontrollierbaren TCP-Pfad. Ob danach Web Policy, Malware Scan, Application Control oder TLS Inspection greifen, entscheidet die übrige Regel- und Inspektionskonfiguration.

Wann man QUIC blockieren sollte

In vielen produktiven Client-Netzen ist das Blockieren von QUIC sinnvoll, wenn eine oder mehrere dieser Aussagen zutreffen:

• Webfiltering soll zuverlässig greifen.
• Malware-Scanning für Webdownloads ist wichtig.
• TLS Inspection wird für ausgewählte Kategorien oder Benutzergruppen eingesetzt.
• Application Control soll Webanwendungen besser erkennen.
• Webzugriffe sollen im Log Viewer nachvollziehbar sein.
• Helpdesk und Security-Team sollen reproduzierbare Tests durchführen können.

Für ein Gäste-WLAN ohne Web Filtering oder Inhaltsprüfung kann erlaubtes QUIC eine bewusste Entscheidung sein. Dann dokumentiert man, dass der UDP-Pfad nicht durch den SFOS-Webfilter gescannt wird. Für verwaltete Client-Netze oder Netze mit Compliance-Vorgaben ist die regelbezogene Sperre meist die nachvollziehbarere Wahl. Server- und Spezialanwendungen werden separat getestet, weil nicht jeder QUIC-basierte Client garantiert auf TCP zurückfällt.

Einstellung in der Firewall-Regel prüfen

Der normale Ort ist die ausgehende Firewall-Regel, zum Beispiel LAN_to_WAN_Clients. In SFOS 22 befindet sich die Einstellung unter Security features > Web filtering > Block QUIC protocol.

Wichtig ist: Das ist kein globaler Schalter für die ganze Firewall. Die Option wirkt nur auf Datenverkehr, für den diese Firewall-Regel tatsächlich zutrifft. Wenn eine allgemeinere Allow-Regel weiter oben bereits zutrifft, muss QUIC dort blockiert oder die Regelreihenfolge korrigiert werden.

Menüpfad:

Rules and policies > Firewall rules

Für einen Pilotclient kann die bestehende Internetregel kopiert oder eine enge Regel oberhalb davon angelegt werden. Als nachvollziehbares Beispiel verwendet die Pilotregel Source zones: LAN, Source networks and devices: CLIENT-WEB-01 mit 10.20.30.50, Destination zones: WAN, Destination networks: Any und die bereits produktiv benötigten Services und Security Policies. 10.20.30.50 und die Objektnamen sind Platzhalter und werden durch einen eindeutig zuordenbaren Testclient ersetzt; Destination, NAT und Schutzprofile bleiben gegenüber dem bisherigen Pfad zunächst unverändert.

Vorgehen:

1. Betroffene Client-Internetregel öffnen.
2. Zu Security features > Web filtering gehen.
3. Log firewall traffic aktivieren, damit Tests im Log Viewer sichtbar werden.
4. Die vorgesehene Web policy und Scan HTTP and decrypted HTTPS prüfen.
5. Block QUIC protocol aktiviert lassen oder bewusst aktivieren.
6. Scan HTTP and decrypted HTTPS nur aktivieren, wenn auch klar ist, wie HTTPS entschlüsselt wird.
7. Bei DPI Mode prüfen, dass Use web proxy instead of DPI engine nicht versehentlich aktiv ist.
8. Bei Web Proxy Mode prüfen, ob Decrypt HTTPS during web proxy filtering und die CA-Verteilung zum Ziel passen.
9. Regel speichern.
10. Testclient prüfen und Log Viewer kontrollieren.

SFOS 22 wählt Block QUIC protocol standardmässig aus, sobald man eine Web Policy auswählt oder Scan HTTP and decrypted HTTPS einschaltet. Das ist eine UI-Voreinstellung für diese Regel, keine globale Policy. Nach Migrationen, kopierten Regeln und Änderungen der Regelreihenfolge kontrolliert man deshalb erneut die tatsächlich zutreffende Regel.

Mehr zu den einzelnen Optionen einer Firewall-Regel steht in Sophos Firewall-Regeln verstehen und richtig konfigurieren.

QUIC nicht nur per Browser deaktivieren

Früher war es üblich, QUIC direkt im Browser oder über Chrome Flags zu deaktivieren. Das kann für Tests helfen, ist aber kein belastbares Sicherheitskonzept:

• Browser-Einstellungen ändern sich.
• Nicht nur Chrome kann QUIC oder HTTP/3 verwenden.
• Benutzer oder Updates können Einstellungen zurücksetzen.
• BYOD-, Gast- und unmanaged Geräte lassen sich damit kaum kontrollieren.
• Security Policies sollten zentral auf der Firewall nachvollziehbar sein.

Für produktive Umgebungen ist die Firewall-Regel der bessere Ort. Browser-seitige Tests können ergänzend nützlich sein, wenn man einen Fehler eingrenzen möchte.

Application Control und eigene UDP-Regeln richtig einordnen

Neben Block QUIC protocol gibt es weitere Möglichkeiten, QUIC-Traffic einzuschränken.

• Block QUIC protocol in der Firewall-Regel: Standardfall für Webfiltering und Scanning. Grenze: Die Einstellung greift nur für Datenverkehr, für den diese Regel zutrifft.
• Application Control: Signaturbasierte Erkennung und Protokollierung können ergänzen. Ob die aktuelle Pattern-Version einen passenden QUIC-Eintrag anbietet, wird unter Applications > Application list geprüft; ein historischer Screenshot ist dafür kein Nachweis. Ein Application Filter wirkt erst, wenn er unter Other security features > Identify and control applications (App control) der zutreffenden Firewall-Regel zugewiesen ist.
• Eigene Drop-Regel für UDP 80/443: Sehr klare technische Blockade. Grenze: Die Regel muss richtig positioniert und auf Client-Netze begrenzt werden.
• Browser-Konfiguration: Nützlich für Kurztests oder verwaltete Spezialumgebungen. Grenze: Nicht robust genug als alleinige Firewall-Policy.

Wenn eine eigene Drop-Regel verwendet wird, sollte sie oberhalb allgemeiner Client-Internetregeln stehen und vollständig protokolliert werden. Sonst ist später nicht erkennbar, ob QUIC bewusst blockiert wurde oder ob der Datenverkehr an einer anderen Stelle hängen bleibt.

Falls eine Änderung ausdrücklich eine separate Sperrregel verlangt, wird unter Hosts and services > Services > Add zum Beispiel QUIC_UDP_80_443 mit Type of service: UDP und Destination port: 80,443 angelegt. Der voreingestellte Source port: 1:65535 bleibt unverändert. Die oberhalb der allgemeinen Allow-Regel platzierte Firewall-Regel verwendet Action: Drop, Source zones: LAN, das Pilotobjekt unter Source networks and devices, Destination zones: WAN, Destination networks: Any, diesen Service und Log firewall traffic. Namen, Quellbereich und Position sind an die Umgebung anzupassen; die UDP-Zielports bleiben bewusst eng gefasst, und mögliche Auswirkungen auf Nicht-QUIC-Datenverkehr werden separat abgenommen.

Application Control ist kein gleichwertiger Ersatz für den dokumentierten portbasierten Schalter, wenn der TCP-Webfilterpfad erzwungen werden soll. Signaturen und Klassifizierungen können sich mit Pattern-Updates ändern. Für URL-basierte Micro Apps braucht die DPI Engine zudem die entschlüsselte URL. Deshalb werden Application-, Firewall-, Web- und SSL/TLS-Inspection-Logs zusammen ausgewertet.

Zusammenhang mit TLS Inspection

Block QUIC protocol ist kein Ersatz für TLS Inspection. Die Einstellung sorgt nur dafür, dass Browser bei passendem Traffic nicht über QUIC weiterkommunizieren, sondern normalerweise auf HTTPS über TCP zurückfallen.

Erst danach stellt sich die eigentliche TLS-Frage:

• Gibt es eine passende SSL/TLS Inspection Rule?
• Ist das CA-Zertifikat auf den Clients verteilt?
• Wird der Traffic entschlüsselt oder bewusst nicht entschlüsselt?
• Ist Scan HTTP and decrypted HTTPS in der Firewall Regel aktiv?
• Gibt es Ausnahmen für Anwendungen mit Certificate Pinning?

Wenn HTTPS-Inhalte geprüft werden sollen, braucht es einen geplanten TLS-Rollout. Die Details stehen in Sophos Firewall TLS Inspection richtig einführen.

Wichtig ist die Betriebsart der Regel. Im DPI Mode greifen SSL/TLS Inspection Rules unter Rules and policies > SSL/TLS inspection rules. Im Web Proxy Mode wird HTTPS-Decryption über die Web-Proxy-Einstellungen und die Option Decrypt HTTPS during web proxy filtering gesteuert. Wenn man diese beiden Modelle vermischt, sieht QUIC schnell wie das Hauptproblem aus, obwohl eigentlich die Inspection-Architektur unklar ist.

Die Funktions- und Migrationsentscheidung zwischen diesen Datenpfaden erklärt DPI Engine oder Web Proxy richtig wählen.

Wirkung mit Positiv- und Negativtest nachweisen

Eine erreichbare Webseite allein beweist den Rückfall nicht. Die Abnahme trennt drei Fragen: Wurde UDP 443 in der erwarteten Regel verworfen, entstand danach eine neue TCP-Verbindung und griff auf diesem TCP-Pfad die gewünschte Web- beziehungsweise TLS-Entscheidung?

Praktischer Testablauf:

1. Vorzustand, Rule ID der Firewall-Regel, Client-IP, Testziel und Uhrzeit notieren. Im Browser oder in einem Capture zuerst bestätigen, dass das Ziel überhaupt einen UDP-443-Versuch erzeugt; sonst ist der Test für QUIC nicht aussagekräftig.
2. Log firewall traffic aktivieren und den Usage Counter der Pilotregel optional zurücksetzen. Das ändert keine Policy, erleichtert aber die Zuordnung neuer Verbindungen.
3. Unter Diagnostics > Packet capture auf Configure klicken und in Enter BPF string für das Beispiel host 10.20.30.50 and proto UDP and dst port 443 eintragen. Die IP wird durch die echte Pilot-IP ersetzt. Capture starten, Browser vollständig beenden und neu öffnen, dann das vorbereitete Ziel aufrufen.
4. Unter Diagnostics > Packet capture > Display filter nach Source IP, Destination port: 443, Reason: Firewall und der erwarteten Rule ID eingrenzen. Ein UDP-Paket mit Status Violation in dieser Regel ist der Positivnachweis für den Schalter; ausbleibender UDP-Traffic allein ist es nicht.
5. Für den Rückfall den Capture-Filter auf host 10.20.30.50 and proto TCP and dst port 443 ändern und eine neue Verbindung erzeugen. Der TCP-Handshake und die erwartete Rule ID der Firewall-Regel belegen den Netzwerkpfad.
6. Im oben rechts geöffneten Log viewer das Modul Firewall wählen und mit Zeit, Source IP, Destination, Rule ID, Protokoll und Port korrelieren. Firewall-Sessions erscheinen häufig erst beim Connection Destroy event; eine noch offene Verbindung wird zusätzlich unter Current activities > Live connections geprüft.
7. Ist Web Protection Teil des Ziels, einen bewusst erlaubten und einen durch die Web Policy blockierten Request aus demselben Client-Scope ausführen. Bei TLS Inspection zusätzlich das Modul SSL/TLS inspection, die getroffene Decryption Rule und den im Browser sichtbaren Zertifikatsaussteller prüfen. Scan HTTP and decrypted HTTPS allein beweist keine Entschlüsselung.
8. Als Negativtest den Pilotclient aus dem Scope nehmen oder Block QUIC protocol nur kurz auf den dokumentierten Vorzustand setzen, eine neue Session erzeugen und prüfen, ob wieder UDP 443 auf dem erwarteten Regelpfad erscheint. Danach den freigegebenen Sollzustand wiederherstellen.

Für Regeltests passt die Anleitung Sophos Firewall Regel testen mit Log Viewer und Packet Capture.

Typische Fehler

• QUIC-Block nur in einer alten oder falschen Regel aktiviert: Der aktuelle Client-Traffic läuft über eine andere Regel.
• Regel steht unterhalb einer allgemeineren Allow-Regel: QUIC wird vorher erlaubt.
• Logging ist deaktiviert: Im Log Viewer ist nicht sichtbar, was passiert.
• Bestehende Browser-Session wird weiterverwendet: Browser neu starten oder Testprofil verwenden, bevor man Logs bewertet.
• Nur Chrome lokal angepasst: Andere Browser oder Geräte nutzen QUIC weiterhin.
• TLS Inspection wird erwartet, aber nicht konfiguriert: HTTPS-Inhalte werden trotz QUIC-Block nicht entschlüsselt.
• Scan HTTP and decrypted HTTPS wird falsch verstanden: Die Option scannt nur bereits entschlüsseltes HTTPS.
• DPI Mode und Web Proxy Mode werden vermischt: Die gesuchte Einstellung liegt dann möglicherweise an einer anderen Stelle.
• UDP 443 wird global blockiert: Spezialanwendungen können unerwartet betroffen sein.

Troubleshooting und SFOS-22-Versionshinweise

Wenn Webfiltering oder Scanning nicht wie erwartet greift, sollte man diese Reihenfolge prüfen:

1. Welche Firewall-Regel trifft auf den Client-Datenverkehr wirklich zu?
2. Ist Block QUIC protocol in genau dieser Regel aktiv?
3. Nutzt der Client UDP 443 oder TCP 443?
4. Ist Log firewall traffic aktiviert?
5. Greift eine spezifischere Regel oberhalb?
6. Gibt es eine Application-Control-Policy, die QUIC anders behandelt?
7. Ist eine SSL/TLS Inspection Rule vorhanden, wenn HTTPS-Inhalte geprüft werden sollen?
8. Wird DPI Mode oder Web Proxy Mode verwendet?
9. Zeigt Packet Capture ausgehende UDP 443 Pakete trotz erwarteter Blockade?

Erscheinen bei einem Capture weiterhin Forwarded-Pakete, werden zuerst Rule ID, Source-Objekt, IPv4-/IPv6-Pfad, Services und Regelreihenfolge geprüft. Ein UDP-Paket kann eine andere Regel treffen; der Haken in einer nicht zutreffenden Regel ist kein globaler Block. Fehlt dagegen schon der UDP-Versuch, wird ein anderes HTTP/3-fähiges Testziel verwendet, bevor man einen Fehler der Firewall annimmt.

Greift nach dem TCP-Rückfall die Web Policy nicht, ist QUIC nicht automatisch die Ursache. Bei Regeln mit mehreren Benutzern oder Gruppen ist auch der installierte SFOS-22-Build relevant: Die offiziellen Release Notes führen für SFOS 22.0 MR1 Build 490 den Fix NC-176376 auf; betroffen waren Web-Policy-Regeln mit mehr als einer Gruppe oder einem Benutzer nach einem Upgrade auf 22.0 GA. Build, Rule ID und Benutzerkontext werden geprüft, bevor man QUIC oder TLS-Einstellungen ändert. Ein Firmware-Upgrade folgt dem eigenen Change- und Backup-Prozess und ist kein spontaner Troubleshooting-Schritt.

Wenn die Regel nicht zutrifft, ist nicht QUIC das Hauptproblem, sondern Regelreihenfolge, Source Zone, Source Network, Destination, Service oder Exclusion. Dafür hilft Firewall-Regel greift nicht: Ursachen prüfen.

Betriebscheckliste

• Betroffene Client-Internetregel eindeutig identifiziert.
• Web Policy, Malware Scan oder TLS Inspection in genau dieser Regel geprüft.
• Block QUIC protocol bewusst aktiviert oder begründet deaktiviert.
• DPI Mode oder Web Proxy Mode bewusst entschieden.
• Regelreihenfolge und allgemeinere Allow-Regeln geprüft.
• Log firewall traffic aktiv.
• Test mit Browser und echter Zielseite durchgeführt.
• Log Viewer auf UDP 443, TCP 443, Rule ID und Web-Events geprüft.
• Bei TLS Inspection zusätzlich SSL/TLS-inspection-Logs kontrolliert.
• Ausnahmen oder eigene UDP-Regeln dokumentiert.
• Helpdesk weiss, dass Webseiten nach QUIC-Block normalerweise weiter funktionieren sollten.

Rollback

Vor dem Pilottest werden Regelstatus, Position, Block QUIC protocol, Web Policy, Application Filter, Logging, NAT-Zuordnung und TLS-/Proxy-Modus dokumentiert. Für den Rückweg deaktiviert man eine separate Pilotregel oder stellt in der bearbeiteten Regel genau den vorherigen Haken- und Policy-Zustand wieder her. Danach werden Browser und bestehende Sessions geschlossen und mit einer neuen Verbindung die frühere Rule ID sowie das frühere UDP-/TCP-Verhalten geprüft. Erst dann entfernt man ausschliesslich nicht mehr benötigte Pilotobjekte; gemeinsam verwendete Services, Filter oder NAT-Regeln werden nicht gelöscht.

Häufige Fragen