Re: Interaktive Firewall für transparenten Proxy (part. solved)
Am Dienstag 03 Juni 2008 17:39:49 schrieb M. Houdek:
> Hallo,
>
> Am Dienstag 03 Juni 2008 17:16:39 schrieb M. Houdek:
> > [Problembeschreibung in der ersten Mail]
> >
> > 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.
>
> Nachtrag:
> Mir scheint, dass der Browser (zumindest Epiphany ;-) die
> Verbindungsanfrage nach kurzer Zeit automatisch wiederholt. Verhalten sich
> alle Browser so? Außerdem: Es könnte ja auch statt des erwarteten
> SSL-Verbindungsaufbaus eine HTML-Seite zurück geschickt werden, die einfach
> wieder auf das ursprüngliche Ziel weiterleitet. Vorausgesetzt, der Browser
> reagiert in diesem Zustand (SSL-Verbindungsaufbau) auf eine statt dessen
> zurückkommende HTML-Seite. Aber das lässt sich ja schnell testen.
An einer Lösung mit interaktivem iptables arbeiten wir noch. Da iptables
selbst bei einem eingehenden Paket keine andere Aktion nach außen ausführen
kann als einen Log-Record zu schreiben, sind wir dabei, dies auszuwerten.
Problematisch ist dabei allerdings auch, dass wir den Aufbau eines Paketes zu
Initialisierung einer HTTPS-Verbindung immer noch nicht ganz verstanden
haben. Manchmal ist der Ziel-Domainname enthalten, manchmal nur die
zugehörige IP (was natürlich für einen Domaincheck am Proxy unbrauchbar ist).
Bis dahin verwenden wir eine andere Lösung (nicht schön, aber funktional):
Transproxy läuft nach wie vor für HTTP-Anfragen und forwarded an den Squid im
Gateway. Das wird auch so bleiben.
Alle anderen Verbindungen (HTTPS, FTP, SSH, ...) werden prinzipiell erst
einmal durch iptables aus dem LAN nach außen geblockt.
Jede DNS-Anfrage wird von iptables umgeleitet auf ein Socket eines
Python-Scripts, das die Domain am Proxy gecheckt. Ist der Fehlercode im
zurückgegebenen HTTP-Header 403, so bedeutet dies, dass der Proxy diese
Domain blockt. Das Python-Script gibt dann die IP einer lokalen Fehlerseite
zurück, die auf die Sperre hinweist. Andernfalls startet das Script eine
eigene DNS-Anfrage und gibt die aufgelöste IP an den Client zurück.
Gleichzeitig wird für eine bestimmte Zeit das Routing aus dem LAN an diese
Domain für ausgewählte Protokolle über iptables erlaubt.
Außerdem wird die Domain in eine Whitelist geschrieben, um bei erneuten
Anfragen die Antwortzeit zu verkürzen. Die Whitelist arbeitet als FIFO-Stack,
eine ideale Länge müssen wir nich ermitteln. Einige Domains werden permanent
in der Whitelist geführt (lokale Domains und Suchmaschinen z.B.).
Das Script ist noch nicht ganz ausgefeilt, aber das Prinzip funktioniert ganz
gut (bis auf die Wartezeiten). Vielleicht bleibt das Provisorium auch ... ;-)
Nachteilig ist vor allem, dass die Wartezeiten für die "geprüfte"
DNS-Auflösung für _alle_ Verbindungen relativ hoch ist, wenn die Domain nicht
in der Whitelist steht.
--
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: