Im ersten Teil ist die Einstellung des Proxy Server am Client, mittels netsh Kommando bei Windows Vista /Windows 7 und mittels proxycfg bei Windows XP, besprochen worden. Diese Einstellungen werden hier jedoch nicht benötigt, da der Proxy Server transparent laufen soll. Daher kann man diese ggf. zurücksetzen, wenn man diese Einstellungen schon vorgenommen hat.

Zurücksetzen der Proxy Settings mit "netsh winhttp reset proxy"

Was bedeutet transparent ?

Transparent bedeutet in diesem Fall: Es ist für den Client-Rechner, bzw. den Absender der Netzwerk-Pakete nicht ersichtlich, dass die Kommunikation über eine Proxy-Server-Software erfolgt. Es erscheint ihm, als ob er direkt mit dem Zielserver kommuniziert. Nur im Falle das diverse Filterlisten greifen oder eine Seite nicht gefunden werden kann, erfolgt eine Fehlermeldung bzw. die Umleitung auf eine Fehlerseite.

Diese Vorgehensweise hat enorme Vorteile, wenn man es mit einer großen Anzahl von Client-Rechnern zu tun hat, wie z.B. bei einem Internet Service Provider, da die Konfiguration der Proxy-Einstellungen bei jedem einzelnen Client entfällt. Aber auch bei kleinen Installationen spart man sich in diesem Fall damit viel Arbeit. Durch die Eliminierung einer Fehlerquelle, kombiniert mit der Nutzung von automatischen Anmeldungverfahren, erhöht man damit zusätzlich die Akzeptanz beim Netzwerk-Nutzer.

Transparenz ist für SSL-Verbindungen nicht akzeptabel

Transparent Interception ist für SSL-Verbindungen nicht akzeptabel, da die Sicherheit bei SSL auf der Annahme beruht, das beide Partner direkt über einen verschlüsselten Kanal verbunden sind, ohne Unterbrechung durch Dritte. Wäre ein transparenter Proxy für SSL verfügbar, so könnte man von einer in Software implementierten Man-in-theMiddle-Attacke sprechen.

Ist sich der Client darüber im Klaren, dass er mit einem Proxy kommuniziert, so umgeht er dieses Problem, indem er mittels CONNECT, wie bei automatischen Windows Update, den Proxy auffordert, einen Tunnel zu öffnen. Durch diesen Tunnel werden die Netzwerkpakete nur hindurch geleitet, nicht jedoch bearbeitet. Somit ist in diesem Fall die Sicherheit gewährleistet.

Setup- bekannte Proxy-Einstellungen am Client

Technischer Vorgang

Wichtigste Voraussetzung: Die Proxy-Software muss den transparenten Modus beherrschen, ansonsten führt kein Weg an der Konfiguration der Proxy-Einstellungen auf der Client-Seite vorbei. Das gilt jedoch nur für den Fall, dass man ein transparentes System einsetzen möchte. Squid, als eines der am weitesten verbreiteten Systeme, beherrscht den transparenten Modus sehr gut.

Eine Beschreibung des Vorganges bei transparenten Proxies: Wird von einem Client im Netzwerk ein Paket mit dem Ziel Port 80 verschickt, dann wandert es zum Standard-Gateway. Bereits dort, oder aber spätestens an der nächsten Firewall, wird das Paket mittels Port-Weiterleitung an den zuständigen Proxy-Server umgeleitet. Der Proxy-Server versucht die angeforderte Seite aus seinem Cache auszuliefern. Wird sie dort nicht gefunden oder ist bereits veraltet, löst der Proxy-Server den Namen der Zielseite auf, holt die angefragte Seite, wenn sie gefunden werden kann, und liefert sie an den Anfragenden zurück.

Pakete an den Port 443 werden nicht abgefangen und an den Proxy umgeleitet, sondern mittels NAT auf eine aus dem Internet erreichbare IP-Adresse umgelegt. Auf diesem Wege hat man eine sichere direkte Verbindung für SSL und muss den Aufbau seiner Infrastruktur trotzdem nicht preisgeben.

Setup mit Transparent Interception

Für eine Firewall- oder Paketfilter-Software muss nur eine einfache Portweiterleitung auf den Kommunikationsport des Proxys eingerichtet werden. Dabei ist zu beachten, dass die Filtersoftware stateful arbeiten muss, d.h. ihr muss bekannt sein, das eine Verbindungsaufnahme erfolgt ist. Als Beispiel für Software, die eben das gut beherrscht, wären hier iptables (Linux) bzw. ipfilter (Solaris/openBSD/FreeBSD) zu nennen.

Mit dem ipfilter von Darren Reed, welches z.B. seit Solaris 10 zum Standardumfang des Betriebssystems gehört, sieht die Weiterleitung bei einem Solaris Host (die in der /etc/ipf/ipnat.conf vorgenommen wird ) z.B. wie folgt aus:

rdr eri0 0.0.0.0/0 port 80 -> 127.0.0.1 port 3128

Alle Pakete mit dem Zielport 80 mit allen möglichen Zielrechnern, die am Netzwerkinterface eri0 hereinkommen, werden an den Port 3128 an localhost

Das normale NAT-Mapping von ipfilter ist hier ausreichend und schliesst die SSL-Ports mit ein: