Sophos Firewall HTTP Proxy Settings sicher prüfen

Die HTTP Proxy Settings der Sophos Firewall steuern globale Eigenschaften des Web Proxy und teilweise des Captive Portal. Dazu gehören TLS-Mindestversionen, Timeouts, Via Header, Schutz vor Proxy-Loops und das Verhalten der URL-Kategorisierung während des TLS-Handshakes. Eine Änderung kann deshalb mehrere Regeln, Benutzergruppen und Clientnetze gleichzeitig betreffen.

Der sichere Einstieg ist der lesende Befehl show http_proxy in der Device Console. Erst wenn ein reproduzierbares Problem zu genau einem Parameter passt, wird mit set http_proxy eine einzelne Einstellung geändert. Der aktuelle Wert, ein enger Positiv- und Negativtest sowie der Rückweg werden vorher festgehalten.

⚠️ Die Ausgabe von show http_proxy ist eine Baseline, keine Tuning-Liste. Insbesondere veraltete TLS-Versionen, deaktivierte URL-Kategorisierung oder weitergeleiteter Nicht-HTTP-Traffic werden nicht vorsorglich aktiviert. Auch ein von Sophos dokumentierter Standardwert ist nicht automatisch eine Empfehlung für ein neues Sicherheitsdesign.

Die eigentliche Einrichtung von Listener, Device Access, Firewallregel und PAC-Datei beschreibt Direct Web Proxy mit PAC-Datei einrichten. Hier geht es ausschliesslich um die globalen CLI-Parameter dahinter.

Sicherer Kurzweg

1. Das Symptom mit Client, Ziel, Uhrzeit, Proxyweg und betroffener Funktion reproduzieren.
2. In der Device Console show http_proxy ausführen und die vollständige Ausgabe geschützt sichern.
3. Den passenden Parameter, dessen aktuelle Wirkung und den exakten Rollback-Befehl dokumentieren.
4. Nur diesen einen Wert ändern und eine neue Verbindung für den Test erzeugen.
5. Web Proxy und Captive Portal getrennt prüfen, wenn der Parameter beide Funktionen betrifft.
6. Bleibt die erwartete Wirkung aus oder entsteht ein Nebeneffekt, sofort auf den gesicherten Ausgangswert zurückstellen.

Der Zugriff erfolgt nach einem abgesicherten SSH-Login über 4. Device Console. Host-Key-Prüfung, Device Access und die Trennung von Device Console und Advanced Shell erklärt Sophos Firewall CLI Troubleshooting.

show http_proxy

Dokumentierte Werte richtig lesen

Sophos dokumentiert für SFOS 22 folgende Standardausgabe. Der tatsächlich angezeigte Wert auf der eigenen Firewall bleibt jedoch die massgebliche Basis für Änderung und Rollback.

Die überraschend aktiv dokumentierten TLS-1.1-Werte sind kein Grund, TLS 1.1 in einem neuen Design zuzulassen. Sophos bezeichnet TLS 1.0 und TLS 1.1 selbst als unsicher und empfiehlt beide Versionen nicht. Entscheidend sind der aktuelle Zustand, die reale Legacy-Abhängigkeit und ein kontrollierter Test mit dem betroffenen Portal beziehungsweise Proxyziel.

Via Header und Proxy-Loops

Mit add_via_header on ergänzt der Proxy einen HTTP-Via-Header. Er macht Zwischenstationen sichtbar, übermittelt Protokollinformationen und hilft Proxys, Schleifen zu erkennen. Das ist der dokumentierte Standard.

block_proxy_loop on verwirft Requests, wenn doppelte Via-Werte auf eine Schleife hindeuten. Sophos dokumentiert den Schutz standardmässig als off. Ein Proxy-Loop kann beispielsweise entstehen, wenn ein Upstream Proxy den Request durch DNS, PAC-Datei oder Routing wieder an dieselbe Sophos Firewall zurücksendet.

Vor einer Änderung werden PAC-Datei, Upstream Proxy, DNS-Auflösung und der tatsächliche Rückweg geprüft. Ein Schalter ersetzt keine Korrektur dieses Pfads.

set http_proxy block_proxy_loop on

Für einen zeitlich begrenzten Nachweis verlangt Sophos zusätzlich Debug-Logging des Dienstes awarrenhttp. Dabei kann in awarrenhttp.log die Meldung Duplicate Via header values, proxy loop erscheinen. Debug ist standardmässig aus und kann Leistung, Speicherbedarf und Datenschutz beeinflussen. Es wird nur für einen reproduzierbaren Test eingeschaltet, danach wieder deaktiviert und nicht als Dauerüberwachung verwendet. Die Logdateien und der sichere Analyseablauf stehen unter Sophos Firewall Services und Logdateien.

TLS für Web Proxy und Captive Portal

Mindestversionen getrennt behandeln

Die Device Console kann TLS 1.0 und TLS 1.1 für Web Proxy und Captive Portal getrennt steuern. Damit ist ein enger Legacy-Test möglich, ohne automatisch beide Funktionen gleich zu lockern. In WebAdmin wird anschliessend jedoch nur die Mindestversion des Proxy angezeigt; Sophos weist bei abweichenden Werten auf die Differenz hin.

Die vier Schalter lauten:

set http_proxy captive_portal_tlsv1_0 off
set http_proxy captive_portal_tlsv1_1 off
set http_proxy proxy_tlsv1_0 off
set http_proxy proxy_tlsv1_1 off

Diese Befehle zeigen das sichere Zielbild für Umgebungen ohne Legacy-Abhängigkeit, nicht eine pauschale Migrationsanweisung. Vor dem Abschalten werden reale Portal-Logins, Direct-Proxy-Clients, entschlüsselte HTTPS-Ziele und verwaltete Altanwendungen inventarisiert. Danach wird jede Funktion mit einem frischen Client-Handshake getestet. Für eine grössere Umstellung eignet sich der schrittweise Ablauf unter TLS Inspection ausrollen.

Wenn ein alter Client nachweislich nur TLS 1.0 oder TLS 1.1 kann, wird die Version nicht stillschweigend global wieder aktiviert. Zuerst werden Update, Austausch oder ein enger separater Pfad geprüft. Bleibt eine befristete Ausnahme unvermeidbar, braucht sie Owner, Ablaufdatum, dokumentiertes Risiko und einen Test, der belegt, welche der beiden Funktionen die Lockerung wirklich benötigt.

X-Frame-Options schützt das Portal

captive_portal_x_frame_options on fügt dem Captive Portal einen Schutz gegen Einbettung in fremde Frames und damit gegen Clickjacking hinzu. Dieser dokumentierte Standard bleibt aktiv. Eine Deaktivierung ist nur vertretbar, wenn eine konkrete, kontrollierte Einbettung nachweislich nötig ist und das daraus entstehende Risiko separat bewertet wurde.

Das komplette Portaldesign mit Device Access, Benutzerregel, Zertifikat und Abmeldung beschreibt Captive Portal einrichten und testen.

Cipher-String gilt für beide Funktionen

tlsciphers_server legt die angebotenen Cipher für Web Proxy und Captive Portal gemeinsam fest. Eine vermeintliche Proxykorrektur kann dadurch das Portal verändern und umgekehrt. Der von Sophos dokumentierte Standard ist:

HIGH:!RC4:!MD5:!aNULL

Der String wird nicht aus einem Blog oder von einer anderen Plattform kopiert. Unterstützte Cipher hängen von SFOS-Version, TLS-Version, Client und Server ab. Vor einer Änderung werden die vorhandene Ausgabe, der erwartete Cipher-Match und Tests auf beiden Funktionen festgelegt. Scheitert eine Verbindung, sind TLS-Version, Zertifikatskette, Decryption Policy und Client-Trust zuerst getrennt zu prüfen.

Vier Timeouts mit unterschiedlicher Wirkung

Alle vier Zeitwerte akzeptieren laut Sophos Werte von 1 bis 2147483647 Sekunden oder default. Ein technisch zulässiger Extremwert ist noch kein sinnvoller Betriebswert.

client_timeout betrifft bereits etablierte Proxyclients. connect_timeout begrenzt den Versuch, eine Verbindung aufzubauen. response_timeout bestimmt, wie lange der Proxy bei einer neuen Verbindung auf die Antwort wartet. tunnel_timeout gilt für den Aufbau eines HTTPS-Tunnels und liegt im dokumentierten Standard mit 300 Sekunden höher als die drei übrigen Werte mit 60 Sekunden.

set http_proxy client_timeout 60
set http_proxy connect_timeout 60
set http_proxy response_timeout 60
set http_proxy tunnel_timeout 300

Diese Werte sind dokumentierte Standards, keine automatische Reparatur. Bei einem Abbruch wird zuerst ermittelt, in welcher Phase er auftritt und ob Client, Zielserver, Upstream Proxy, WAN-Pfad oder Anwendung selbst den kürzeren Timeout setzt. Eine Erhöhung hilft nur, wenn genau der Sophos-Proxywert die Verbindung beendet. Danach werden gleichzeitig offene Verbindungen und Ressourcenverbrauch beobachtet.

Für den Rollback wird der vorher mit show http_proxy abgelesene Wert explizit wieder gesetzt. default wird nur verwendet, wenn bewusst zum dokumentierten Standard zurückgekehrt werden soll, nicht wenn der frühere Wert unbekannt ist.

Kategorisierung im TLS-Handshake nicht blind abschalten

Mit disable_tls_url_categories on wird die Kategorienabfrage für SSL/TLS-Inspection-Regeln deaktiviert. Während des TLS-Handshakes gilt der Traffic dann als unkategorisiert. In dieser Phase können nur SSL/TLS-Inspection-Regeln mit Categories and websites: Any matchen. Auch die Web Policy kann während des Handshakes anders entscheiden.

Die Einstellung verändert weder die URL-Kategorisierung normaler HTTP-Requests noch die spätere Kategorisierung bereits entschlüsselter HTTPS-Inhalte. Gerade deshalb kann ein einfacher Webseitenaufruf nach der Änderung erfolgreich wirken, während Regelwahl und Schutzwirkung bereits anders sind.

Vor dem Einsatz werden die betroffenen SSL/TLS-Inspection-Regeln, Kategoriebedingungen, Websites-Matches und das gewünschte Verhalten für unkategorisierten Traffic geprüft. Danach müssen ein erlaubtes, ein blockiertes und ein nicht kategorisierbares Ziel die erwarteten Regeln treffen. Wie Kategorien und Policy-Aktionen zusammenwirken, erklärt Web Protection auf Sophos Firewall.

Nicht-HTTP-Traffic nicht durch den Proxy drücken

relay_invalid_http_traffic on lässt Nicht-HTTP-Traffic über die normalerweise für HTTP und HTTPS verwendeten Ports 80 und 443 weiterleiten. Das kann ein einzelnes Legacy-Protokoll scheinbar reparieren, vergrössert aber den Proxyweg und erschwert die Sicherheitsbewertung.

Sophos empfiehlt stattdessen einen Proxy-Bypass für die konkrete Anwendung. Dieser Bypass wird nach Quelle, Ziel und benötigtem Dienst so eng wie möglich geplant und mit einer normalen Firewall- sowie gegebenenfalls SSL/TLS-Inspection-Regel abgesichert. Der globale Relay-Schalter bleibt im Regelfall off.

Core Dump und Debug nur für die Diagnose

core_dump on lässt beim Absturz des Proxyprozesses einen Core Dump erzeugen. Das kann Sophos Support bei einer reproduzierbaren Prozessstörung helfen, ist aber kein Health Check und keine Performanceoption. Ein Core Dump kann sensible Prozessdaten enthalten und Speicherplatz belegen.

Die Funktion wird nur für ein konkretes Support- oder Diagnosefenster verwendet. Vorher werden freier Speicher, Reproduktionsschritte und der sichere Übergabepfad geklärt. Nach dem Test wird der vorherige Wert wiederhergestellt und geprüft, ob erzeugte Dateien gemäss Supportanweisung gesichert oder bereinigt werden müssen.

Änderung abnehmen und zurückrollen

Die Prüfung verwendet vor und nach der Änderung dieselbe Quelle, dasselbe Ziel und eine neue Verbindung. Bei einer globalen TLS- oder Cipher-Änderung werden mindestens ein Direct-Proxy-Request und ein Captive-Portal-Login getestet. Bei einem Timeout zählt die betroffene Phase, bei einem Proxy-Loop die exakte Logmeldung und bei der Kategorisierung die tatsächlich verwendete SSL/TLS-Inspection-Regel.

Im Log Viewer werden Zeit, Client, Web Policy und Rule ID festgehalten. Falls die Regelwahl unklar bleibt, verbindet Sophos Firewall-Regel sauber testen Policy Test, Log Viewer und Packet Capture.

Der Rollback verwendet den zuvor dokumentierten Wert:

set http_proxy <parameter> <vorheriger-wert>
show http_proxy

Danach wird ein neuer Testflow erzeugt. Dass show http_proxy wieder den alten Wert zeigt, bestätigt nur die Konfiguration. Erst der reale Proxy- beziehungsweise Portaltest bestätigt den wiederhergestellten Betrieb.

Betriebscheckliste

• Vollständige Ausgabe von show http_proxy, SFOS-Build, Zeitpunkt und verantwortliche Person dokumentiert.
• Betroffene Funktion und genau ein Parameter eingegrenzt.
• Wirkung auf Web Proxy, Captive Portal, TLS Inspection und Web Policy bewertet.
• Vorheriger Wert als ausführbarer Rollback-Befehl vorbereitet.
• Positiv-, Negativ- und unbeteiligter Kontrolltest festgelegt.
• Debug und Core Dump nur zeitlich begrenzt verwendet.
• Nach Änderung und nach Rollback jeweils eine neue Verbindung getestet.
• Temporäre Legacy-Ausnahme mit Owner und Ablaufdatum versehen.

FAQ