Sophos Firewall TLS Inspection richtig einführen

Bei der TLS Inspection beendet die Sophos Firewall die verschlüsselte Verbindung des Clients und baut eine zweite zum Zielserver auf. Dazwischen kann sie den Klartext prüfen. Das vom Client sichtbare Serverzertifikat signiert sie mit einer eigenen CA (Certificate Authority) neu. Vertraut der Client dieser CA nicht, erscheint eine Zertifikatswarnung oder die Verbindung bricht ab.

Damit werden Prüfungen des entschlüsselten Inhalts möglich, etwa Malware- und Content-Scanning. Ohne Entschlüsselung bleiben Schutzfunktionen je nach Modul auf Informationen wie IP-Adresse, Domain, SNI, Zertifikat oder Protokollmetadaten beschränkt. Das rechtfertigt aber keinen breiten Start: Certificate Pinning, Datenschutz, Applikationskompatibilität und die zusätzliche Last auf der Firewall müssen vor dem Rollout geklärt sein.

Der sichere Kurzablauf lautet: DPI- oder Web-Proxy-Pfad bestimmen, Re-Signing-CA an eine kleine Gruppe verteilen, den bisherigen Zustand dokumentieren, eine eng begrenzte Decrypt-Regel erstellen, einen positiven und einen negativen Test ausführen und erst danach erweitern.

Vor dem Pilotprojekt entscheiden

Lizenz, CA und Verantwortlichkeit

SSL/TLS Inspection Rules sowie darin verwendete URL Groups werden bereits mit der Base License durchgesetzt. Web Protection ist keine allgemeine Voraussetzung für TLS Inspection. Sie wird benötigt, wenn Web-Kategorien als Regelkriterium greifen oder entsprechende Web-Protection-Funktionen genutzt werden sollen. Malware-, Zero-Day- und weitere Prüfungen benötigen jeweils die dazugehörige Subscription. Die Unterschiede erklären Welche Sophos Firewall Bundles gibt es? und Sophos Firewall Base License verstehen.

Vor der ersten Regel sollten folgende Punkte geklärt sein:

• Die eingesetzte SFOS-Version, die verfügbare Lizenz und der gewünschte Prüfpfad sind dokumentiert.
• Eine verwaltete Pilotgruppe und ein klarer Zeitraum sind festgelegt. Das Beispiel unten verwendet den Client 10.20.30.50 aus dem Testnetz 10.20.30.0/24; diese Werte müssen durch eigene Objekte ersetzt werden.
• Datenschutzverantwortliche haben Scope, Protokollierung, Aufbewahrung und Information der Benutzer freigegeben.
• Der genaue Vorzustand von Firewall-Regel, TLS-Regeln, Decryption Profile, CA und allfälligen globalen Einstellungen ist gesichert.
• Owner, Abbruchkriterien, Ausnahmeprozess und Rückweg sind benannt.

Die Re-Signing-CA muss im Trust Store der betroffenen Betriebssysteme oder Browser liegen. Alternativ lässt sich eine untergeordnete Unternehmens-CA verwenden. Eine öffentlich vertrauenswürdige CA ist dafür nicht erhältlich, weil die Firewall Zertifikate für fremde Domains neu signiert. Bei einer externen CA müssen Root- und Subordinate-CA importiert sein; enthält die Signing-CA eine EKU-Sektion, muss sie TLS Web Server Authentication erlauben. Die Verteilung beschreibt Sophos Firewall CA Zertifikat für HTTPS Scanning installieren, den Enterprise-CA-Weg Untergeordnete CA für Sophos Firewall TLS Inspection einrichten.

⚠️ Beginne nicht mit allen Benutzern. Geräte ohne verwaltbaren Trust Store, BYOD und Anwendungen mit Certificate Pinning gehören zunächst in einen separaten Scope. Eine Ausnahme stellt die Verbindung zwar wieder her, nimmt ihren Inhalt aber aus der Entschlüsselung.

DPI und Web Proxy unterscheiden

SFOS verwendet standardmässig die DPI engine. In diesem Pfad verarbeitet die Firewall zuerst die Firewall Rule und danach die SSL/TLS Inspection Rules. Die Inspection Rule erlaubt selbst keinen Traffic: Auch Services: Any bedeutet nur, dass bereits von der Firewall Rule erlaubter TLS-Traffic auf jedem TCP-Port für diese Inspection Rule infrage kommt.

Für den DPI-Pfad öffnet man Rules and policies > Firewall rules, bearbeitet die betroffene LAN-to-WAN-Regel und prüft unter Security features > Web filtering:

1. Use web proxy instead of DPI engine bleibt deaktiviert.
2. Eine Web Policy wird nur gewählt, wenn sie für den geplanten Schutz benötigt wird; sie ist keine Voraussetzung für die Decryption Rule.
3. Scan HTTP and decrypted HTTPS aktiviert Malware-Scanning für HTTP und bereits entschlüsseltes HTTPS. Die Option schaltet die HTTPS-Entschlüsselung nicht selbst ein.

Im Web Proxy Mode übernimmt der Proxy die HTTPS-Entschlüsselung. Dafür ist Decrypt HTTPS during web proxy filtering im Proxy-Pfad massgebend. Die DPI-Regeln unter Rules and policies > SSL/TLS inspection rules wirken nicht auf Verbindungen, die der Web Proxy entschlüsselt. Beim transparenten Proxy laufen Port 80 und 443 über den Proxy, während SSL/TLS auf anderen Ports weiterhin vom DPI-Pfad erfasst werden kann; beim Explicit Proxy entschlüsselt der Web Proxy.

Auch die CAs sind getrennt: DPI verwendet die CA aus den SSL/TLS settings beziehungsweise dem gewählten Decryption Profile. Der Web Proxy verwendet die CA aus Web > General settings. Wer den Modus wechselt, muss deshalb nicht nur Regeln, sondern auch die tatsächlich präsentierte CA prüfen. DPI Engine oder Web Proxy richtig wählen führt die Unterschiede weiter aus.

Für veröffentlichte Webserver aus dem Internet ist dieser ausgehende Inspection-Pfad nicht gedacht. Dort sind Web Server Protection / WAF oder ein Reverse Proxy meist die passendere Architektur. SSL/TLS Inspection Rules gelten für ausgehenden Traffic; als Source zones sind deshalb nur interne Zonen auswählbar. Sie erkennen TLS auf jedem TCP-Port, werden aber nicht über UDP erzwungen.

QUIC in den Prüfpfad einbeziehen

QUIC beziehungsweise HTTP/3 verwendet UDP. Block QUIC protocol in einer Firewall Rule verwirft in deren Scope ausgehende UDP-Pakete zu Port 80 und 443, damit Clients auf einen prüfbaren TCP-Pfad zurückfallen. SFOS wählt die Option standardmässig aus, sobald in der Regel eine Web Policy gewählt oder Scan HTTP and decrypted HTTPS aktiviert wird. Das ist regelbezogen, nicht global; kontrolliert wird daher die tatsächlich matchende Firewall Rule.

QUIC kann von diesem Webfilter nicht gescannt werden. Daraus folgt nicht, dass jede andere Firewall-Kontrolle umgangen wird, wohl aber, dass der erwartete TCP-TLS- und Webfilterpfad nicht greift. Den Regeltest zeigt Sophos Firewall QUIC und HTTP/3 richtig blockieren; die Web Policy wird in Sophos Firewall Web Protection Policy erstellen aufgebaut.

Scope nach Aufgabe und Risiko auswählen

Der übliche Einstieg ist verwalteter Benutzerverkehr von LAN nach WAN. Ein separates Firmen-WLAN kann als Wi-Fi > WAN folgen. Bei Remote Access kommt VPN > WAN nur infrage, wenn der Internetverkehr der Benutzer tatsächlich als Full Tunnel durch die Firewall läuft. Interne Verbindungen von LAN in eine DMZ werden nur einbezogen, wenn die Inhaltsprüfung dort einen klaren Nutzen hat und beide Seiten der Re-Signing-CA vertrauen.

Technische Kompatibilität und die zulässige Entschlüsselung sind getrennte Entscheide. Banking-, Gesundheits- und Behördenportale, Passwortmanager, Identity-Provider, Betriebssystem- und Hersteller-Updates sowie Voice-, Video- und Collaboration-Dienste brauchen vor dem Einschluss eine fachliche und datenschutzrechtliche Bewertung. Pinning oder ein Fehler im Pilotprojekt rechtfertigt keine pauschale Ausnahme für die ganze Kategorie: Zuerst werden die tatsächlich benötigte Source, Domain und Anwendung bestimmt.

Ein vollständiges Pilotprojekt konfigurieren

Für ein direkt prüfbares Pilotprojekt verwenden wir diese Beispielwerte:

• Pilotclient: 10.20.30.50 aus dem dokumentierten Testnetz 10.20.30.0/24
• Firewall Rule: LAN to WAN - TLS pilot
• SSL/TLS Inspection Rule: TLS decrypt pilot client
• Source zone: LAN, Destination zone: WAN
• Destination networks und Services: Any
• Action: Decrypt
• Decryption profile: zunächst Block insecure SSL oder ein daraus abgeleitetes Pilotprofil
• Logging: Log connections für das Pilotprojekt aktiviert

10.20.30.0/24, Host-IP und Objektnamen sind Beispiele. Die produktive Source muss so eng sein, dass ein einzelner Client sicher zugeordnet werden kann. Any bei Destination und Service erleichtert im Pilotprojekt die Beobachtung von TLS ausserhalb TCP 443; es erweitert nicht die Erlaubnis der vorgelagerten Firewall Rule. Wer nur eine Zielgruppe prüfen darf, setzt zusätzlich eine URL Group oder ein anderes passendes Zielkriterium.

Decryption Profile wählen

Unter Profiles > Decryption profiles stehen drei nicht editierbare Standardprofile bereit:

• Maximum compatibility maximiert die Kompatibilität und schränkt Cipher nicht ein.
• Block insecure SSL blockiert schwache Cipher und erlaubt Traffic, der nicht entschlüsselt werden kann.
• Strict compliance setzt strenge, unter anderem auf PCI-DSS ausgerichtete Vorgaben.

Maximum compatibility kann einen problematischen Client kurzfristig eingrenzen, ist wegen seiner gelockerten Prüfungen aber kein Produktions-Abnahmekriterium. Für das Pilotprojekt ist Block insecure SSL oder ein bewusst daraus abgeleitetes Profil der transparentere Ausgangspunkt. Alte TLS-Versionen oder RSA-Schlüssel unter 2048 Bit werden nur für einen benannten Altserver und in einer engen Regel toleriert.

Ein eigenes Profil kann die globalen SSL/TLS settings überschreiben. Für die Re-Signing-CA stehen Use CAs defined in SSL/TLS settings, Re-sign RSA with und Re-sign EC with zur Verfügung. Für nicht entschlüsselbaren Traffic gibt es Use SSL/TLS settings default, Allow without decryption, Drop und Reject. Der Verweis auf den globalen Standard gilt nicht für Unrecognized cipher suites; dieser Fall muss im Profil ausdrücklich beurteilt werden. Zertifikatsfehler, RSA-Mindestgrösse, TLS-Versionen und blockierte Cipher verwenden als Block action je nach Einstellung Drop, Reject oder Reject and notify.

Ein selbstsigniertes oder unvollständig verkettetes Serverzertifikat wird durch Inspection nicht vertrauenswürdig. Statt es vorschnell auszunehmen, prüft man zuerst Hostname, Originalzertifikat und vollständige Chain.

Bei TLS 1.3 greifen Zertifikatsfehler, Mindest-RSA-Grösse, ein globales Downgrade und Reject and notify in der dokumentierten Weise nur mit Action: Decrypt. Bei Don’t decrypt oder Deny wird für diese Profilbehandlung stattdessen Reject angewendet. Ein globales Downgrade auf TLS 1.2 bringt ein Sicherheitsrisiko mit und ist kein allgemeiner Kompatibilitätsfix.

Regel anlegen und Reihenfolge prüfen

Unter Rules and policies > SSL/TLS inspection rules > Add werden die Felder so gesetzt:

1. Rule name: TLS decrypt pilot client
2. Rule position: Top, damit die Pilotregel vor allgemeinen selbst erstellten Decrypt-Regeln liegt
3. Action: Decrypt
4. Log connections: aktiv für die Pilotbeobachtung
5. Decryption profile: das gewählte Pilotprofil
6. Source zones: LAN
7. Source networks and devices: Hostobjekt für 10.20.30.50
8. Destination zones: WAN
9. Destination networks: Any
10. Services: Any
11. Categories and websites: leer oder auf den genehmigten Ziel-Scope begrenzt

Log connections ist optional und nicht nötig, damit die Regel arbeitet. Für ein zeitlich begrenztes Pilotprojekt ist es dennoch sinnvoll, weil Handshake und Verbindungsende nachvollziehbar werden. Die Aufbewahrung richtet sich nach dem vereinbarten Datenschutz- und Betriebskonzept.

Die Tabelle wird von oben nach unten ausgewertet; beim ersten Treffer endet die Suche. Alle gesetzten Kriterien müssen gleichzeitig passen. Die feste Standardregel Exclusions by website or category steht dauerhaft ganz oben und lässt sich nicht durch Rule position: Top überholen. Eigene Don't decrypt-Ausnahmen gehören unmittelbar darunter, danach spezifische Pilotregeln und zuletzt breitere Decrypt-Regeln.

Benutzer- und Gruppenkriterien sind nur zuverlässig, wenn SFOS den Benutzerkontext für die Verbindung kennt. Ist das nicht garantiert, beginnt man mit einem eindeutigen Host- oder Netzobjekt und ergänzt Identitätskriterien erst nach einem separaten Match-Test.

Ausnahmen eng halten

Die Standardregel Exclusions by website or category verwendet Don’t decrypt mit Maximum compatibility und bleibt an erster Position. Die Local TLS exclusion list ist standardmässig leer; die Managed TLS exclusion list enthält bekannte inkompatible Sites und wird mit Firmware-Updates gepflegt.

Die lokale Liste lässt sich unter folgendem Pfad bearbeiten:

Web > URL groups > Local TLS exclusion list

URL Groups beziehungsweise SNI-Matches sind für Domain-Ausnahmen effizienter als viele FQDN Hosts. Laut Sophos verursachen beispielsweise 200 FQDN Hosts bei jeder neuen SSL/TLS-Verbindung 200 Lookups. Source- und Destination-Exceptions können zudem nicht miteinander kombiniert werden. Domain-Scope, Wildcards und Negativtests erklärt URL Groups erstellen und sicher verwenden.

Eine eigene SSL/TLS Inspection Rule mit Action: Don’t decrypt sollte Domain, betroffene Source, Grund, Ticket, Owner und Review-Datum enthalten. Don’t decrypt ist kein bedingungsloser Bypass: Die Einschränkungen des ausgewählten Decryption Profile gelten weiter. Sollen SSL 2/3, Compression oder unbekannte Cipher für einen ausdrücklich genehmigten Altfall passieren, braucht es ein Profil mit Allow without decryption zusammen mit Action: Don’t decrypt. Diese Kombination gehört nicht in eine breite Internetregel.

SSL/TLS Exclusions und Web Exceptions lösen verschiedene Aufgaben. Die TLS-Ausnahme entscheidet im DPI Mode über Decryption auf beliebigen TCP-Ports. Eine Web Exception verändert ausgewählte Web-Policy-Prüfungen; im Proxy Mode betrifft sie den entsprechenden Proxy-Pfad. Ob Decryption oder nur eine Web-Prüfung ausgenommen werden soll, muss daher vor der Änderung feststehen. Web Exceptions sicher erstellen und prüfen zeigt den Auswahl- und Regex-Pfad.

Android mit engem Scope unterstützen

Einige Android-Verbindungen verwenden Certificate Pinning. Dann können Connectivity Check, Play Store oder Updates bei Decryption ausfallen. Der von Sophos dokumentierte Workflow verwendet ein isoliertes VLAN oder WLAN und eine FQDN Host Group mit:

• *.play.googlezip.net
• *.gvt1.com
• *.app-measurement.com
• der lokalen Google-Domain, in der Schweiz beispielsweise *.google.ch

Darüber liegt eine SSL/TLS Inspection Rule mit Action: Don’t decrypt, Decryption profile: Maximum compatibility, Source zone: Wi-Fi, dem Mobilgeräte-Netz als Source networks and devices, WAN als Destination zone und der Google-Gruppe als Destination networks. Sie steht unter der festen Standard-Exclusion, aber vor der allgemeinen Decrypt-Regel. Das Mobilnetz bleibt von sensiblen internen Ressourcen getrennt.

Abgenommen wird mit einem Android-Pilotgerät: Connectivity Check, Browser, Play-Store-Download und Update werden ausgeführt. Im Log viewer dürfen nur die erwarteten Google-Ziele die Ausnahme treffen; ein anderes HTTPS-Ziel aus demselben VLAN muss weiterhin die vorgesehene Decrypt-Regel verwenden. Dieser Negativtest verhindert, dass eine funktionierende, aber zu breite Ausnahme akzeptiert wird. Weitere Methoden und SNI-Grenzen behandelt Web Exceptions und TLS-Ausnahmen sicher erstellen.

Wirkung nachweisen

Eine Policy-Simulation, ein echter Client und die Logs beantworten unterschiedliche Fragen. Für eine belastbare Abnahme werden sie kombiniert.

Unter Diagnostics > Tools > Pop-out tools > Policy tester wählt man Firewall, SSL/TLS, and web und setzt Source-IP, Destination beziehungsweise URL, Protokoll und bei Bedarf den Port. Ohne Protokoll testet das Tool HTTP mit dem protokollspezifischen Standardport. Der Policy tester simuliert transparenten Webtraffic; SD-WAN-Routen bildet er nicht ab, und Regeln mit MAC-Adressen unter Source networks and devices matchen dort nicht. Web policy only prüft nur die Web Policy. Das Ergebnis ist deshalb eine Vorhersage, kein Nachweis des realen Datenpfads.

Am Client folgen vier gezielte Tests:

1. Vor der Änderung werden Ziel-Domain, Zertifikatsaussteller, Antwortzeit und funktionierende Business-Anwendung notiert.
2. Ein genehmigtes positives Ziel wird geöffnet. Der Browser muss die für DPI gewählte Re-Signing-CA als Aussteller zeigen, und der Log viewer muss die erwartete Decrypt Rule samt Decryption Profile treffen.
3. Ein bewusst ausgenommenes Ziel wird geöffnet. Es muss die erwartete Don't decrypt-Regel treffen; der Browser darf dort nicht das von der Firewall neu signierte Zertifikat sehen.
4. Ein zweites, nicht ausgenommenes Ziel aus demselben Client-Scope muss weiterhin entschlüsselt werden. Das ist der Negativtest für die Ausnahme.

Wenn eine Web Policy Teil des Designs ist, wird zusätzlich eine eigens dafür freigegebene Testkategorie oder Test-URL blockiert. Ein Malware-Test wird nur mit einem dokumentierten, ungefährlichen Hersteller-Testobjekt und einem vorher festgelegten Erwartungswert durchgeführt; dieser Artikel behauptet keinen Labortest. Vor und nach dem Pilotprojekt werden ausserdem CPU-/Speicherlast, Antwortzeit und Benutzerfehler im gleichen Zeitfenster verglichen.

Control Center und Log viewer lesen

Das Control-Center-Widget heisst SSL/TLS connections. Seine Details werden alle fünf Minuten aktualisiert. Sessions beziehen sich auf die letzten 24 Stunden, Fehler auf die letzten 7 Tage; Failed wird um Mitternacht zurückgesetzt. Die Detaildaten enthalten keine Web-Proxy-Verbindungen. Decryption peak erscheint nur nahe oder über dem Peak, Decryption limit nur nahe am geräteabhängigen Limit. Es gibt daher keinen universellen Grenzwert für alle Appliances.

Den Log viewer öffnet man oben rechts und wählt das Modul SSL/TLS inspection. Eine TLS-Verbindung wird nach abgeschlossenem Handshake und beim Schliessen protokolliert. Entscheidend sind Action, Rule, Decryption Profile, Source, Destination, Domain und Fehlergrund; Farben allein sind kein belastbares Abnahmekriterium. Unter Manage > Exclude kann man Domains oder Subdomains zur Local TLS exclusion list und Kategorien zur Standard-Exclusion hinzufügen. Bei Error IDs 19004 und 19005 steht Exclude nicht zur Verfügung.

Ein Don't decrypt-Event beweist nur, dass nicht entschlüsselt wurde. Erst die getroffene Regel, der Listenabgleich und der Negativtest zeigen, ob die Ausnahme fachlich korrekt und eng genug ist.

Fehler eingrenzen und Änderungen zurückrollen

Bei einer Störung bleibt der Fall zunächst auf einen Client, eine Domain, einen Zeitpunkt, eine Firewall Rule und eine SSL/TLS Inspection Rule begrenzt.

• Zeigt der Browser eine Zertifikatswarnung, vergleicht man den sichtbaren Aussteller mit der CA des tatsächlich verwendeten DPI- oder Proxy-Pfads. Danach werden Client-Truststore, Root-/Subordinate-Chain und Hostname geprüft.
• Fehlen SSL/TLS-Events, kontrolliert man zuerst den Treffer der Firewall Rule und den Modus. Danach müssen Rules and policies > SSL/TLS inspection rules sowie Advanced settings > SSL/TLS engine > Enabled aktiv sein.
• Wird Traffic erlaubt, aber nicht entschlüsselt, sucht man von oben nach unten nach der festen Standard-Exclusion, Managed/Local List oder einer eigenen Don't decrypt-Regel. Anschliessend wird der Negativtest wiederholt.
• Greift der Webfilter nicht, wird die echte Firewall Rule auf Web Policy, Scan HTTP and decrypted HTTPS, Block QUIC protocol und DPI/Proxy-Modus geprüft. Eine vorhandene Web Policy beweist keine Decryption.
• Bricht nur eine Anwendung ab, liefern Fehlergrund, TLS-Version, Cipher, Zertifikatskette und Pinning den nächsten Entscheid. Eine temporäre Ausnahme bleibt eng und erhält ein Review-Datum.
• Steigt die Last, verkleinert man den Pilotumfang und vergleicht das gleiche Zeitfenster vor und nach der Änderung. Peak- oder Limit-Hinweise werden appliancebezogen bewertet.

Die SSL/TLS engine darf nur kurz zur Fehlersuche deaktiviert werden. Dann greifen keine SSL/TLS Inspection Rules, und die DPI engine wendet die Firewall-Web-Policy nicht auf HTTPS an; Proxy-HTTPS-Decryption bleibt davon unberührt. Das Deaktivieren ist daher kein gleichwertiger, risikoarmer Ersatz für eine gezielt deaktivierte Pilotregel.

Port-agnostic IPS nur mit bekanntem Vorzustand testen

SFOS prüft entschlüsselten Traffic standardmässig auf jedem TCP-Port gegen IPS-Signaturen. Bei einem reproduzierbaren Fehlalarm dokumentiert man Signature ID, Source, Destination, TCP-Port, Firewall Rule, Inspection Rule und SFOS-Build. Bevorzugt wird eine enge Signaturausnahme mit Action: Allow packet in der tatsächlich verwendeten IPS Policy; Sophos Firewall IPS einrichten und testen beschreibt diesen Weg.

Ein mögliches Fehlerbild der port-agnostischen Prüfung sind wiederholte Treffer derselben IPS-Signatur auf derselben Website. Die Wiederholung allein beweist keinen Fehlalarm. Man gleicht die genaue Signature ID und das Ziel in den Logs ab, prüft den betroffenen legitimen Arbeitsablauf und bewertet das Risiko, bevor eine eng begrenzte, reversible Signaturausnahme freigegeben wird.

Die umfangreichere Prüfung auf mögliche Bedrohungen kann die Last erhöhen und den Durchsatz für entschlüsselten HTTPS-Traffic gegenüber älteren Sophos-Firewall-Versionen geringfügig reduzieren. Das ist ein möglicher, versionsbezogener Effekt, kein garantierter Rückgang und kein Nachweis einer Regression des aktuell eingesetzten Builds. Zur Einordnung vergleicht man Durchsatz, CPU-/Speicherlast und Antwortzeit bei vergleichbarer Verkehrslast im gleichen Zeitfenster; ein einzelner Vergleich ersetzt keine Ursachenanalyse.

Der globale Vergleich in der Device Console ist nur zulässig, wenn der exakte aktuelle Wert on oder off bereits aus der Change-Dokumentation beziehungsweise einer verlässlich gesicherten Konfiguration bekannt ist. Die offizielle SFOS-22-Dokumentation nennt für diesen Schalter keinen Befehl zur Abfrage des aktuellen Zustands. Ist der Vorzustand unbekannt, wird der Test nicht ausgeführt.

Nur bei dokumentiertem Vorzustand on kann man für genau einen vorbereiteten Vergleich setzen:

set ips scan_decrypted_port_agnostic off
set ips scan_decrypted_port_agnostic on

Der zweite Befehl stellt hier ausschliesslich den bekannten Vorzustand on wieder her. War der Vorzustand off, darf man ihn nicht blind einschalten; dann ist off zu erhalten beziehungsweise nach jeder autorisierten Änderung exakt wiederherzustellen. Diese globale Einstellung betrifft die Firewall insgesamt und kann den Durchsatz leicht reduzieren beziehungsweise bei off den Prüfbereich verkleinern. Ergebnis und Zeitfenster werden dokumentiert, ohne daraus allein eine allgemeine Ursache abzuleiten.

Rollback in fester Reihenfolge

Ein Rollback stellt den dokumentierten Vorzustand her, statt eine neue Architektur einzuführen:

1. Die Pilotregel TLS decrypt pilot client deaktivieren. Nicht gleichzeitig Profil, Web Policy und Ausnahmen ändern.
2. Mit dem Pilotclient prüfen, dass diese Rule nicht mehr matcht und der vorher dokumentierte Pfad wieder verwendet wird. Bestehende Sitzungen werden nicht als sofort neu bewertet vorausgesetzt; für den Test wird eine neue Verbindung aufgebaut.
3. Falls nur ein Ziel betroffen ist und der Betrieb dies verlangt, eine zeitlich begrenzte Don't decrypt-Ausnahme setzen und ihren Negativtest ausführen.
4. Temporäre Ausnahmen, Testobjekte und nur für das Pilotprojekt verteilte CA-Einstellungen nach Freigabe kontrolliert zurückbauen. Gemeinsam genutzte CAs werden nicht ungeprüft entfernt.
5. Rule ID, Client, Ziel, sichtbare CA, Log-Event, Zeitpunkt und wiederhergestellte Einstellungen im Change festhalten.

Die Web Policy darf konfiguriert bleiben, doch ohne Decryption kann sie den verschlüsselten HTTPS-Payload nicht scannen. Auf Web Proxy wird nur zurückgestellt, wenn genau dies der gesicherte Vorzustand war. Die ganze SSL/TLS engine wird nicht als Standard-Rollback abgeschaltet, weil dadurch sämtliche DPI-TLS-Regeln und die Anwendung der DPI-Web-Policy auf HTTPS ausfallen.

Der Rollout stoppt, sobald eine geschäftskritische Anwendung ausfällt, Zertifikatswarnungen ausserhalb der Pilotgruppe auftreten, der Scope unerwartet breit matcht oder Last und Fehler die vorab definierten Grenzen überschreiten. Erst wenn positiver Test, Ausnahme-Negativtest, Business-Anwendungen, Logs, Benutzerfeedback und Lastbild im vereinbarten Zeitraum passen, wird die Source-Gruppe schrittweise erweitert.

Im Betrieb werden Exclusions, TLS-Fehler, neue Anwendungen, Last und Benutzerfeedback in einem festgelegten Rhythmus geprüft. Temporäre Ausnahmen bleiben nur bestehen, wenn Owner, Grund und Review-Datum noch gültig sind; andernfalls werden sie nach einem erneuten Positiv- und Negativtest entfernt.

FAQ