UTM/APP/HTTP Proxy-Transparenter Modus

---

Tranparenter Modus für den HTTP-Proxy der UTM

Letzte Anpassung: 12.2

Neu:

• Layoutanpassung
• Fehlerursache bei Host header forgery detected

notempty

Dieser Artikel bezieht sich auf eine Resellerpreview

11.7

Funktionsweise des transparenten Proxys

Der transparente Proxy sorgt dafür, dass Webseitenaufrufe auch ohne Einstellungen im Browser über den HTTP-Proxy geleitet werden, so dass der Virenscanner und der Webfilter auf diese Verbindungen angewendet werden können.

Um auch SSL-Verschlüsselte Verbindungen auf Viren und Schadsoftware überprüfen zu können, muss sich der Proxy als Client gegenüber dem Webserver im Internet ausgeben, so dass die Daten schon auf der Firewall entschlüsselt werden können.
Diese sollen anschließend natürlich wieder verschlüsselt an den eigentlichen Client im internen Netzwerk weitergeleitet werden.
Um dieses zu erreichen wird das Feature SSL-Interception genutzt.

Die Regex-Ausnahmen gelten nicht für den transparenten Modus!

Konfiguration

Zertifikat

Für die SSL-verschlüsselte Übertragung zum Client wird eine CA benötigt.

[[Datei: |hochkant=2|mini| ]] [[Datei: |hochkant=0.85|mini| ]]

SSL-Interception

SSL-Interception

Konfiguration unter Anwendungen HTTP-Proxy  Bereich SSL-Interception

Beschriftung	Wert	Beschreibung
SSL-Interception:	Ein
	Nein
	Ein
	CA-SSL-Interception
	Aus
'	Ein
'	Aus

Zertifikat dem Browser hinzufügen

Dazu wird der öffentliche Teil des CA über den Button heruntergeladen.
Entweder dadurch, dass sich von jedem einzelnen Client auf der UTM einloggen um auf diesen das CA zu speichern oder es wird einmal heruntergeladen und auf einem USB-Stick oder einem Netzwerkspeicher abgelegt. Anschließend wird über diesen Weg dem Browser das Zertifikat hinzugefügt.

Zertifikatsverwaltung
1. In den Einstellungen des Browser befindet sich die Zertifikatsverwaltung

Zertifizierungsstellen
2. Im Zertifikat-Manager unter Zertifizierungsstellen wird das CA Importiert

Zertifikat für Websites
3. Das heruntergeladene CA wird aus dem entsprechenden Verzeichnis ausgewählt

Zertifizierungsstellen mit CA
4. Bei der Frage ob dem CA als Zertifizierungsstelle vertraut werden soll, wird die Zeile "Diesem Zertifikat zur Identifizierung von Websites vertrauen" markiert.
5. Abschließend auf OK klicken.

Transparenter Modus

Transparenter Modus

Transpatenter Modus aktiviert

Aktivierung unter Anwendungen HTTP-Proxy  Bereich Transparenter Modus mit Transparenter ModusEin

HTTPS-Regel anlegen

In der Standard Einstellung ist der transparente Modus für das HTTP Protokoll über Port 80 schon aktiviert.
Um diesen auch für das HTTPS Protokoll und Port 443 einzurichten, wird durch einen Klick auf die Schaltfläche Transparente Regel hinzufügen eine weitere Regel hinzugefügt.

Beschriftung	Wert	Beschreibung	Transparente Regel für HTTPS hinzufügen
Protokoll	HTTPS	Protokoll, das gescannt werden soll
Typ	Include Exclude	Bestimmt ob der Transparente Modus für die folgenden Netzwerkgruppen angewendet werden soll, oder nicht. Soll ein bestimmtes Netzwerkobjekt oder eine Netzwerkgruppe als Quelle oder Ziel vom Transparenten Modus ausgenommen werden, kann eine Exclude-Regel vor der allgemeinen Include-Regel eine Ausnahme definieren.
Quelle	Newtzwerkobjekt	Quell-Netzwerkobjekt, angelegt unter Firewall Netzwerkobjekte Als Quelle muss das Netzwerk aus dem die Anfragen kommen, z.B. internal-network.
Ziel	internet	Ziel-Netzwerkobjekt in dem die Webserver stehen die angesprochen werden sollen, in diesem Beispiel internet.

Ein Klick auf Speichern und schließen speichert die neue Regel und schließt den Dialog.
Ein weiterer Klick auf Speichern im HTTP-Proxy Fenster sorgt für eine Aktualisierung der Regeln.

		#	Quelle	Ziel	Dienst	NAT	Aktion	Aktiv
Paketfilterregel für Zugriff auf DNS-Auflösung		2	internal-network	internal-interface	proxy		Accept	Ein

Beispiele für Ausnahmen für Windows-Updateserver

Weitere Beispiele zur Einrichtung der SSL-Interception, Authentifizierungsausnahmen, Virenscanner und Webfilter bezüglich Windows Updates gibt es im Knowledge Base Artikel Windows Updates mit HTTP-Proxy und Webfilter

---

Troubleshooting

---

Situation

• UTM mit aktivem transparenten HTTP-Proxy für HTTP und HTTPS.
• Die SSL-Interception läuft im Modus "Webfilterbasierend".

Fehlermeldung im Browser

ERROR_SSL_PROTOCOL_ERROR

oder

ssl_error_rx_record_too_long

Logmeldung in der UTM

Logmdeldung des Squid (Menü Log ) in der UTM:

2021-09-15T16:50:20.003+02:00|squid|8933|1631717419.981 1 192.0.2.192 NONE/200 0 CONNECT 104.96.47.5:443 - HIER_NONE/- -
2021-09-15T16:50:20.007+02:00|squid|8933|1631717420.007 27 192.0.2.192 NONE_ABORTED/409 12387 CONNECT loadbalancing.ttt-point.de:443 - HIER_NONE/- text/html
2021-09-15T16:50:20.007+02:00|squid|8933|1631717420.007 27 192.0.2.192 NONE_ABORTED/409 12387 CONNECT loadbalancing.ttt-point.de:443 - HIER_NONE/- text/html
2021-09-15T16:50:22.652+02:00|squid|8933|SECURITY ALERT: Host header forgery detected on local=192.0.2.22:443 remote=192.168.175.10:28144 FD 9 flags=33 (local IP does not match any domain IP)
2021-09-15T16:50:22.654+02:00|squid|8933|SECURITY ALERT: on URL: loadbalancing.ttt-point.de:443

---

Bedeutung

• Der Client startet eine TCP-Verbindung zu einem HTTPS-Server
• Die Verbindung wird durch die UTM → Transparenter Proxy abgefangen
• Der HTTP-Proxy (Squid) prüft die Verbindung und analysiert den TLS-Handshake.
• Die gewonnen Informationen wie der SNI werden dabei aufgelöst und mit der ursprünglichen IP-Adresse verglichen
• In diesem Fall stimmen ursprüngliche IP und die aufgelöste IP für den SNI (Hostnamen) nicht überein und werden daher durch den HTTP-Proxy blockiert und es kommt zu oben stehender Fehlermeldung

Ursache

Dieses Verhalten ist bei Hostnamen mit einer intensiven Lastenverteilung zu beobachten.
Wenn der Anbieter in kurzer Zeit unterschiedliche Antworten auf DNS-Anfragen gibt, können sich die Ergebnisse in der DNS-Auflösung zwischen Client und UTM unterscheiden.

Dieses Verhalten kann hervorgerufen werden durch:

• unterschiedliche DNS-Server auf Client und UTM
• Hostnamen, die mit einer sehr kleinen TTL durch intensive Lastenverteilung, von UTM und Client unterschiedlich aufgelöst werden.
• Nutzung von DNS-Servern an unterschiedlichen geografischen Standorten.
  Dabei kann über den entfernten Standort für die aufgerufenen Hostnamen eine andere IP-Adresse zurückgegeben werden als am lokalen Standort der UTM. (Geographic DNS Routing)

Lösung

• Best Practice:
  Auf dem Client wird die UTM als globaler Proxy-Server und ggf. für jede Anwendung als Proxy-Server eingetragen.

• Workaround:
  Auf Client und UTM werden die gleichen DNS-Server eingetragen.

Dieses Vorgehen minimiert die Fehlerrate, kann das Problem aber vor allem bei Servern, die Loadbalancing mit sehr kurzen TTLs-betreiben nicht sicher verhindern.
Zusätzlich muss darauf geachtet werden, daß auch keine DNS-Server verwendet werden, die selber bereits über Geographic DNS Routing angesprochen werden.
Die Google-Server z.B. unterscheiden sich trotz identischer IP-Adresse je nach Region, von der aus sie aufgerufen werden!

• Einfach, aber unsicher:
  Unter Anwendungen HTTP-Proxy  Bereich SSL-Interception die Option SNI validieren: Nein deaktivieren.
  Ohne SNI Validierung können Clients die SNI beliebig manipulieren, um den Webfilter zu passieren. Diese Einstellung sollte nur als eine letzte Möglichkeit betrachtet werden, wenn es unmöglich scheint, die DNS-Einstellungen zwischen Clients des HTTP-Proxy und der UTM zu vereinheitlichen.