Zum Inhalt springen
Avanet

Sophos Firewall DPI Engine oder Web Proxy richtig wählen

Für neue allgemeine Client-Internetregeln ist die DPI Engine meistens der sinnvollere Ausgangspunkt. Sie verarbeitet Firewall-, Web-, Application-Control-, IPS-, Malware- und TLS-Inspection-Entscheidungen in einem gemeinsamen Pfad. Der Web Proxy bleibt richtig, wenn eine ausdrücklich proxygebundene Funktion gebraucht wird, etwa Policy Quota, Batch-Scanning, Web Cache oder ein Direct-Proxy-Design.

Die Wahl ist keine globale Entweder-oder-Entscheidung für die ganze Firewall. Verschiedene Firewallregeln und Clientgruppen können unterschiedliche Pfade verwenden. Für einen einzelnen Testfluss muss aber eindeutig sein, welche Regel greift und ob die DPI Engine, der transparente Web Proxy oder ein explizit konfigurierter Direct Proxy den Request verarbeitet.

⚠️ Eine produktive Regel nicht spontan zwischen DPI Engine und Web Proxy umschalten. Der Wechsel verändert TLS-Decryption, unterstützte Funktionen, Logbild und teilweise das Verhalten von Browsern und Anwendungen. Zuerst einen Pilotclient in einer eigenen Regel testen, den Rückweg dokumentieren und erst danach den Scope erweitern.

Kurzentscheidung

  1. Die betroffene Clientgruppe, Firewall Rule ID, Web Policy, TLS-Anforderung und benötigten Webfunktionen erfassen.
  2. DPI Engine wählen, wenn normaler gerouteter Clienttraffic ohne Proxy-Sonderfunktion kontrolliert werden soll.
  3. Web Proxy wählen, wenn Policy Quota, Batch-Scanning, Web Cache oder ein bewusstes Proxy-Design erforderlich ist.
  4. Bei Direct Proxy zusätzlich Listener, Device Access, PAC- oder Browserkonfiguration und lokale Firewall-Dienste prüfen.
  5. TLS-Decryption am richtigen Ort konfigurieren: SSL/TLS inspection rule für DPI, Proxy-HTTPS-Decryption für Web Proxy.
  6. Einen Pilothost in eine eigene, geloggte Regel aufnehmen und genau einen erlaubten sowie einen blockierten Request auslösen.
  7. Rule ID, Web-Filter-Aktion, Zertifikatsaussteller, Scanergebnis und verwendeten Datenpfad gemeinsam prüfen.
  8. Bei Abweichungen auf den vorherigen Regelpfad zurückgehen, statt beide Modi gleichzeitig am selben Testfluss zu verändern.

DPI Engine, transparenter Web Proxy und Direct Proxy verstehen

Die drei Begriffe beschreiben nicht dieselbe Konfiguration:

  • DPI Engine: Normal gerouteter Traffic wird anhand der Firewallregel und der SSL/TLS inspection rules geprüft. Der Client kennt keinen Proxy.
  • Transparenter Web Proxy: Der Client kennt ebenfalls keinen Proxy. Die Firewallregel verwendet jedoch Use web proxy instead of DPI engine und übergibt klassischen Webtraffic an den Web Proxy.
  • Direct Web Proxy: Browser oder Anwendung verbinden sich ausdrücklich mit dem Proxylistener der Firewall, normalerweise auf TCP-Port 3128. Dieser Pfad entsteht durch die Clientkonfiguration und nicht erst durch den Schalter in der Firewallregel.

Eine Web Policy wirkt in allen Fällen nur, wenn sie in der tatsächlich getroffenen Firewallregel ausgewählt ist. Scan HTTP and decrypted HTTPS aktiviert ebenfalls keine TLS-Decryption von allein. Die Web-Policy-Planung, Kategorien und Regelreihenfolge erklärt Web Protection mit Web Policies einrichten.

Sophos verarbeitet mit der DPI Engine SSL/TLS Inspection, IPS, Application Control, Web Policies und Antivirus in einem gemeinsamen Inspection-Pfad. Plattform und Flow können dabei von Firewall Acceleration profitieren. Proxyverbindungen werden dagegen durch einen Proxyprozess terminiert und neu aufgebaut. Daraus darf trotzdem keine pauschale Aussage abgeleitet werden, dass ein Modus in jeder Umgebung schneller oder sicherer ist. Aussagekräftig sind nur Tests auf der eigenen Appliance mit echten Regeln, Zielanwendungen und realistischem Durchsatz.

Welche Funktionen den Entscheid bestimmen

DPI Engine passt für den allgemeinen Clientpfad

Die DPI Engine ist ein guter Startpunkt, wenn die Umgebung diese Eigenschaften braucht:

  • normaler gerouteter Clienttraffic ohne PAC- oder Browser-Proxyvorgabe
  • SSL/TLS Inspection über regelbasierte Decryption Profiles
  • HTTP- oder TLS-Erkennung auch ausserhalb der klassischen Ports, sofern Regel und Erkennung passen
  • gemeinsame Auswertung mit IPS, Application Control und Malware-Scanning
  • möglichst einheitlicher Datenpfad für neue Client-Internetregeln

In der DPI Engine erfolgt Malware-Scanning immer in Real-time. Welche Scan Engine, Grössenlimits und Fehleraktionen gelten, steht in Sophos Firewall Malware-Scanning konfigurieren und testen.

Web Proxy passt für Proxyfunktionen

Der Web Proxy ist nötig oder zweckmässig, wenn mindestens eine dieser Anforderungen gilt:

  • eine Web Policy verwendet Quota
  • Malware-Scanning soll im Modus Batch statt nur Real-time arbeiten
  • Web Content Cache ist Teil des Designs
  • Clients verwenden einen Direct Proxy mit PAC-, GPO-, MDM- oder Anwendungskonfiguration
  • ein Parent Proxy oder eine andere proxybezogene Architektur ist vorgesehen
  • ein bestehender, getesteter Proxy-Authentifizierungspfad soll erhalten bleiben

Policy Quota wird von der DPI Engine nicht unterstützt. Ein Wechsel auf DPI würde eine solche Policy deshalb nicht gleichwertig übernehmen. Umgekehrt ist ein vorhandener Proxy kein Grund, jede neue Regel ebenfalls auf Proxy Mode zu setzen. Die benötigte Funktion und der tatsächliche Datenpfad entscheiden pro Clientgruppe.

Beim transparenten Web Proxy verarbeitet der klassische Pfad HTTP auf Port 80 und HTTPS auf Port 443. Der Direct Web Proxy hört auf seinem konfigurierten Listener, standardmässig TCP 3128. Listener, PAC-Datei, enge Local Service ACL und Proxyregel führt Direct Web Proxy mit PAC-Datei einrichten vollständig zusammen.

Was beide Modi gemeinsam benötigen

Unabhängig vom Modus braucht der Webschutz:

  • eine Firewallregel, die den Testtraffic wirklich trifft
  • eine ausgewählte Web Policy und aktiviertes Logging
  • klare Source-, Destination-, Service- und Benutzerkriterien
  • eine bewusste QUIC-Entscheidung für Browsertraffic
  • TLS-Sichtbarkeit, wenn HTTPS-Inhalte oder Downloads geprüft werden sollen
  • gezielte statt breite Web- und TLS-Ausnahmen
  • einen realen Positiv- und Negativtest

Web Exceptions können in beiden Designs Schutzprüfungen überspringen. Deshalb werden sie nur nach der Ursachenanalyse gesetzt und mit Owner sowie Review-Datum dokumentiert. Die genaue Trennung von Policy-, Malware-, HTTPS- und Zertifikatsausnahmen steht in Web Exceptions sicher einsetzen.

Beispiel und Pilot vorbereiten

Der Ablauf verwendet folgende Dokumentationswerte:

  • Clientnetz: 10.20.30.0/24
  • Pilotclient: CLIENT-WEB-01
  • feste Pilot-IP: 10.20.30.50
  • bestehende Regel: LAN_Clients_Web
  • Pilotregel: LAN_Web_Mode_Pilot
  • Web Policy: Web_Standard
  • Proxy-FQDN bei Direct Proxy: fw01.example.com
  • Direct-Proxy-Port: 3128

10.20.30.0/24 und 10.20.30.50 werden durch das echte Clientnetz und eine feste, auf der Firewall sichtbare Pilot-IP ersetzt. Hinter der Pilotadresse darf kein NAT weitere Clients verbergen. example.com ist eine reservierte Dokumentationsdomain; fw01.example.com wird nur bei einem Direct-Proxy-Test durch den intern auflösbaren Firewall-FQDN ersetzt.

Vor der Änderung werden die aktuelle Rule ID, Web Policy, Use web proxy instead of DPI engine, Scan HTTP and decrypted HTTPS, QUIC-Einstellung, TLS-Regeln, CA, Ausnahmen und relevante Logs dokumentiert. Zusätzlich braucht der Pilot einen getesteten Rückweg über die unveränderte bestehende Regel.

Die Pilotregel steht oberhalb der bisherigen Clientregel und enthält nur CLIENT-WEB-01 als Source. Destination, Services, Web Policy und weitere Schutzprofile werden zunächst deckungsgleich übernommen. So verändert der Test nur den Inspection-Pfad und nicht gleichzeitig Routing, NAT, Kategorien oder Benutzerlogik.

DPI Mode konfigurieren

Unter Rules and policies > Firewall rules wird die Pilotregel geöffnet:

  1. Use web proxy instead of DPI engine deaktivieren.
  2. Unter Web filtering > Web policy Web_Standard auswählen.
  3. Scan HTTP and decrypted HTTPS entsprechend dem geplanten Malware- und Content-Scanning aktivieren.
  4. Log firewall traffic aktivieren.
  5. QUIC bewusst blockieren, wenn Browser für die Prüfung auf HTTPS über TCP zurückfallen sollen.
  6. Regel speichern und ihre Position oberhalb der allgemeinen Clientregel prüfen.

TLS-Decryption für DPI wird nicht in dieser Firewallregel eingeschaltet. Unter Rules and policies > SSL/TLS inspection rules braucht der Pilot eine passende Regel mit Action: Decrypt, dem vorgesehenen Decryption profile, aktivem Logging und dem richtigen Source-Scope. Die von diesem Pfad verwendete CA muss auf dem Pilotclient vertrauenswürdig sein.

Ein kontrollierter Rollout von CA, Decryption Profile, Ausnahmen und SSL/TLS inspection rule steht in TLS Inspection schrittweise einführen. Ohne passende Decrypt-Regel kann die Web Policy weiterhin Domain- oder Kategorieentscheidungen treffen, aber die erwartete Inhalts- und Downloadprüfung bleibt eingeschränkt.

Web Proxy Mode konfigurieren

Für den transparenten Web Proxy wird dieselbe Pilotregel angepasst:

  1. Use web proxy instead of DPI engine aktivieren.
  2. Unter Web filtering > Web policy Web_Standard auswählen.
  3. Scan HTTP and decrypted HTTPS entsprechend dem Scan-Design aktivieren.
  4. Log firewall traffic aktivieren.
  5. Unter Web > General settings Proxy-CA, Zertifikatsprüfung und Scanmodus kontrollieren.
  6. Decrypt HTTPS during web proxy filtering nur aktivieren, wenn die Proxy-CA auf dem Piloten vertraut und der HTTPS-Test vorbereitet ist.
  7. Regelposition und Pilot-Source erneut prüfen.

In diesem Modus kommen HTTPS-Decryption und Zertifikatsverhalten aus den Proxy-Einstellungen. Eine DPI-SSL/TLS inspection rule ist nicht der Schalter für die Proxyentschlüsselung. Beim Wechsel deshalb nicht nur nach einem vorhandenen Decryption Profile suchen, sondern den tatsächlich im Browser sichtbaren Zertifikatsaussteller prüfen.

Ein Direct Proxy ist ein eigener Clientpfad. Der Browser oder die Anwendung verbindet sich mit fw01.example.com:3128; dafür müssen Listener, Device Access, Firewallregel und Clientkonfiguration zusammenpassen. Use web proxy instead of DPI engine ist keine Voraussetzung für diesen expliziten Request. Direct-Proxy-Traffic hat zudem besondere Grenzen: Traffic Shaping gilt nicht für diesen Pfad, und IPS prüft zwischen Proxy und WAN statt zwischen Client und Proxy.

⚠️ Ein für den Client erreichbarer Direct Proxy kann lokale HTTP- und HTTPS-Dienste der Firewall über den Proxy zugänglich machen, auch wenn die Zonenmatrix diese Dienste nicht freigibt. WebAdmin, User Portal und weitere Managementziele müssen deshalb negativ getestet werden. Ist eine unzulässige Exposition sichtbar, wird der Direct-Proxy-Rollout gestoppt.

Bestehende Regel sicher umstellen

Der Wechsel erfolgt nicht durch Bearbeiten der einzigen produktiven Regel während des laufenden Tests:

  1. Bestehende Regel und relevante Web-/TLS-Einstellungen exportieren oder dokumentieren.
  2. Pilotregel mit identischen Kriterien und nur einem Pilothost erstellen.
  3. Zuerst den aktuellen Modus in der Pilotregel nachbilden und den Ausgangszustand bestätigen.
  4. Nur den Modus und seine zwingend zugehörige TLS-Konfiguration ändern.
  5. Erlaubten, blockierten und entschlüsselten Traffic prüfen.
  6. Geschäftskritische Browser-, Update-, Collaboration- und Login-Flows testen.
  7. Bei Erfolg den Scope schrittweise erweitern.
  8. Bei Abweichung Pilotregel deaktivieren und den unveränderten Rückweg erneut testen.

Eine Regelmigration ist kein geeigneter Zeitpunkt, gleichzeitig Webkategorien, Authentication, NAT, SD-WAN, Ausnahmen und Malware-Engine zu ändern. Mehrere gleichzeitige Änderungen machen ein abweichendes Resultat kaum noch zuordenbar.

Wirkung sauber prüfen

Für jeden Modus werden mindestens dieselben vier Requests verwendet:

  1. eine bewusst erlaubte HTTPS-Seite
  2. eine durch Web_Standard bewusst blockierte Kategorie oder Test-URL
  3. ein kontrollierter HTTPS-Download, der vom geplanten Scanpfad erfasst wird
  4. eine geschäftskritische Anwendung mit Login oder Zertifikatserwartung

Im Log Viewer werden Zeitpunkt, Source-IP, Benutzer, Firewall Rule ID, Web Policy, Kategorie, Action und Scanresultat zusammen geprüft. Die Rule ID muss zur Pilotregel gehören. Eine sichtbare Webseite allein beweist weder die richtige Regel noch den richtigen Inspection-Pfad.

Beim HTTPS-Test wird zusätzlich der Zertifikatsaussteller im Browser kontrolliert. Im DPI Mode muss er zur CA der getroffenen SSL/TLS inspection rule passen. Im Proxy Mode muss er zur unter Web > General settings verwendeten Proxy-CA passen. Zeigt der Browser das unveränderte öffentliche Serverzertifikat, wurde die Verbindung möglicherweise nicht entschlüsselt oder eine Ausnahme hat gegriffen.

Bei einer blockierten Verbindung auf Port 80 oder 443 kann das Firewall-Log die Verbindung als erlaubt zeigen, während das Web-Filter-Log den Request blockiert. Das ist mit dem Proxyverhalten vereinbar: Die Firewall lässt den Flow zum Proxy zu, und der Proxy erzeugt danach die Blockseite. Beide Logs werden deshalb zeitlich korreliert und nicht gegeneinander ausgespielt.

Regelmatch, Log Viewer, Policy Tester und Packet Capture verbindet Sophos Firewall Regeln kontrolliert testen. Bei einem Capture ist zu beachten, dass Diagnosewerkzeuge den Beschleunigungspfad vorübergehend verändern können. Ein Performanceunterschied während einer laufenden Capture-Sitzung ist deshalb kein sauberer Vergleich der beiden Modi.

Fehler nach Symptom eingrenzen

Web Policy greift nicht

Rule ID, Regelposition, Source, Benutzer, Service und ausgewählte Web Policy prüfen. Bei Direct Proxy zusätzlich kontrollieren, ob Browser oder Anwendung wirklich den Listener verwendet. Keine breitere Any-Regel hinzufügen, bevor der tatsächliche Match geklärt ist.

HTTPS wird nicht entschlüsselt

Zuerst den aktiven Modus feststellen. Bei DPI die getroffene SSL/TLS inspection rule, Action, Decryption Profile und CA prüfen. Beim Web Proxy Decrypt HTTPS during web proxy filtering, Proxy-CA und mögliche Web Exceptions kontrollieren. Scan HTTP and decrypted HTTPS ersetzt keinen dieser Decryption-Schritte.

Nach dem Wechsel entstehen Zertifikatsfehler

Den im Client sichtbaren Aussteller, Trust Store, TLS-Ausnahme, Certificate Pinning und eigenen Anwendungsspeicher prüfen. Nicht sofort eine breite Don't decrypt- oder Web-Exception erstellen. Die Ausnahme muss so eng wie möglich auf die tatsächlich betroffene Domain oder Anwendung begrenzt werden.

Quota oder Batch-Scanning fehlt

Diese Funktionen benötigen Web Proxy Mode. Aktive Pilotregel, Schalter Use web proxy instead of DPI engine, Policy-Zuordnung und Proxy-Scanmodus prüfen. Ein grüner DPI-Test kann diese Proxyfunktion nicht bestätigen.

Website ist blockiert, Firewall-Log zeigt aber erlaubt

Web Filter und Firewall zeitlich zusammenführen. Bei Proxytraffic kann die Firewall die Verbindung zum Proxy erlauben, bevor der Proxy die URL blockiert und eine Blockseite liefert. Kategorie, Action, Rule ID und Web-Policy-Regel liefern die eigentliche Entscheidung.

Nur einzelne Ports oder Anwendungen scheitern

Klären, ob transparenter Proxy, Direct Proxy oder DPI verwendet wird. Transparenter Proxy fokussiert die klassischen Webports; Direct Proxy braucht einen unterstützten Client und den Listener; DPI kann TLS auf weiteren TCP-Ports erkennen, wenn Regel und Decryption passen. Keine universelle Portfreigabe als Diagnoseersatz setzen.

Logs reichen für die Zuordnung nicht aus

Firewall- und Web-Logging aktivieren und den Test mit eindeutigem Zeitpunkt wiederholen. Je nach Pfad sind Webproxy-, TLS- und Inspection-Logs relevant. Eine Einordnung der Dateien und ein sicherer Export stehen in Sophos Firewall Services und Logdateien.

Rollback und Betrieb

Für den Rückweg wird die Pilotregel deaktiviert, nicht die produktive Web Policy gelöscht. Danach muss der Pilot wieder die zuvor dokumentierte Rule ID und den ursprünglichen Datenpfad verwenden. Temporäre Proxy-Device-Access-Freigaben, PAC-Zuweisungen und Pilot-Ausnahmen werden auf den Vorzustand gesetzt.

Im Betrieb erhält jede regelbezogene Modusentscheidung einen Owner und einen nachvollziehbaren Grund. Proxy-only-Funktionen, Decryption Profiles, CA-Wechsel, Ausnahmen und Clientgruppen werden regelmässig geprüft. Ein späterer Wechsel beginnt erneut mit einem Pilot, weil neue Browser-, TLS- und Anwendungsstände das Ergebnis verändern können.

Betriebscheckliste

  • Clientgruppe, Pilot-IP und Rückweg sind dokumentiert.
  • Tatsächliche Firewall Rule ID und Regelposition sind bekannt.
  • Web Policy und Logging sind in der Pilotregel aktiv.
  • Proxy-only-Funktionen wurden vor der Moduswahl erfasst.
  • DPI- und Proxy-TLS-Decryption sind nicht verwechselt.
  • Die tatsächlich verwendete CA ist auf dem Pilotclient vertrauenswürdig.
  • QUIC wurde bewusst behandelt und mit Browsern getestet.
  • Erlaubter, blockierter und gescannter Echttraffic wurde geprüft.
  • Zertifikatsaussteller und Web-Filter-Aktion passen zum Modus.
  • Direct-Proxy-Managementziele wurden negativ getestet, falls dieser Pfad verwendet wird.
  • Firewall- und Web-Logs wurden gemeinsam ausgewertet.
  • Keine breite Ausnahme oder Any-Regel wurde als Schnellfix gesetzt.
  • Rollback, Owner und Review-Datum sind dokumentiert.

Häufige Fragen

Welcher Modus passt für eine neue Client-Internetregel?

Ohne Proxy-Sonderfunktion ist die DPI Engine meistens der sinnvollere Ausgangspunkt. Web Proxy Mode wird bewusst gewählt, wenn Policy Quota, Batch-Scanning, Cache, Direct Proxy oder eine andere proxygebundene Anforderung den Pfad bestimmt. Entscheidend bleibt ein Pilot auf der eigenen Appliance.

Können DPI Engine und Web Proxy gleichzeitig verwendet werden?

Ja, in unterschiedlichen Firewallregeln oder für unterschiedliche Clientpfade. Ein einzelner Testfluss muss aber eindeutig einer Regel und einem Modus zugeordnet sein. Sonst lassen sich TLS-, Policy- und Logresultate nicht verlässlich erklären.

Braucht der Direct Web Proxy den Schalter Use web proxy instead of DPI engine?

Nein. Der Direct-Proxy-Pfad entsteht, weil Browser oder Anwendung ausdrücklich den Proxylistener verwendet. Der Schalter entscheidet, ob normaler Webtraffic einer Firewallregel transparent über den Web Proxy statt über die DPI Engine verarbeitet wird.

Kann dieselbe CA für DPI und Web Proxy verwendet werden?

Eine Umgebung kann dieselbe vertrauenswürdige CA vorsehen, die Konfigurationsorte bleiben aber getrennt. Entscheidend ist nicht der geplante Name, sondern welcher Zertifikatsaussteller beim echten DPI- beziehungsweise Proxytest im Client sichtbar ist.