(Die Seite wurde neu angelegt: „{{Archivhinweis|UTM/APP/HTTP Proxy-Transparenter Modus|pre=12.6.0}} {{Set_lang}} {{#vardefine:headerIcon|spicon-utm}} {{var | display | HTTP-Proxy Transparenter Modus | HTTP proxy transparent mode }} {{var | head | Tranparenter Modus für den HTTP-Proxy der UTM | Transparent mode for the http-proxy of the UTM }} {{var | Anwendungen | Anwendungen | Applications }} {{var | Transparenter Modus | Transparenter Modus | Transparent Mode }} {{v…“) |
K (Textersetzung - „sptable2 spezial“ durch „sptable2 Paketfilter“) |
||
Zeile 359: | Zeile 359: | ||
{{#var:Portfilterregeln--desc}}<br> | {{#var:Portfilterregeln--desc}}<br> | ||
{| class="Einrücken sptable2 | {| class="Einrücken sptable2 Paketfilter pd5 tr--bc__white zh1" | ||
|- class="bold small no1cell" | |- class="bold small no1cell" | ||
| class="Leerzeile bc__default" | || ||<nowiki>#</nowiki> || style="min-width:12em;"| {{#var:Quelle}} || style="min-width:12em;"| {{#var:Ziel}} || style="min-width:12em;"| {{#var:Dienst}} || style="min-width:6em;"| NAT || {{#var:Aktion}} || {{#var:Aktiv}} ||style="min-width:5em;"| | | class="Leerzeile bc__default" | || ||<nowiki>#</nowiki> || style="min-width:12em;"| {{#var:Quelle}} || style="min-width:12em;"| {{#var:Ziel}} || style="min-width:12em;"| {{#var:Dienst}} || style="min-width:6em;"| NAT || {{#var:Aktion}} || {{#var:Aktiv}} ||style="min-width:5em;"| |
Aktuelle Version vom 29. Mai 2024, 11:48 Uhr
notempty
- Layoutanpassung
- Fehlerursache bei Host header forgery detected
- Die SNI-Validierung ist deaktivierbar
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.
Konfiguration
Zertifikat
SSL-Interception
Konfiguration unter SSL-Interception
Beschriftung | Wert | Beschreibung | |
---|---|---|---|
SSL-Interception: | Ein | Aktiviert die SSL-Interception | |
Webfilter basiert: | Nein | Bei Aktivierung werden lediglich vom Webfilter blockierte Verbindungen abgefangen. Dadurch wird das Problem umgangen, daß es Seiten gibt, die ein Unterbrechen der Verschlüsselung nicht tolerieren (z.B. Banking-Software), ohne das man dafür extra eine Ausnahme definieren muss. | |
SNI validieren Nur verfügbar wenn Webfilter basiert aktiv |
Nein | Bei Aktivierung Ja wird eine sich ggf. im ClientHello des TLS-Handshake befindliche SNI geprüft. Dabei wird der enthaltene Hostname aufgelöst und die Adressen im Ergebnis mit der Zieladresse des abgefangenen Requests abgeglichen. | |
SNI in den Ausnahmen validieren:notempty Neu ab v12.5.2 Nur verfügbar, wenn Webfilter basiert nicht aktiv ist |
Nein | Wendet die Server Name Indication Validierung nur auf aktivierte Ja Ausnahmen für SSL-Interception an | |
Nicht erkannte Protokolle erlauben: | Ja | Wenn dieser Schalter deaktiviert ist, werden nicht erkannte Protokolle blockiert | |
CA-Zertifikat: | Hier muss eine CA ausgewählt werden, die die Verbindung nach dem entschlüsseln (und scannen) wieder verschlüsseln kann. Der Public-Key der CA muss auf allen Client Rechnern, die SSL-Interception nutzen sollen, installiert werden. Herunterladen kann hier direkt mit ⬇Public-Key herunterladen erfolgen. | ||
Der Public-Key sollte auf den Clients, die die SSL-Interception nutzen sollen installiert werden, um Zertifikatsfehler zu vermeiden | |||
Zertifikatsverifizierung: | Aus | Sollte unbedingt aktiviert werden Damit überprüft der HTTP-Proxy, ob das Zertifikat der aufgerufenen Seite vertrauenswürdig ist. Da der Browser nur noch das lokale Zertifikat sieht, ist eine Überprüfung durch den Browser nicht mehr möglich. | |
Ausnahmen für SSL-Interception | Ein | Es besteht die Möglichkeit Ausnahmen im Format der Regular Expressions zu definieren. Da hier aber nur https ankommen kann, wird hier, anders als bei dem Virenscanner, nicht auf Protokolle gefiltert. Mit werden neue Ausnahmen hinzu gefügt. Eine Ausnahme für www.securepoint.de würde also lauten:
.*\.securepoint\.de" | |
Ausnahmen für Zertifikatsverifizierung | Aus | Hier können Ausnahmen für die Zertifikatsverifizierung im Regex-Format hinzugefügt werden. |
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.
Transparenter Modus
Aktivierung mit Transparenter Modus Ein
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 eine weitere Regel hinzugefügt.
Beschriftung | Wert | Beschreibung | |
---|---|---|---|
Protokoll | Protokoll, das gescannt werden soll | ||
Typ | 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: | Quell- Netzwerkobjekte Reiter Als Quelle muss das Netzwerk aus dem die Anfragen kommen, z.B. internal-network. | , angelegt unter ||
Ziel: | Ziel-Netzwerkobjekt in dem die Webserver stehen die angesprochen werden sollen, in diesem Beispiel internet. |
Ein Klick auf
Ein weiterer Klick auf im HTTP-Proxy Fenster sorgt für eine Aktualisierung der Regeln.
Portfilterregeln
Da nun sowohl HTTP mit Port 80 als auch HTTPS mit Port 443 über den Proxy umgeleitet werden, muss gewährleistet sein, dass die Namensauflösung erfolgen kann.
Sofern die UTM als Nameserver bei den Clients eingetragen ist, wird also eine Regel benötigt die DNS aus den lokalen (privaten) Netzwerken auf die dazugehörige Netzwerkschnittstelle erlaubt.
In der Werkseinstellung existiert schon eine entsprechende Regel mit der Dienstgruppe Proxy. Diese enthält auch den Nameserver Port 53 für UDP und TCP.
Abschließend sollte also noch im Memü
# | Quelle: | Ziel: | Dienst | NAT | Aktion | Aktiv | |||
Portfilterregel 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ü
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.
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 Reiter 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.