Zum Inhalt springen
Avanet

Sophos Firewall Upstream Proxy einrichten und testen

Ein Upstream Proxy, auch Parent Proxy genannt, ist die nächste Proxyinstanz hinter der Sophos Firewall. Interne Clients senden ihre Web Requests zuerst an den Web Proxy der Firewall. Die Firewall prüft den Traffic und leitet ihn danach an den übergeordneten Proxy weiter. Erst dieser baut die Verbindung zum Internet auf.

Sophos Firewall unterstützt genau einen Upstream Proxy. Die DPI Engine kann diesen Pfad nicht verwenden. Deshalb müssen die betroffenen Webregeln im Proxy-Modus mit Use web proxy instead of DPI engine arbeiten.

⚠️ Der Parent Proxy ist eine globale Abhängigkeit für Web Requests im Proxy-Modus. Vor dem Aktivieren ein aktuelles Backup, eine unabhängige Adminverbindung, die bestehenden Proxy-Regeln, den ursprünglichen NAT-Pfad und einen getesteten Rückweg dokumentieren. Sophos Firewall bietet keinen zweiten Parent-Proxy-Eintrag als eingebautes Failoverziel.

Die folgenden Feldnamen und Menüpfade sind für SFOS 22 geprüft. Der Ablauf behandelt HTTP- und HTTPS-Anfragen, die aus internen Netzen über den Web Proxy laufen. Sophos beschreibt den Upstream Proxy für Webanfragen aus dem Netzwerk, nicht als Proxy für systemeigene Verbindungen der Firewall. Firmwareupdates, Lizenzierung, Sophos Central und andere Systemdienste müssen deshalb separat auf Erreichbarkeit geprüft werden.

Webausnahmen ändern diesen Geltungsbereich nicht. Unter Web > Exceptions lässt sich für passende Webanfragen gezielt die HTTPS-Entschlüsselung, Zertifikatsprüfung, Malware- und Inhaltsprüfung, Zero-Day-Analyse oder Web Policy überspringen. Eine solche Ausnahme ist kein dokumentierter Weg am Parent Proxy vorbei. Für HTTPS ohne Entschlüsselung muss das Muster den Hostnamen treffen; ein Muster nur für den URL-Pfad greift erst bei HTTP oder entschlüsseltem HTTPS. Besonders vorsichtig mit HTTPS decryption: Wird sie übersprungen, entfallen auch davon abhängige Prüfungen, und passende Verbindungen mit ungültigen Zertifikaten können zugelassen werden.

Upstream Proxy in zehn Schritten

  1. Einen verwalteten Pilotclient, einen erlaubten und einen blockierten Web Request festlegen.
  2. Entscheiden, ob der Parent Proxy im WAN oder in LAN beziehungsweise DMZ steht.
  3. Proxy-IP, Port, optionales Servicekonto, Routing und Rückweg dokumentieren.
  4. Den Proxy als IP Host anlegen und seine Erreichbarkeit von der Firewall aus prüfen.
  5. Unter Routing > Upstream proxy den Modus Parent proxy auswählen und Adresse, Port sowie optionale Zugangsdaten eintragen.
  6. Die Client-Webregel auf Use web proxy instead of DPI engine stellen und Logging aktivieren.
  7. Für einen Proxy im WAN eine enge Client-zu-Proxy-Regel erstellen und die wirksame SNAT-Regel prüfen.
  8. Für einen Proxy in LAN oder DMZ zusätzlich den Clientpfad per MASQ übersetzen und eine eigene Proxy-zu-WAN-Regel ohne Web Policy und Malware-Scan erstellen.
  9. Erlaubten, blockierten und direkten Proxyzugriff mit Firewall Rule ID, NAT Rule ID, Web- und Proxylogs abnehmen.
  10. Proxy-Ausfall, HA-Failover und Rollback im Wartungsfenster testen, bevor weitere Netze aufgenommen werden.

Zwei Verbindungen und zwei Topologien verstehen

Der Datenfluss besteht aus zwei getrennten Verbindungen:

  1. Der Client sendet einen HTTP- oder HTTPS-Request an beziehungsweise durch den Web Proxy der Sophos Firewall.
  2. Die Sophos Firewall erzeugt daraus die Verbindung zum Parent Proxy. Dieser sendet den Request weiter ins Internet.

Ein Browser muss deshalb nicht direkt auf den Parent Proxy zeigen. Bei einem expliziten Direct Web Proxy mit PAC-Datei bleibt die Sophos Firewall das Proxyziel des Clients. Der Parent Proxy ist der nächste Hop hinter der Firewall.

Parent Proxy im WAN

Steht der Parent Proxy im WAN, braucht der Datenpfad neben der Web-Proxy-Regel eine Firewallregel von den internen Clientnetzen zum konkreten Proxyhost und Proxyport. Private Quelladressen werden normalerweise durch die bestehende Default SNAT IPv4-Regel maskiert. Eine eigene SNAT-Regel ist nur nötig, wenn dieser Pfad eine andere Source Translation erhalten soll.

Parent Proxy in LAN oder DMZ

Steht der Parent Proxy in LAN oder DMZ, bleibt sein Internetpfad hinter der Sophos Firewall. Dann sind drei zusätzliche Bausteine nötig:

  • eine Client-zu-Proxy-Firewallregel,
  • eine enge MASQ-SNAT-Regel für genau diesen Pfad,
  • eine Proxy-zu-WAN-Regel ohne Web Policy und ohne erneuten Malware- oder Content-Scan.

Die Proxy-zu-WAN-Regel steht oberhalb überlappender Regeln im Web-Proxy-Modus. Sonst kann der vom Parent Proxy erzeugte Traffic erneut in den Proxyweg geraten oder anders als geplant geprüft werden.

Beispiel und austauschbare Werte

Der Artikel verwendet zwei Alternativen:

  • Pilotclient: CLIENT-WEB-01
  • feste Client-IP: 10.20.30.50
  • Clientnetz: 10.20.30.0/24
  • Clientzone: LAN
  • Webregel: LAN_Web_ParentProxy_Pilot
  • Parent-Proxy-Port: 3128
  • WAN-Proxy: PARENT-WAN_192.0.2.80
  • WAN-Proxy-IP: 192.0.2.80
  • DMZ-Proxy: PARENT-DMZ_10.20.40.20
  • DMZ-Proxy-IP: 10.20.40.20
  • DMZ-Zone: DMZ
  • optionales Proxykonto: svc_sfos_parent_proxy

192.0.2.80 ist eine Dokumentationsadresse und wird durch die echte öffentliche oder providerseitige IP des Upstream Proxys ersetzt. 10.20.40.20 steht für einen internen Proxy in einer eigenen DMZ. Die gewählte Adresse muss aus Sicht der Sophos Firewall über den vorgesehenen Pfad erreichbar sein.

Sophos erlaubt eine IPv4-Adresse, IPv6-Adresse oder einen Domainnamen. Die Wahl verändert den Prüfbereich: Bei einem Domainnamen prüft die Firewall den gesamten Traffic zum konfigurierten Upstream-Port. Bei einer IP-Adresse gilt dies nur für Traffic zu genau dieser IP-Port-Kombination. Sophos empfiehlt die IP-Adresse, damit die Firewall ihre Policy auch auf direkte Clientverbindungen zum Upstream Proxy anwenden kann. Ein Domainname ist kein belegter zweiter Proxy- oder Failovermechanismus.

Port 3128 ist ein häufig verwendeter Proxyport, aber kein unveränderlicher Produktwert. Wenn der Parent Proxy einen anderen Listener nutzt, müssen Host-/Serviceobjekt, Firewallregeln, Packet Capture, Monitoring und Tests denselben Port verwenden.

Das optionale Konto wird nur eingesetzt, wenn der Parent Proxy Authentisierung verlangt. Dafür ein dediziertes, möglichst eingeschränktes Servicekonto verwenden, Passwortrotation und Owner dokumentieren und keine persönlichen Adminkonten hinterlegen.

Parent Proxy global eintragen

Vor der Änderung muss die Firewall den Proxy über Routing und Firewallpfad erreichen können. Ein TCP-Porttest allein beweist noch keine funktionierende Proxy-Authentisierung oder HTTP-Weiterleitung.

  1. Unter Hosts and services > IP host den konkreten Proxyhost anlegen.
  2. Unter Routing > Upstream proxy Parent proxy auswählen.
  3. IP-Adresse oder Domainname des Parent Proxys eintragen. Für diesen Ablauf die bestätigte IP verwenden.
  4. Den tatsächlichen Proxyport eintragen, im Beispiel 3128.
  5. Username und Password nur hinterlegen, wenn der Parent Proxy eine Anmeldung verlangt.
  6. Mit Apply speichern.

Diese Einstellung wirkt nicht wie eine einzelne Firewallregel nur für den Piloten. Der Pilot wird über enge Regeln und deren Reihenfolge begrenzt. Vor dem Speichern deshalb alle bestehenden Regeln erfassen, die bereits Use web proxy instead of DPI engine verwenden.

SFOS 22 bietet in dieser Maske keine Auswahl für ein Authentifizierungsverfahren und keinen Zertifikats-Upload. Vor der Umstellung muss daher bestätigt sein, dass der Parent Proxy die von Sophos gesendeten Zugangsdaten akzeptiert. Ein erfolgreicher TCP-Verbindungsaufbau reicht dafür nicht. Erst eine erfolgreiche Webanfrage und der passende Eintrag für das konfigurierte Konto im Parent-Proxy-Log bestätigen die Anmeldung; 407 Proxy Authentication Required weist dagegen auf fehlende oder abgelehnte Zugangsdaten hin.

Webregel in den Proxy-Modus setzen

Die Webregel vom internen Netz zum WAN bindet Web Policy und Scanning an den ersten Teil des Datenflusses. Die allgemeine Regelmechanik erklärt Firewallregeln auf Sophos Firewall.

Für den Piloten wird eine eigene Regel erstellt oder eine vorhandene Pilotregel eng angepasst:

  • Source zones: LAN
  • Source networks and devices: CLIENT-WEB-01 oder das bestätigte Pilotnetz
  • Destination zones: WAN
  • Destination networks: nur die vorgesehenen Webziele oder bewusst Any
  • Services: die benötigten HTTP-/HTTPS-Dienste
  • Web policy: die vorbereitete Pilotpolicy
  • Scan HTTP and decrypted HTTPS: nur wenn der geplante Schutz dies verlangt
  • Use web proxy instead of DPI engine: aktiviert
  • Block QUIC protocol: aktiviert; die Option blockiert für passende Verbindungen ausgehendes UDP zu Port 80 und 443 und verhindert damit, dass QUIC die Webfilterung umgeht
  • Decrypt HTTPS during web proxy filtering: nur nach geplantem Zertifikats-Rollout aktiviert
  • Log firewall traffic: aktiviert

Wie Kategorien, Ausnahmen und echte erlaubte sowie blockierte Ziele abgenommen werden, erklärt Web Protection auf Sophos Firewall.

Der Parent Proxy funktioniert nicht mit der DPI Engine. Ein grüner Regelstatus beweist den tatsächlichen Pfad nicht. Nach dem Speichern muss der Testrequest die erwartete Firewall Rule ID und Web Policy zeigen.

HTTPS-Decryption ist eine eigene Entscheidung. Im Web-Proxy-Modus wird sie in der Firewallregel mit Decrypt HTTPS during web proxy filtering eingeschaltet. Unter Web > General settings > HTTPS decryption and scanning wählt man bei HTTPS scanning certificate authority (CA) die CA aus und verteilt deren Zertifikat vor dem Pilotversuch an die Endgeräte. Block invalid certificates sollte nicht beiläufig abgeschaltet werden. Wenn sowohl Sophos Firewall als auch Parent Proxy TLS entschlüsseln, muss klar sein, welche Instanz welches Zertifikat ausstellt und welcher CA die jeweilige Gegenstelle vertraut. Der kontrollierte TLS-Inspection-Rollout bleibt dafür der Detailablauf.

Parent Proxy im WAN anbinden

Für einen Proxy im WAN wird zusätzlich eine Regel erstellt, die den Proxyhop ausdrücklich erlaubt:

  • Name: LAN_to_PARENT-WAN_3128
  • Source zones: LAN
  • Source networks and devices: 10.20.30.0/24 oder enger der Pilot
  • Destination zones: WAN
  • Destination networks: PARENT-WAN_192.0.2.80
  • Services: eigener TCP-Service für 3128
  • Log firewall traffic: aktiviert

Die Regel darf nicht als breite allgemeine LAN-zu-WAN-Freigabe enden. Proxyhost und Proxyport bleiben konkret. Nach dem Test wird anhand der Firewall Rule ID geprüft, dass genau diese Regel trifft.

Private Clientadressen werden in einer Standardkonfiguration häufig durch Default SNAT IPv4 maskiert. Im Log Viewer und Packet Capture muss dennoch die wirksame NAT Rule ID kontrolliert werden. Eine neue SNAT-Regel ist nur sinnvoll, wenn der Providerproxy eine bestimmte Quelladresse verlangt oder der vorhandene NAT-Pfad nicht passt. Die Grundlogik erklärt NAT auf Sophos Firewall.

Parent Proxy in LAN oder DMZ anbinden

Bei einem Proxy in LAN oder DMZ muss sein eigener Internetverkehr vom Client-zu-Proxy-Pfad getrennt bleiben.

Client-zu-Proxy-Regel erstellen

Die erste Regel erlaubt nur den bestätigten Clientpfad:

  • Name: LAN_to_PARENT-DMZ_3128
  • Source zones: LAN
  • Source networks and devices: 10.20.30.0/24 oder enger der Pilot
  • Destination zones: DMZ
  • Destination networks: PARENT-DMZ_10.20.40.20
  • Services: eigener TCP-Service für 3128
  • Log firewall traffic: aktiviert

Steht der Proxy in LAN, wird dessen tatsächliche Zone verwendet. Any ist für den produktiven Avanet-Ablauf weder als Source noch als Destination nötig.

SNAT nur für diesen Pfad erstellen

Unter Rules and policies > NAT rules wird eine enge Source-NAT-Regel angelegt:

  • Original source: 10.20.30.0/24 oder enger der Pilot
  • Translated source (SNAT): MASQ
  • Original destination: PARENT-DMZ_10.20.40.20
  • Translated destination (DNAT): Original
  • Original service: TCP 3128
  • Inbound interface: das bestätigte Clientinterface oder bewusst Any
  • Outbound interface: das Interface zum Proxy oder bewusst Any

Interfacefelder werden nur gesetzt, wenn der reale Pfad stabil ist. Ein falsches Interface verhindert den Match. Die Regel wird über die erwartete NAT Rule ID abgenommen und nicht allein anhand ihrer Position.

Proxy-zu-WAN-Regel ohne erneute Webprüfung erstellen

Der Parent Proxy braucht eine eigene Regel für seine Internetverbindungen:

  • Name: PARENT-DMZ_to_WAN
  • Source zones: DMZ
  • Source networks and devices: PARENT-DMZ_10.20.40.20
  • Destination zones: WAN
  • Destination networks: die benötigten Ziele oder bewusst Any
  • Web policy: None
  • Malware and content scanning: deaktiviert
  • Log firewall traffic: aktiviert

Diese Regel wird oberhalb anderer Regeln platziert, die mit derselben Source-/Destination-Kombination im Web-Proxy-Modus treffen könnten. Eine IPS Policy kann bewusst eingesetzt werden, wenn der Betrieb sie für den Proxy-zu-WAN-Pfad verlangt. Web Policy und Malwareprüfung werden hier nicht ein zweites Mal angewendet.

Für den WAN-Hop des Parent Proxys gilt wieder die tatsächlich treffende SNAT-Regel. Die Default SNAT IPv4 kann ausreichen; die NAT Rule ID entscheidet.

Datenpfad kontrolliert abnehmen

Ein erfolgreicher Test bestätigt nicht nur, dass irgendeine Webseite öffnet. Er verbindet Client, Regel, NAT, Web Policy und Parent Proxy zu einer gemeinsamen Zeitlinie.

  1. Zeitpunkt mit Zeitzone, Pilot-IP, Ziel-URL und erwartete Aktion notieren.
  2. Eine erlaubte HTTP- oder HTTPS-Seite öffnen.
  3. Eine Kategorie oder Test-URL öffnen, welche die Pilot-Web-Policy blockieren soll.
  4. Im Log Viewer die erwartete Firewall Rule ID, NAT Rule ID, Web Policy, Aktion sowie Source und Destination prüfen.
  5. Im Logging oder Monitoring des Parent Proxys bestätigen, dass beide Requests von der erwarteten Sophos-/NAT-Source eintreffen.
  6. Im Built-in Packet Capture mit host 192.0.2.80 and port 3128 beziehungsweise der echten Proxy-IP den Hin- und Rückweg prüfen.
  7. Vom Pilotclient einen direkten Zugriff auf Proxy-IP und Proxyport testen. Bei einer als IP eingetragenen Parent-Proxy-Adresse muss die Sophos-Policy auch für diesen Weg greifen; ein ungeprüfter Bypass ist eine Stop-Bedingung.
  8. Parent Proxy kontrolliert unerreichbar machen oder den Testport im Wartungsfenster sperren. Das beobachtete Fehlerverhalten und die Alarmierung dokumentieren, ohne einen automatischen zweiten Proxy anzunehmen.

Der Test gilt erst als bestanden, wenn erlaubter und blockierter Request korrekt sind, der Parent Proxy beide sieht und der direkte Zugriff die Sicherheitsvorgabe nicht umgeht. Firewallregel systematisch testen erklärt die Rule-ID- und Packet-Capture-Abnahme im Detail.

HA getrennt prüfen

In Active-Active kann Sophos Parent-Proxy-TCP-Traffic zwischen den Nodes verteilen. Jeder Node speichert jedoch nur die Logs für den Traffic, den er verarbeitet hat. Deshalb bei der Fehlersuche beide Nodes beziehungsweise den zum Ereigniszeitpunkt verarbeitenden Node berücksichtigen.

Ein kontrollierter Failover wird mit einer neuen Browserverbindung wiederholt. Danach Firewall Rule ID, NAT Rule ID, Parent-Proxy-Log und erlaubte sowie blockierte Aktion erneut prüfen. Keine unterbrechungsfreie Fortsetzung einer bereits laufenden Proxyverbindung voraussetzen.

Fehler systematisch eingrenzen

Webseiten öffnen direkt, aber nicht über den Parent Proxy

  • Prüfen, ob die Client-Webregel Use web proxy instead of DPI engine verwendet.
  • Die tatsächliche Firewall Rule ID und Regelreihenfolge kontrollieren.
  • Route, Proxy-IP, Port, NAT Rule ID und Rückweg prüfen.
  • Bei Authentifizierung Benutzername, Passwort, Sperrstatus und das Protokoll des Parent Proxys abgleichen.
  • Ein offener TCP-Port beweist weder eine erfolgreiche Proxyanfrage noch eine gültige Authentifizierung.

Der Parent Proxy antwortet mit 407 oder einer Authentisierungsfehlermeldung

Zugangsdaten und Kontostatus am Parent Proxy prüfen. SFOS bietet hier keine Auswahl eines Authentifizierungsverfahrens; deshalb auch die vom Parent Proxy erwartete Methode in dessen Log prüfen. Persönliche Adminzugänge nicht als schnelle Umgehung hinterlegen. Nach einer Passwortänderung den globalen Eintrag kontrolliert aktualisieren, eine neue Verbindung testen und den Zugriff mit dem alten Passwort entziehen.

Ein Proxy in LAN oder DMZ erreicht das Internet nicht

  • Client-zu-Proxy-Regel und deren Rule ID prüfen.
  • Die enge MASQ-Regel und NAT Rule ID kontrollieren.
  • Proxy-zu-WAN-Regel, Position und tatsächliche Proxy-Source prüfen.
  • Sicherstellen, dass Web policy auf None steht und Malware-/Content-Scanning nicht erneut aktiviert ist.
  • Route und SNAT für den WAN-Hop des Parent Proxys getrennt prüfen.

Die Web Policy trifft doppelt oder der Datenfluss läuft im Kreis

Die Proxy-zu-WAN-Regel muss vor überlappenden Regeln im Web-Proxy-Modus stehen. Source, Destination, Service und Rule ID jedes Hops vergleichen. In awarrenhttp.log, fwlog.log, firewall_rule.log und nat_rule.log nach derselben Zeit, Client-IP, Proxy-IP und Zieladresse suchen. Die Zuordnung der Dateien erklärt Sophos Firewall Service-Logs.

Keine Proxydienste neu starten und keine Debugausgabe dauerhaft aktivieren. Zuerst Log Viewer, Packet Capture und die vorhandenen Logdateien sichern. awarrenhttp_access.log enthält detaillierte Einzelrequests nur bei aktiviertem Debug und ist deshalb kein Standardbeweis für jeden Incident.

HTTPS zeigt unerwartete Zertifikate oder Zertifikatsfehler

Feststellen, ob Sophos Firewall, Parent Proxy oder beide TLS entschlüsseln. Das Ausstellerzertifikat im Browser, die treffende Web Policy, SSL/TLS-Inspection-Regel und das Upstream-Proxy-Log vergleichen. Nicht gleichzeitig CA-Verteilung, Decryption und Parent-Proxy-Regeln auf Verdacht ändern.

Nur einzelne Anwendungen umgehen den Proxy

Nicht jede Anwendung verwendet Browser- oder Betriebssystem-Proxyeinstellungen. Der Parent Proxy ist kein allgemeiner Tunnel für beliebigen TCP-/UDP-Traffic. Für die betroffene Anwendung den tatsächlichen Datenpfad und die treffende Firewallregel erfassen, statt aus einem erfolgreichen Browsertest auf alle Programme zu schliessen.

Betrieb und Rollback

Der einzelne Parent Proxy ist eine dokumentierte Abhängigkeit. Monitoring sollte nicht nur den TCP-Port prüfen, sondern einen echten HTTP-/HTTPS-Request, Authentisierung, Latenz und die erwartete Upstream-Antwort. Owner, Wartungsfenster, Secretablauf und Wiederherstellungsweg gehören in die Betriebsdokumentation.

Für einen Rollback:

  1. Zeit, Konfiguration, Rule IDs und NAT Rule IDs vor der Änderung sichern.
  2. Unter Routing > Upstream proxy den dokumentierten Vorzustand wiederherstellen: entweder den vorherigen Modus ohne Parent Proxy oder die bisherigen Werte für Adresse, Port, Username und Password.
  3. Die Client-Webregel auf ihren vorherigen DPI- oder Proxy-Modus zurücksetzen.
  4. Temporäre Client-zu-Proxy-, Proxy-zu-WAN- und SNAT-Regeln erst nach bestätigtem Ersatzpfad deaktivieren.
  5. Eine neue Browser-/Anwendungsverbindung öffnen und erlaubten sowie blockierten Request erneut testen.
  6. In HA den Test für den aktuellen verarbeitenden Node und nach einem geplanten Failover wiederholen.
  7. Nicht mehr benötigte Proxyzugänge und Secrets erst nach erfolgreicher Abnahme entfernen.

Checkliste

  • Ein aktuelles Backup, unabhängige Adminverbindung und der Vorzustand sind dokumentiert.
  • Proxyposition WAN, LAN oder DMZ, IP, Port, Routing und Rückweg sind bestätigt.
  • Der Parent Proxy ist als IP eingetragen oder die FQDN-Entscheidung ist begründet.
  • Die Client-Webregel verwendet Use web proxy instead of DPI engine.
  • Client-zu-Proxy-Regel, Firewall Rule ID und Proxyport stimmen.
  • Für LAN/DMZ sind enge MASQ-SNAT- und Proxy-zu-WAN-Regeln vorhanden.
  • Die Proxy-zu-WAN-Regel hat Web Policy None und keine erneute Malwareprüfung.
  • Erlaubter, blockierter und direkter Proxyzugriff wurden geprüft.
  • Parent-Proxy-Ausfall, Alarmierung, HA-Failover und Rollback wurden getestet.
  • Owner, Secretrotation, Monitoring und Review-Datum sind dokumentiert.

Häufige Fragen

Nein. Beim transparenten Web Proxy kennt der Client keinen Proxy. Beim Direct Web Proxy zeigt der Browser auf die Sophos Firewall. Der Parent Proxy ist in beiden Fällen der nächste Proxyhop hinter der Firewall.

Nein. Sophos dokumentiert den Upstream Proxy nur für den Web-Proxy-Modus. Die betroffene Webregel muss Use web proxy instead of DPI engine verwenden.

Nein. Sophos dokumentiert einen einzelnen Upstream-Proxy-Eintrag. Hochverfügbarkeit muss deshalb auf der Upstream-Seite über eine getestete stabile Adresse oder einen dort bereitgestellten HA-Dienst gelöst werden. Ein Domainname allein ist kein belegter Parent-Proxy-Failovermechanismus.