Sophos Firewall TLS Inspection richtig einführen

Ein grosser Teil des heutigen Web-Traffics ist verschlüsselt. Ohne TLS Inspection sieht die Firewall oft nur Ziel-IP, SNI, Zertifikatsinformationen und Metadaten, aber nicht den eigentlichen Inhalt der Verbindung.

Das ist ein Sicherheitsproblem: Viele Schutzfunktionen können verschlüsselten Payload nicht oder nur stark eingeschränkt prüfen. Malware-Scanning, Web Protection, Zero-Day-Analyse, Content-Scanning und Teile der Applikations- oder Bedrohungserkennung werden erst wirklich wirksam, wenn die Firewall den TLS-Traffic entschlüsseln, prüfen und danach wieder verschlüsseln kann. Auch IPS und NDR profitieren von mehr Klartext-Sichtbarkeit. Ohne Entschlüsselung bleiben viele Signale auf Metadaten, Zertifikate, IPs, Domains oder Protokollinformationen beschränkt.

TLS Inspection ist aber kein Feature, das man unvorbereitet für alle Benutzer aktivieren sollte. Es kann Anwendungen stören, Datenschutzfragen berühren und die Firewall stärker belasten. Deshalb sollte man TLS Inspection geplant, schrittweise und mit klarer Ausnahme-Strategie einführen.

Orientierung und Voraussetzungen

TLS Inspection betrifft Zertifikate, Datenschutz, Performance und Applikationskompatibilität. Deshalb sollte man zuerst klären, welche Schutzfunktionen genutzt werden sollen, welche Regelart aktiv ist und welcher Traffic überhaupt entschlüsselt werden darf.

Lizenz und Voraussetzungen

Für TLS Inspection und die sinnvolle Auswertung des entschlüsselten Traffics benötigt man die passenden Schutzlizenzen.

Wichtig sind vor allem:

• Web Protection: Enthält Web Security, Web Control, Application Control und Web Malware Protection.
• Network Protection: Enthält unter anderem IPS, Security Heartbeat und weitere Netzwerk-Schutzfunktionen.
• Zero-Day Protection: Wird wichtig, wenn Dateien oder Downloads zusätzlich per Machine Learning oder Sandbox analysiert werden sollen.

Web Protection ist im Lizenzbundle Standard Protection enthalten. Xstream Protection und Epic Protection enthalten ebenfalls Web Protection und weitere Schutzmodule. Für die Einordnung der Bundles passt Welche Sophos Firewall Bundles gibt es?; für Base License, Supportstatus und Subscriptions passt Sophos Firewall Base License verstehen.

Vor dem Rollout sollte man prüfen:

• Aktuelle Sophos Firewall Firmware ist installiert.
• Web Protection ist lizenziert.
• CA-Zertifikat der Firewall ist auf den Clients verteilt.
• Testgruppe oder Testnetz ist definiert.
• Rollback ist dokumentiert.
• Ausnahmeprozess ist geklärt.
• Logging ist aktiviert.

Wenn das CA-Zertifikat noch nicht verteilt ist, hilft der Artikel Sophos Firewall CA Zertifikat für HTTPS Scanning installieren.

⚠️ TLS Inspection kann Anwendungen stören, die Certificate Pinning verwenden oder eigene Zertifikatsprüfungen durchführen. Der Rollout sollte immer mit einer Testgruppe beginnen und nicht direkt mit allen Benutzern.

DPI oder Web Proxy?

Die Sophos Firewall kann HTTPS-Decryption in zwei Betriebsarten umsetzen:

• DPI Mode: Die Firewall-Regel verwendet den DPI Engine. SSL/TLS Inspection Rules unter Rules and policies > SSL/TLS inspection rules entscheiden, was entschlüsselt wird.
• Web Proxy Mode: Die Firewall-Regel verwendet den Web Proxy. HTTPS-Decryption wird dann über die Web-Proxy-Einstellungen und Web Policies gesteuert.

Für moderne Setups wird häufig DPI Mode verwendet. Wichtig ist dabei die Firewall-Regel:

1. Rules and policies > Firewall rules öffnen.
2. Die betroffene LAN-to-WAN-Regel bearbeiten.
3. Security features > Web filtering öffnen.
4. Die passende Web Policy aktivieren.
5. Scan HTTP and decrypted HTTPS aktivieren.
6. Use web proxy instead of DPI engine deaktiviert lassen, wenn die SSL/TLS Inspection Rules greifen sollen.

Wenn Use web proxy instead of DPI engine aktiviert ist, läuft Web-Traffic über den Web Proxy. Dann gelten für HTTP/HTTPS andere Decryption-Einstellungen als bei DPI-basierten SSL/TLS Inspection Rules. Vor dem Rollout sollte deshalb klar sein, ob die Umgebung Web Proxy oder DPI nutzt, sonst sucht man Ausnahmen später an der falschen Stelle.

Welchen Traffic sollte man entschlüsseln?

Man sollte nicht blind alles entschlüsseln. Gute TLS Inspection beginnt mit klaren Zielen.

Sinnvolle erste Ziele:

• LAN > WAN: klassischer Benutzer-Web-Traffic ins Internet.
• Wi-Fi > WAN: verwaltete Clients im Firmen-WLAN.
• VPN > WAN: Remote-Access-Benutzer, wenn deren Internet-Traffic über die Firewall läuft.
• LAN > DMZ: interne Zugriffe auf eigene Server, wenn dort Sicherheitsprüfung gewünscht ist und Zertifikate sauber verteilt sind.

Mit Vorsicht behandeln:

• Banking, Gesundheit, Behörden und hochsensible Portale.
• Passwortmanager und Identity-Provider.
• Betriebssystem- und Hersteller-Update-Dienste.
• Mobile Apps und Android-Geräte.
• Anwendungen mit Certificate Pinning.
• Voice-, Video- und Collaboration-Dienste, wenn sie durch Decryption instabil werden.

Für Server-Veröffentlichungen aus dem Internet in die DMZ ist TLS Inspection nicht automatisch die beste Lösung. Bei Webservern ist häufig Web Server Protection / WAF oder ein Reverse Proxy sinnvoller.

QUIC und Web Policy mitdenken

Wenn Web-Traffic trotz TLS Inspection nicht wie erwartet geprüft wird, sollte man auch QUIC beziehungsweise HTTP/3 prüfen. Viele Browser können HTTPS-Verbindungen über UDP 443 aufbauen. Je nach Regel- und Web-Policy-Design läuft der Traffic dann nicht im erwarteten klassischen HTTPS-Pfad über TCP 443.

In Client-Internetregeln sollte deshalb bewusst geprüft werden:

• Ist die passende Web Policy aktiv?
• Ist Block QUIC protocol in der tatsächlich matchenden Firewall-Regel aktiv?
• Ist Scan HTTP and decrypted HTTPS passend zur Decryption-Strategie gesetzt?
• Nutzt die Regel DPI oder Web Proxy?
• Sieht man im Log Viewer UDP 443, TCP 443, Web-Policy-Events und SSL/TLS-Inspection-Events konsistent?

Der Ablauf zum QUIC-Block steht in Sophos Firewall QUIC und HTTP/3 richtig blockieren. Für die Web-Policy selbst passt Sophos Firewall Web Protection Policy erstellen.

Rollout planen

Ein sauberer Rollout beginnt klein, hat klare Owner und trennt temporäre Ausnahmen von dauerhaften Sicherheitsentscheidungen.

Rollout-Strategie

Bewährt hat sich ein stufenweiser Ansatz:

1. CA-Zertifikat verteilen.
2. Web Policy und Firewall-Regel vorbereiten.
3. Decryption Profile auswählen.
4. Kleine Testgruppe definieren.
5. SSL/TLS Inspection Rule nur für diese Gruppe aktivieren.
6. Control Center und Log Viewer beobachten.
7. Fehler analysieren und Ausnahmen sauber dokumentieren.
8. Schrittweise auf weitere Benutzergruppen erweitern.

So erkennt man früh, welche Anwendungen Probleme machen, ohne den gesamten Betrieb zu beeinflussen.

Rollout-Phasen planen

Ein TLS-Inspection-Rollout sollte in Phasen geplant werden. Dadurch bleibt er kontrollierbar und man kann technische Fehler von Akzeptanz- oder Applikationsproblemen trennen.

Die Phasen sollten klar voneinander getrennt werden:

• Vorbereitung: CA, Web Policy, Firewall-Regel und Testgruppe sind bereit. Geprüft werden CA-Verteilung, Lizenz, Logging und Rollback.
• Pilot: Wenige verwaltete Clients testen den produktiven Alltag. Wichtig sind Log Viewer, Dashboard Widget und Benutzerfeedback.
• Erweiterung: Weitere Benutzergruppen oder Netze werden einbezogen. Ausnahmen werden dokumentiert und Performance wird beobachtet.
• Betrieb: TLS Inspection wird regelmässig geprüft. Dazu gehören Review von Exclusions, Reports, Fehlern und neuen Anwendungen.

Wichtig ist, dass jede Phase einen klaren Abbruchpunkt hat. Wenn eine geschäftskritische Anwendung im Pilot bricht, sollte nicht sofort eine breite globale Ausnahme gesetzt werden. Besser ist eine saubere Analyse: Welche Domain, welcher Client, welche Regel, welches Decryption Profile und welcher Fehler im Log Viewer sind betroffen?

Pilot, Owner und Ausnahmeprozess festlegen

Vor dem ersten produktiven Rollout sollte klar sein, wer die Testgruppe betreut, wer Ausnahmen freigibt und wie Fehler zurückgemeldet werden. TLS Inspection erzeugt sonst schnell ungeordnete Ausnahmen: einzelne Domains werden hektisch auf Don't decrypt gesetzt, ohne dass später noch klar ist, warum die Ausnahme existiert.

Für den Betrieb sollten diese Punkte dokumentiert sein:

• Pilotgruppe, betroffene Netze und Zeitraum.
• Owner für Web Policy, Decryption Profile und SSL/TLS Inspection Rules.
• Prozess für neue Ausnahmen mit Grund, Ticket und Review-Datum.
• Kriterien, wann eine Anwendung ausgenommen wird und wann zuerst die Ursache geprüft wird.
• Stelle, an der Log Viewer, Dashboard Widget und Benutzerfeedback gesammelt werden.
• Rollback, falls geschäftskritische Anwendungen gestört werden.

Besonders wichtig ist die Trennung zwischen technischer Ausnahme und dauerhaftem Sicherheitsentscheid. Eine temporäre Ausnahme kann sinnvoll sein, damit ein Dienst wieder funktioniert. Diese Ausnahme sollte aber später erneut bewertet werden, sobald Ursache, Risiko und Alternative klar sind.

Rollback vor dem Rollout testen

Ein Rollback sollte nicht erst im Störungsfall erfunden werden. Vor dem Pilot sollte klar sein, wie man TLS Inspection für die Testgruppe zurücknimmt, ohne andere Regeln, Web Policies oder Ausnahmen durcheinanderzubringen.

Praktische Rollback-Prüfung:

• Testgruppe entfernen: Prüfen, ob die SSL/TLS Inspection Rule danach nicht mehr für den Pilotclient matcht.
• Rule deaktivieren: Kontrollieren, ob der Traffic wieder über den erwarteten Nicht-Decryption-Pfad läuft.
• Ausnahme testen: Eine gezielte Don't decrypt-Regel muss oberhalb der allgemeinen Decrypt-Regel stehen und im Log Viewer sichtbar greifen.
• Web Policy erhalten: Rollback der Entschlüsselung darf nicht versehentlich Webfiltering, Malware-Scanning oder Logging komplett entfernen.
• Nachweis dokumentieren: Testclient, Ziel-Domain, Regelname, Log-Event und Zeitpunkt festhalten.

Diese Probe ist besonders wichtig, wenn mehrere Admins an Web Policies, Firewall-Regeln und SSL/TLS Inspection Rules arbeiten. Ein sauberer Rollback nimmt nur den betroffenen Scope zurück und macht nicht die ganze Web-Protection-Kette blind.

Konfiguration

Die technische Umsetzung besteht aus Decryption Profile, SSL/TLS Inspection Rule und Ausnahmen. Entscheidend ist die Reihenfolge der Regeln und die Frage, ob DPI oder Web Proxy verwendet wird.

Decryption Profiles verstehen

Ein Decryption Profile legt fest, wie streng die Firewall mit TLS-Verbindungen umgeht. Die Profile findet man unter Profiles > Decryption profiles.

Ein Decryption Profile beantwortet unter anderem diese Fragen:

• Was passiert bei ungültigen oder nicht vertrauenswürdigen Zertifikaten?
• Werden alte TLS-Versionen blockiert?
• Werden unsichere Cipher Suites blockiert?
• Was passiert bei SSL-Kompression?
• Was passiert bei unrecognized cipher suites?
• Was passiert, wenn die Firewall eine Verbindung nicht entschlüsseln kann?
• Welche CA wird für die erneute Signierung verwendet?

Für einen ersten Rollout ist ein kompatibleres Profil sinnvoll, zum Beispiel Maximum compatibility oder ein eigenes konservatives Profil. Für produktive Sicherheitsregeln kann später ein strengeres Profil wie Block insecure SSL verwendet werden.

Wichtig: Das Decryption Profile wird direkt in der SSL/TLS Inspection Rule ausgewählt. Das Profil kann die globalen SSL/TLS-Inspection-Settings für diese Regel übersteuern. Deshalb sollte man bei Troubleshooting immer die konkrete Regel und nicht nur die globalen Einstellungen prüfen.

SSL/TLS Inspection Rule erstellen

Der Menüpfad lautet Rules and policies > SSL/TLS inspection rules.

Eine erste Regel sollte möglichst gezielt sein:

• Action: Decrypt
• Decryption profile: konservatives Testprofil
• Source zones: LAN oder Testnetz
• Source networks and devices: Testgruppe oder Testsubnetz
• Destination zones: meistens WAN
• Destination networks: zunächst Any
• Services: für den Start häufig Any, weil SSL/TLS auch auf anderen TCP-Ports erkannt werden kann
• Websites / Categories: optional einschränken

SSL/TLS Inspection Rules können TLS-Verbindungen auch ausserhalb des klassischen HTTPS-Ports erkennen. Die Regeln werden von oben nach unten verarbeitet. Spezifische Ausnahmen und Pilotregeln gehören deshalb oberhalb allgemeiner Decrypt-Regeln, sonst wird später schwer nachvollziehbar, warum eine Verbindung entschlüsselt oder ausgenommen wurde.

Exclusion Lists

Nicht jeder TLS-Traffic sollte entschlüsselt werden. Sophos arbeitet dafür mit Exclusion Rules und TLS Exclusion Lists.

Local TLS Exclusion List

Die Local TLS exclusion list ist die lokale Ausnahmeliste der Firewall. Diese Liste ist standardmässig leer und kann durch Troubleshooting im Control Center oder Log Viewer gefüllt werden.

Man kann sie auch manuell bearbeiten:

Web > URL groups > Local TLS exclusion list

Diese Liste ist sinnvoll für Domains, die in der eigenen Umgebung Probleme machen, zum Beispiel wegen Certificate Pinning oder speziellen Client-Anwendungen.

Managed TLS Exclusion List

Die Managed TLS exclusion list enthält von Sophos gepflegte Ausnahmen für bekannte problematische Dienste. Diese Liste wird durch Firmware-Updates aktualisiert.

Typische Beispiele sind Dienste, bei denen TLS Inspection erfahrungsgemäss Probleme verursacht oder technisch nicht sinnvoll ist.

Eigene Exclusion Rules

Zusätzlich kann man eigene SSL/TLS Inspection Rules mit Action > Don’t decrypt erstellen. Diese sollten direkt unter der standardmässigen Exclusion-Regel stehen und nur Traffic enthalten, der wirklich nicht entschlüsselt werden soll.

Mögliche Kriterien:

• Web-Kategorien
• URL Groups
• Benutzer und Gruppen
• Source- und Destination-Netze
• IP-Adressen
• Services

Ausnahmen sollten dokumentiert werden: Domain, Grund, betroffene Benutzer, Datum und Review-Termin.

Kontrolle und Auswertung

Nach der Aktivierung sollte man Dashboard, Log Viewer und Testclients gemeinsam betrachten. Nur so erkennt man, ob Traffic wirklich entschlüsselt wird oder ob Ausnahmen, Fehler oder QUIC den erwarteten Pfad verändern.

Dashboard Widget beobachten

Im Control Center gibt es ein Widget für SSL/TLS Inspection. Dieses Widget ist sehr hilfreich, um Rollout und Fehler zu überwachen.

Es zeigt unter anderem:

• Anteil entschlüsselter SSL/TLS-Sessions.
• Anteil nicht entschlüsselter SSL/TLS-Sessions.
• Sonstiger Traffic.
• Fehler der letzten Tage.
• Top-Websites oder Top-User mit Problemen.
• Decryption peak und Decryption limit.

Wenn im Widget viele Fehler auftauchen, sollte man nicht sofort die gesamte TLS Inspection deaktivieren. Besser ist es, über Fix errors gezielt die betroffenen Ziele zu prüfen und bei Bedarf saubere Ausnahmen zu erstellen.

Log Viewer auswerten

Im Log Viewer kann man den Filter SSL/TLS inspection auswählen. Dort sieht man, was mit einzelnen Verbindungen passiert ist.

Die Farben helfen bei der ersten Einordnung:

• Rot: Fehler. Die Verbindung konnte nicht korrekt entschlüsselt oder verarbeitet werden. Hier sollte man Zertifikatsfehler, Cipher Suites, TLS-Versionen oder inkompatible Anwendungen prüfen.
• Grün: Do not decrypt. Die Verbindung wurde bewusst nicht entschlüsselt, zum Beispiel wegen einer Exclusion Rule oder einer TLS Exclusion List.
• Blau: Decrypt. Die Verbindung wurde entschlüsselt und danach wieder verschlüsselt weitergeleitet.

Im Log sieht man ausserdem Decryption Profile, Quell-IP, Ziel-IP, Benutzer, Kategorie und Ziel-Domain. Damit lässt sich prüfen, ob die richtige Rule matched und ob eine Ausnahme wirklich greift.

Tests

Nach Aktivierung der TLS Inspection sollte man prüfen:

• Wird das Sophos CA-Zertifikat im Browser verwendet?
• Funktionieren wichtige Business-Anwendungen?
• Gibt es TLS-Fehler im Log Viewer?
• Werden Malware- oder Web-Policy-Events korrekt erkannt?
• Wird der Traffic im Control-Center-Widget als decrypted angezeigt?
• Bleibt die Firewall-Performance im erwarteten Bereich?
• Gibt es Beschwerden von Testbenutzern?

Für die Fehlersuche sind besonders Log Viewer, Policy Test, Browser-Zertifikatsansicht, Packet Capture und das SSL/TLS-Inspection-Widget hilfreich.

Troubleshooting und Betrieb

Bei Problemen sollte man den Scope klein halten: ein Client, eine Domain, eine Regel, ein Decryption Profile und ein klarer Zeitpunkt im Log Viewer.

Typische Fehler

Typische Symptome:

• Browser zeigt Zertifikatswarnung: Meist fehlt die CA im Trust Store oder es wird die falsche CA verwendet. CA-Verteilung, Zertifikatskette im Browser und Client-Neustart prüfen.
• Log Viewer zeigt keine SSL/TLS-Inspection-Events: Häufig ist der Modus falsch, es gibt keine passende Rule oder die SSL/TLS Engine ist nicht aktiv. Firewall-Regel, DPI/Web Proxy und SSL/TLS Inspection Rule prüfen.
• Traffic wird erlaubt, aber nicht entschlüsselt: Möglich sind Don't decrypt Rule, Managed Exclusion oder falsche Rule-Reihenfolge. SSL/TLS Inspection Rules von oben nach unten prüfen.
• Webfilter greift nicht wie erwartet: Web Policy fehlt, QUIC ist aktiv oder Scan HTTP and decrypted HTTPS wird falsch verstanden. Matchende Firewall-Regel, QUIC und Web-Policy-Log prüfen.
• Einzelne Anwendungen brechen ab: Certificate Pinning, alte TLS-Version, inkompatible Cipher Suite oder eigene Zertifikatsprüfung können die Ursache sein. Log Viewer, Decryption Profile und gezielte Ausnahme prüfen.
• Viele Fehler im Dashboard Widget: Der Rollout ist oft zu breit oder das Decryption Profile ungeeignet. Pilotgruppe verkleinern und Fehler nach Domain und Kategorie sortieren.
• Performance fällt nach Aktivierung ab: Scope, grosse Downloads oder zu viele gleichzeitige Sessions prüfen. Zusätzlich Firewall-Auslastung und Top-User betrachten.
• Ausnahme funktioniert nicht: Die Ausnahme steht möglicherweise unterhalb einer allgemeineren Decrypt-Regel. Rule-Reihenfolge und matchende Kriterien prüfen.

Bei unklaren Fällen sollte man nicht mehrere Dinge gleichzeitig ändern. Besser ist ein enger Testfall: ein Client, eine Ziel-Domain, eine Firewall-Regel, ein Decryption Profile und ein klarer Zeitpunkt im Log Viewer.

Rollback

Falls es zu Störungen kommt, sollte ein klarer Rollback möglich sein:

• SSL/TLS Inspection Rule deaktivieren.
• Testgruppe aus der Regel entfernen.
• Decryption Profile entschärfen.
• Ausnahme für betroffene Domain oder Anwendung ergänzen.
• Firewall-Regel wieder auf Web Proxy umstellen, wenn das bewusst gewünscht ist.

SSL/TLS Inspection Rules und der SSL/TLS Engine müssen sichtbar aktiv sein, damit Control Center und Log Viewer die Details anzeigen. Wenn man SSL/TLS Inspection zu Troubleshooting-Zwecken deaktiviert, sollte man sie danach wieder aktivieren und den Zustand kurz dokumentieren.

Betriebsempfehlung

TLS Inspection ist kein Ein-Klick-Projekt. Richtig eingeführt liefert sie aber erheblich mehr Sichtbarkeit und verbessert die Wirkung von Web Protection, Malware Scanning, IPS, NDR und Zero-Day-Funktionen.

Für produktive Umgebungen empfehlen wir:

• Zuerst LAN-to-WAN für eine kleine Testgruppe.
• CA-Zertifikat sauber verteilen.
• DPI/Web-Proxy-Modus bewusst wählen.
• Decryption Profile nicht zu aggressiv starten.
• Log Viewer und Dashboard täglich beobachten.
• Ausnahmen dokumentieren und regelmässig prüfen.
• Rollback für Pilotgruppe und Ausnahmen getestet halten.
• Erst nach erfolgreichen Tests weiter ausrollen.

FAQ