Webproxys mit Caching-Funktion prahlen mit ihrer Gedächtnisleistung: Statt bei wiederholten Anfragen beim Originalserver zu spicken, liefern sie den Inhalt Zeit und Geld sparend selber aus. Die cleversten Vertreter der Gattung entfernen nebenbei gefährliche Inhalte und arbeiten als unauffällige Bridge.

Wenn viele Surfer im lokalen Netz dieselbe Webseite anfordern, dann kostet das unnötig Bandbreite und – je nach Abrechnungsmodus – Geld. Gegen die Verschwendung hilft ein Caching-Proxy, der alle aufgerufenen Seiten speichert und sie bei Bedarf an Clients ausliefert, ohne erneut externe Bandbreite zu verbrauchen. Die Nutzer profitieren vom flotteren Zugriff auf Webseiten, der Netzbetreiber schont seinen Uplink. Zum Beispiel bedient der Proxy der Universität der Bundeswehr in München satte 40 Prozent aller Webzugriffe aus seinem Cache – und das, obwohl niemand die Studenten und Mitarbeiter dazu zwingt, den Proxy zu verwenden.

Ein Caching-HTTP-Proxy wie Squid [1] läuft auf Schicht 7 des OSI-Modells (Open Systems Interconnection), er versteht also das Anwendungsprotokoll und erkennt dessen Nutzdaten. Folglich ist er in der Lage, den Inhalt der Seite zu prüfen, also als Contentfilter zu arbeiten. Je nach Zielrichtung blockiert er den Zugang zu unerwünschten Seiten, etwa Jugendgefährdendes in Schulnetzen, oder er hält Malware aus Unternehmensnetzen fern. Gerade in Netzen mit Windows-Arbeitsplatzrechnern, auf denen der Internet Explorer zum Einsatz kommt, ist ein solcher Schutz als Verteidigungslinie sehr hilfreich.

Lästige Änderungen

Wer einen herkömmlichen Proxy in seinem Netzwerk installieren will, hat viel Konfigurationsarbeit vor sich: Den Proxy in jedem Browser eintragen oder die Browser auf Proxy-Autokonfiguration umstellen sowie die Firewall anpassen, um HTTP-Zugriffe am Proxy vorbei zu verbieten und damit den Einsatz des Proxy zu erzwingen. Oder er installiert einen transparenten Proxy, bei dem eine Firewallregel den gesamten ausgehenden HTTP-Verkehr auf den Proxy umleitet. Aber auch hier ist es notwendig, die Firewall passend zu konfigurieren.

Viel eleganter wäre es, den Proxy-Rechner einfach in das Netzwerkkabel hinter den letzten Switch und vor den Router zu hängen, ohne eine Firewall, einen Browser oder einen Router anpassen zu müssen. Geräte mit dieser Eigenschaft heißen üblicherweise Bridge oder Switch. Ihre originäre Aufgabe ist zwar, Netzwerkverkehr anhand seiner MAC-Adressen zu sortieren und damit das Netz zu segmentieren, aber moderne Linux-Kernel erlauben es bereits, die Bridge auch zu einer unsichtbaren Firewall aufzurüsten. Sie filtert stateful auf der TCP-Schicht [2].

Bequem und praktisch

Der logisch nächste Schritt besteht darin, auch einen Filter auf der Anwendungsebene des OSI-Schichtenmodells auf einer Bridge zu betreiben (Abbildung 1). Dieses ungleiche Gespann integriert sich nahtlos in ein bestehendes Netzwerk, ohne dass Admins oder Anwender irgend etwas an der Konfiguration von Routern, Clients oder Applikationen ändern müssten.

Abbildung 1: Der Contentfilter ist in diesem Szenario auf einer Bridge installiert (rot). Damit lässt er sich in ein bestehendes Netzwerk einklinken, ohne Neukonfiguration am Router oder an den Clients.

Umgehen lässt sich dieser Proxy nur per Tunnel, etwa über SSH, Stunnel oder OpenVPN. Diese Möglichkeit bleibt aber bei jedem Verfahren [3] und setzt neben einem gewissen Aufwand auch Know-how voraus. Der Tunnelgräber braucht einen Server im Internet, den er als Tunnelendpunkt nutzt, und er muss dort sowie lokal zusätzliche Software installieren. Das ist glücklicherweise vielen Möchtegern-Profis zu aufwändig.

Ein größeres Risiko für die interne IT-Sicherheit stellen per VPN angebundene Rechner von Außendienstmitarbeitern dar, die gleichzeitig noch in einem fremden, ungesicherten Netz hängen. Ganz ähnlich verhält es sich mit dem Notebook des Chefs, der sich abends über das ungesicherte Heimnetz den Freuden und Gefahren im Internet aussetzt.

Ein Filter auf Anwendungsebene ist nur ein weiterer Baustein in einem kompletten Sicherheitspaket, das auch die Schulung der Anwender sowie unternehmensweite Regeln zum Beispiel für die Nutzung von Tunneln beinhalten sollte. Dieser Baustein gehört aber zu den netteren, weil er Bedrohungen filtert, lange bevor sie den Endanwender erreichen und dessen Rechner gefährden.

Grundkonfiguration

Um den Proxy zu installieren, empfiehlt es sich, zunächst ein minimales Linux-System aufzusetzen. Der Rechner braucht dazu zwei Netzwerkkarten, denen das System vorerst keine IP-Adressen zuweisen soll. Da in aller Regel das Neukompilieren des Kernels fällig ist, um Bridging zu aktivieren, und auch Squid und Dansguardian (siehe weiter unten) besser aus den Sourcen übersetzt werden, braucht das System noch die dafür notwendigen Developer-Pakete. Später, also bevor die Bridge in den Produktiveinsatz geht, empfiehlt es sich nicht zuletzt aus Sicherheitsgründen, die Maschine aufzuräumen und unnötige Pakete zu deinstallieren.

Kernfrage

Mit Blick auf ein sicheres System bietet es sich an, einen statischen Kernel ohne Modulsupport zu bauen. Damit ist die Modulschnittstelle, die manche Kernel-Rootkits verwenden, nicht verfügbar. Der Kernel-Bauer muss dann die richtigen Treiber – vor allem für die beiden Netzwerkkarten und den Festplattencontroller – auswählen. Außerdem muss der Kernel Bridging unterstützen (Abbildung 2). Ganz sicherheitsbewusste Admins installieren zusätzlich noch Patches wie GR-Security [4].

Abbildung 2: Ob der Kernel (hier 2.6.17.7) den Bridge-Modus unterstützt, entscheidet die Option »BRIDGE«, zu finden unter »Networking | Networking support | Networking options | 802.1d Ethernet Bridging«.

Wenn das System mit dem neuen Kernel erfolgreich bootet, ist eine Bridge erforderlich: Der Befehl »brctrl addbr br0« fügt ein neues Netzwerkgerät mit dem Namen »br0« hinzu. Da zu einer Bridge zwei Netzwerkkarten gehören, ordnen die folgenden Kommandos die beiden Karten der Bridge zu:

brctrl addif br0 eth0
brctrl addif br0 eth1

Anschließend startet das »ip«-Kommando die beiden Karten sowie die Bridge:

ip link up eth0
ip link up eth1
ip link up br0

Jetzt lässt sich die Bridge schon testen – einfach in das Netzwerk hängen. Sie sollte Datenpakete bei Bedarf durch die Bridge zwischen den beiden Segmenten durchreichen. Eine Netzwerkanalyse mit TCP-Dump [5] bestätigt das im Zweifelsfall. Wer möchte, konfiguriert sich jetzt noch eine Firewall mit »iptables« und dem Physdev-Match oder mit »ebtables«. Wie das geht, beschreibt [2].

Squid installieren

Für den Proxy ist als Erstes Squid zu installieren. Um zum Beispiel den Sourcecode von [1] herunterzuladen, braucht die Bridge eine IP-Adresse und ein Standard-Gateway in der Routingtabelle. Das erledigen die folgenden Befehle:

ifconfig br0 192.0.2.8 netmask 255.255.255.0
route add default gw 192.0.2.1

Danach Squid auspacken und konfigurieren: »./configure –enable-linux-netfilter –disable-ident-lookups«. Dabei aktiviert der erste Parameter die Unterstützung von Linux-Netfilter in Squid. Das ist notwendig, um Squid als transparenten Proxy einzusetzen.

Der zweite deaktiviert die Abfragen bei dem eventuell installierten Ident-Dienst des Clients, den fast alle Firewalls blockieren. Je nach Geschmack empfiehlt sich noch als Parameter »–prefix=/usr/local/squid«, um alles in ein Verzeichnis zu räumen. Der Rest des magischen Dreisatzes kompiliert und installiert Squid: »make && make install«.

Jetzt heißt es, die Konfigurationsdatei von Squid den eigenen Bedürfnissen anzupassen. Mit dem oben genannten Präfix steht »squid.conf« im Verzeichnis »/usr/local/squid/etc/«. Viel Arbeit hat der Admin mit diesem File nicht – eine reine Geschmacksfrage ist der Port, auf dem Squid lauscht. Standardmäßig ist das 3128. Wer das ändern will, trägt in der Squid-Konfiguration Folgendes ein:

http_port 127.0.0.1:65080

Fortan lauscht der Proxy auf 65080. Die Anweisung konfiguriert Squid zudem so, dass der Proxy nur noch an Localhost auf Verbindungen reagiert. Das ist für den später zu ergänzenden Contentfilter wichtig.

Squid unterstützt das Inter Cache Protocol (ICP), mit dem sich die beteiligten Proxys bei Bedarf gegenseitig den Inhalt ihrer Caches zuliefern. Für den vorliegenden Fall ist das überflüssig und schnell deaktiviert: »icp_port 0«. Zusätzlich sorgt ein ACL-Eintrag (Access Control List) dafür, dass wirklich nur Localhost auf Squid zugreifen darf: »http_access allow localhost«.

Contentfilter

Der Proxy läuft noch ohne einen Contentfilter. Hier gibt es die berühmte Qual der Wahl, die sich aber schnell mildert, wenn klar ist, worauf der Filter achten soll. Seine Aufgabe könnte lauten, unsichere Windows-Maschinen vor Malware zu schützen, die über eine HTTP-Antwort den Zielrechner erreicht.

In anderen Umgebungen ist allerdings eher ein Filter gefragt, der den Zugang zu bestimmten Inhalten und unerwünschten Websites blockiert. Zum Beispiel fordern Schulen oft, Seiten mit jugendgefährdenden oder illegalen Inhalten zu sperren. Ob ein solcher Schutz sinnvoll und effektiv ist, kann im vorliegenden Fall offen bleiben – das folgende Beispiel verzichtet auf Zensur und schießt sich stattdessen auf die anerkannt bösartigen Viren ein.

Welcher Virenscanner zum Einsatz kommt, ist erneut Geschmackssache. Einen Anhalt können Tests wie in [6] geben. In einer reinen Open-Source-Umgebung übt ein echter Open-Source-Scanner einen besonderen Charme aus, daher verwendet das Beispiel Clam AV [7]. Die Konfiguration anderer Scanner ist sehr ähnlich, eine andere Auswahl oder gar der Einsatz mehrerer Scanner sollte keine größeren Probleme aufwerfen.

Es gibt mehrere Techniken, um einen Contentfilter in Squid einzuklinken. Zum einen das Redirector-Interface. An dieses Skript übergibt Squid die herunterzuladende URL inklusive aller Parameter. Je nach Rückgabewert des Skripts holt sich Squid dann das Dokument, auf das die URL verweist. Das ist in den Fällen sinnvoll, wenn der Filter nur die URL untersucht und nicht das Dokument, auf das sie verweist.

Redirector mit Hindernissen

Im Fall eines Virenscanners, für den »SquidClamAVRedirector« eine Schnittstelle bereitstellt, ist es aber ungünstig: Zuerst lädt der Redirector die URL unter Umgehung von Squid herunter, analysiert den Inhalt und gibt dann Squid grünes Licht, die Seite selbst anzufordern (Abbildung 3). Das heißt, jeder Download erzeugt doppelten Datentransfer – genau dies sollte ein Caching-Proxy eigentlich verhindern.

Abbildung 3: Beim Virenscan mit dem Clam-AV-Redirector fordert der Client eine URL an 1. Der Proxy übergibt die Adresse an den Redirector 2, der den Inhalt holt (3, 4), untersucht und Squid grünes Licht gibt 5. Danach holt Squid erneut die URL (6 bis 8) und verschwendet somit Bandbreite.

Mit etwas kunstvollem Gebastel lässt sich der Redirector zwar dazu überreden, seinen Download über Squid zu erledigen. Dazu gehört, Squid so einzustellen, dass er Anfragen, die von Localhost kommen, nicht wieder an den »SquidClamAVRedirector« durchreicht und damit eine Endlosschleife erzeugt. Beim transparenten Proxy ist diese Konstruktion aber problematisch, da aus Sicht von Squid alle Anfragen von Localhost kommen. Zusammen mit der aufwändigen Gesamtkonstruktion ist diese Lösung also ungeeignet.

Proxy-Kette

Die Alternative besteht darin, einen dedizierten Contentfilter-Proxy vor oder nach Squid zu schalten. Ein solcher Proxy ist zum Beispiel Dansguardian [8]. Er steht sinnvollerweise zwischen dem Proxy und dem internen Netzwerk (siehe Abbildung 4a), wobei beide Aufgaben auf einem Rechner installiert sein dürfen. Das heißt: Anfragen aus dem internen Netz landen zuerst bei Dansguardian, der sie an Squid weiterleitet, von Squid die Antwort bekommt – wenn vorhanden, dann bereits aus dem Cache – und diese auf Viren, Würmer und anderes Getier überprüft.

Abbildung 4a: Das Gespann aus dem Contentfilter Dansguardian und dem Caching-Proxy Squid sorgt dafür, dass Squid alle Anfragen zwischenspeichern kann und dennoch Dansguardian bei jeder Anfrage die gerade aktuellen Filterregeln anwendet.

Theoretisch wäre auch die umgekehrte Reihenfolge denkbar: Den Malwarefilter-Proxy auf die äußere Seite und den Caching-Proxy nach innen verlagern (Abbildung 4b). Das hätte den Vorteil, dass der Virenscanner nur einmal für jede heruntergeladene Datei arbeiten muss, denn in der oberen Konfiguration schaltet er sich in jeden Seitenzugriff ein, egal ob der aus dem Cache stammt oder vom externen Server. Der Performance-Vorteil geht aber mit einem Sicherheitsnachteil einher. Übersieht der Scanner einen Virus, landet der im Proxy-Cache und ist vor künftiger Enttarnung sicher, selbst wenn ihn der Scanner nach einem Signaturupdate erkennen würde.

Abbildung 4b: Im Unterschied zu Abbildung 4a steht der Contentfilter bei dieser Anordnung in der externen Verbindung. Das erhöht die Performance, weil jedes File nur einmal gescannt wird, ist aber unsicherer, weil neue Virensignaturen keine Chance erhalten, um alte Inhalte im Cache zu prüfen.

Zum Glück nimmt Dansguardian die Entscheidung vorweg: Es gibt nur eine Möglichkeit, dieses Programm zu installieren. Das entbindet den Admin von der schweren Wahl zwischen Performance und Sicherheit. Zudem verwöhnt Dansguardian mit Features jenseits des Malware-Schutzes und filtert auf Wunsch auch unerwünschte Seiten.

Dansguardian installieren

Vor der Installation von Dansguardian muss Clam AV bereits vorhanden sein. Das ist einfach zu erledigen, etwa mit den Binärpaketen, die es auf der Clam-AV-Webseite für fast alle Distributionen gibt. Auch das Kompilieren von Hand erledigt jeder geübte Admin schnell mit dem magischen Dreisatz »./configure && make && make install«.

Bei der Dansguardian-Installation muss dessen Configure-Skript per Aufrufoption erfahren, dass es die Unterstützung für Clam AV einkompilieren soll. Wer will, schiebt das übersetzte Paket zudem übersichtlich in ein eigenes Verzeichnis. Damit erledigt sich die Installation mit den folgenden drei Kommandos:

./configure --enable-clamav --prefix=/usr/local/dansguardian
make
make install

Danach braucht der Contentfilter noch eine passende Konfiguration. Der Eintrag »proxyport=8080« in »dansguardian.conf« lässt den Filter auf Port 8080 lauschen. Zudem muss er wissen, auf welchem Port Squid seine Anfragen erwartet: »filterport=65080«. Anschließend entfernt der Admin in der »contentscanner«-Zeile, die auf Clam AV verweist, die Kommentarzeichen und passt bei Bedarf die Clam-AV-Konfiguration an.

Jetzt fehlt noch eine Fehlermeldung, die Benutzer sehen, wenn sie unerlaubte Inhalte angefordert haben. Am einfachsten ist es, auf einem Intranet-Webserver eine entsprechende Seite bereitzustellen und den Browser im Ernstfall dorthin umzulenken. Alternativ kann eine solche Seite auch von einem externen Server stammen. Eine Beispielseite liefert Dansguardian in »share/dansguardian.pl« mit. Welche Seite zum Zuge kommt, bestimmt im Config-File von Dansguardian die Direktive »accessdeniedaddress«.

Filter einschalten

Noch sieht Dansguardian nichts von den Anfragen der Clients – diese gehen durch die Bridge direkt zum Zielserver. Eine Netfilter-Regel lenkt den eingehenden Traffic auf den Filter um:

iptables -t nat -A PREROUTING -m physdev --physdev-in eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080

Wichtig ist das Physdev-Match. Es sorgt dafür, dass nur Clients auf der Innenseite der Bridge den Proxy benutzen. Sollte keine Firewall die Bridge schützen, wäre es für einen externern Angreifer sehr leicht, den Proxy als Open Proxy zu missbrauchen.

Wenn alles funktioniert, tauchen jetzt alle von innen stammenden Webzugriffe auf das externe Netz in den Logfiles der Proxys auf. Das System ist durch die gewählte Architektur nach innen vollkommen transparent. Nur die Außenseite bemerkt, dass die Anfragen von einem Cache stammen. Der Proxy nutzt für den Abruf der Seite eine neue Verbindung, in der er seine eigene IP-Adresse als Quelle einsetzt. Gegenwärtig arbeiten die Entwickler daran, auch noch diese Spur des ansonsten völlig transparenten Proxy zu verwischen.

Saubere Sache

Mit dem Malwarefilter und Caching-Proxy auf der Bridge ist das interne Netz gegen Viren und Würmer gut geschützt, die sich via HTTP ins interne Netz schummeln wollen. Die Bridge-Lösung glänzt mit ihrem einfachen Deployment: Das fertig konfigurierte Gerät lässt sich jederzeit ins Netzwerk einstöpseln – ohne irgendeine Änderung in der Netzwerkkonfiguration. (fjl)