Interaktive Firewall für transparenten Proxy
Moin,
ich bin auf der Suche nach einer Lösung für eine "interaktive Firewall", um
auch HTTPS durch einen transparenten Proxy zu bekommen. Die Situation ist
nicht ganz einfach, aber sicherlich interessant, da auch andere vor einem
ähnlichen Problem stehen werden. Vielleicht gibt es auch schon eine einfache
Lösung und wir sehen den Wald vor Bäumen nicht ;-)
Kurz zum Problem (Vorsicht, ein wenig länger):
LAN ----> "interaktive FW/Transproxy" ---> Gateway mit Squid ---> Internet
^^^^^^^^^^^^^^^^^^^^^^^^^^^
soll neu dazwischen, weil: ...
Das Gateway mit dem Squid wird von einer Fremdfirma administriert, die auch
die Squid-Filter pflegt und dafür letztlich auch gerade steht. Das soll sie
auch weiterhin, dafür wird sie bezahlt.
Der Squid läuft nicht transparent, kann daher also auch HTTPS weiterleiten, da
dazu ja der Browser eine HTTP-Verbindung zum Squid aufbaut, durch die dann
die SSL-Verbindung getunnelt wird. Trotzdem prüft aber der Squid anhand
seiner Adressfilter das Ziel und verweigert ggf. auch den Verbindungsaufbau.
Soweit ist alles klar.
Da im LAN auch zunehmend mobile Geräte eingesetzt werden, ist das Eintragen
und wieder Löschen des Proxys für die meisten User zu umständlich (bzw. z.T.
auch nicht machbar -> Kinder).
Eine automatische Proxy-Konfiguration wäre eine Alternative, wirft aber auch
Probleme auf, da auch hier der Browser entsprechend eingerichtet sein muss,
damit er danach sucht.
Die eleganteste Lösung ist daher IMHO ein transparenter Proxy.
Was bisher läuft:
Vor dem Fremd-Gateway läuft ein eigenes Gateway, dessen IP per DHCP als neues
Default-Gateway an die Clients geht.
Auf diesem eigenen Gateway läuft transproxy, der eingehenden HTTP-Pakete von
iptables redirektet bekommt und als Proxy-Anfrage an den nicht transparenten
Squid schickt. Klappt bestens. :-) Aber eben nur mit HTTP :-(
HTTPS wird derzeit am externen Gateway vorbei geleitet (das interne Gateway
darf als einziger Host im LAN mit einigen Protokollen auch direkt ins
Internet). Das hat aber den Nachteil, dass natürlich der Adressfilter des
Squid auch nicht mehr greift.
Versuche, die HTTPS-Pakete vom Browser ebenfalls zu manipulieren (ala
transproxy), um sie dann dem Squid unterzuschieben, mussten scheiten, da der
Browser die Manipulation am Header erkannte. Zumindest scheint es bei weitem
nicht so trivial wie bei HTTP zu sein.
Ein "Man in the Middle"-Szenario scheidet auch aus, da die Rechenleistung des
eigenen Gateways nur begrenzt ist und es letztlich auch rechtlich nicht ganz
sauber ist.
Unser Lösungsansatz (bisher nur gedanklich):
Das interne Gateway schickt bei einem eingehenden HTTPS-Paket für eine neue
Verbindung (iptables: --status NEW) eine entsprechende eigene HTTPS-Anfrage
durch den Squid. Kommt ein Fehler zurück, wird der Verbindungsaufbau
abgelehnt. Klappt die Verbindung, soll die Firewall das Paket am externen
Squid vorbei direkt ins Internet schicken. Für alle folgenden Pakete dieser
Verbindung ist die eigene Firewall eh offen.
Nun die Frage: Wie kann man so ein interaktives Verhalten von iptables
realisieren?
Zur Not könnte man bei erfolgreicher HTTPS-Test-Verbindung auch die Firewall
für eine bestimmte Zeit zu diesem Ziel öffnen und eine (Fehler-)Meldung an
den Browser zurückschicken, die dazu auffordert, die Seite erneut aufzurufen
(F5 drücken). Zwar nicht ganz elegant, aber eine Alternative.
Oder gibt es evtl. andere Lösungen?
--
Gruß
MaxX
Bitte beachten: Diese Mailadresse nimmt nur Listenmails entgegen.
Für PM bitte den Empfänger gegen den Namen in der Sig tauschen.
Reply to: