HTTP-Proxy mit Caching und Contentfilter auf einer 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.