© complize, 123RF

Auf nahezu jeder Webseite hinterlassen Anwender ungefragt Informationen, die sich für Marketingfirmen als wertvoll erweisen. Abhilfe schaffen die richtigen Browsereinstellungen oder eine simple Proxykaskade, die ein ganzes lokales Netz effektiv mit Squid und Privoxy schützt.

Alle Standardbrowser verraten aufgerufenen Webseiten viele Informationen über das eigene System. Dazu gehören nicht nur HTTP-Headervariablen, sondern auch weitere Informationen, die Webmaster mit Flash- oder Javascript-Plugins und -Skripten auslesen können. Diese Daten zu speichern und mit bestehenden Profilen aus Shops oder sozialen Netzwerken zu kombinieren lohnt sich, glaubt man Untersuchungen von Forbes [1] oder den Ergebnissen von Online-Toolkits wie Swipe ([2], [3]).

Sparsam mit Daten

Wer Webseiten-Betreibern nicht so viele Daten überlassen oder etwa unerkannt die Auftritte der Konkurrenz durchstöbern will, muss seine Systeme auf Datensparsamkeit trimmen. Schon die Information, welche URL der Besucher zuletzt aufgerufen hatte, kann dem Server interessante Details offenbaren, vor allem wenn der Benutzer sich vorher in sozialen Netzwerken oder Foren aufhielt. In der Defaultkonfiguration übertragen alle Browser ungefragt die Information über die zuletzt besuchte Webseite im HTTP-Header »HTTP_REFERER« (Abbildung  1, [4]).

Abbildung 1: Diverse Anonymitätstests im Web zeigen eine lange Liste an Informationen, die Webseiten aus dem Browser auslesen können. Neben der Bildschirmauflösung und der aktuellen Fenstergröße findet sich da auch die lokale IP des Clients oder der HTTP-Referrer, der die zuletzt besuchte Website enthält.

Wer sich davor schützen will, sollte diese Daten mit Anonymisierungstools verschleiern. Das erste Ziel ist dabei immer der lokale Browser – und dessen Einstellungen sind leider meist nicht oder nur unzureichend als zentrale Vorgabe für das lokale Netz und alle seine Benutzer möglich. Awareness-Schulungen [5], innerbetriebliche Vereinbarungen und Dokumentationen für Anwender helfen dabei, den eigenen Browser mit Tools und Erweiterungen auf einen weniger gesprächigen Stand zu bringen.

Eine sinnvolle Maßnahme sollte beispielsweise Cookies nur für bestimmte Webseiten erlauben (Whitelist) und sie am Ende jeder Browsersession wieder löschen (keine Ever-Cookies). Werbe- und Flashblocker wie Adblock [6] oder Flashblock [7] gibt es für alle gängigen Browser. Sie sind ausgereift und stabil und bieten dem Anwender interaktiven Zugriff auf zunächst geblockte Inhalte: Flashblock verhindert beispielsweise, dass eine Webseite automatisch Flash-Inhalte lädt und dabei unerwünschte Daten überträgt. White- und Blacklists sind integriert, ebenso lassen sich gewünschte Multimedia-Inhalte mit einem einfachen Mausklick starten (Abbildung  2).

Abbildung 2: Ein Mausklick mehr – aber dafür starten Flash-Anwendungen erst, wenn der User zustimmt, und nur dann dürfen die so ausgewählten Programme Daten ins Web übertragen.

Browser-Addons

Gegen freche Datenabfragen mit Skripten helfen Firefox-Addons wie No  Script [8] oder Better Privacy [9], die sich zwar im Addon-Repository finden, aber nicht alseinfach zu konfigurieren erweisen.

Den Erfolg eines so optimierten Clients kann der Anwender auf Webseiten überprüfen, die aggressiv Informationen aus dem Browser auslesen und sie dann dem Surfer präsentieren. Gurusheaven (Abbildung 1, [10]) wertet alle verfügbaren Informationen inklusive der Browser-Historie und diverser Systemeigenschaften aus, IP-Check [11] die HTML-Header und Javascript-Variablen, während sich Ip.cc [12] den HTTP-Headern und der Qualität eines eventuell zwischengeschalteten Proxys widmet. Ist der richtig konfiguriert, liefert ein Anonymitätstest von http://www.ip.cc]den Vermerk: “Sie verwenden einen hochanonymisierenden (Elite) Proxy” (Abbildung 3).

Abbildung 3: Wer einen stark anonymisierenden Proxy oder eine sichere, auf Datensparsamkeit getrimmte Browserkonfiguration verwendet, bekommt beim Anonymitätstest von IP.cc diese Auskunft.

Elite Proxy

Der Name “Elite Proxy” verweist auf die dunkleren Ecken des Internets ([13], [14]). Anonyme Proxyserver dienen der Warez- und Fraud-Szene zum Verschleiern der ursprünglichen IP-Adresse. Häufig infizieren Angreifer unschuldige PCs mit Proxyservern, so genannten Victim Socks oder Vicsocks.

Die Bezeichnung Elite Proxy stammt aus früheren Zeiten, als Angreifer das Internet nach öffentlich zugänglichen Proxyservern scannten und diese auf ihre Qualität hin prüften. Paradoxerweise waren nicht standardkonforme Proxyserver, die die im Folgenden beschriebenen Header nicht übersandten, besonders beliebt, weshalb sie diesen Namen erhielten. Heute bezeichnen Admins damit Proxyserver, die idealerweise alle Detailinformationen über den User, von dem die Anfrage kam, aus dem Datenstrom entfernen.

Elite Proxys stellen eine der wenigen Möglichkeiten dar, dem kompletten lokalen Netz eine gewisse Anonymität einzuräumen, und helfen als erste Abwehr gegen die unerwünschte Profilbildung. Abbildung 4 zeigt exemplarisch, was ein Webserver ohne und mit der Proxykaskade noch an Daten erhält. Das folgende Beispiel nutzt dafür eine Kombination aus Squid [15] und Privoxy [16].

Abbildung 4: Gegenüber einem normalen Proxy schützt die im Artikel vorgestellte Proxykaskade den Anwender, indem sie deutliche weniger Daten in den Headern an den Webserver überträgt.

HTTP-Header

Um deren Funktionsweise zu verstehen, ist jedoch zunächst ein Blick auf das HTTP-Protokoll und die zu übertragenden Header hilfreich. Tabelle 1 zeigt die für die Profilbildung geeigneten HTTP-Header, die ein Client in der Regel an den Server übermittelt. Wer die Profilbildung erschweren will, sollte diese Header verschleiern.

Tabelle1: HTTP-Header

Doch viele Webseiten verlangen Header wie »HTTP_REFERER« , um korrekt zu funktionieren, oder differenzieren anhand des Benutzeragenten, ob der Client die Webseite besuchen darf, ob der Server die Anfrage abzuweisen hat oder eine an den jeweiligen Browser angepasste Darstellung sendet. Der Header »HTTP _USER_AGENT« verlangt besondere Aufmerksamkeit, weil der Anwender hier eine beliebige Zeichenkette festlegen kann. Die Zeichenkette muss aber gewissen Regeln entsprechen [17].

Um sowohl die Anonymität zu gewährleisten, als auch die Nutzung anspruchsvollerer Webseiten zu ermöglichen, muss der Admin einen zweckdienlichen Kompromiss zwischen Preisgabe und Verschleierung finden. In der Regel wählt er dabei die Header abhängig von der besuchten Webseite aus, damit die Anonymität nicht jede Benutzerfreundlichkeit zunichte macht. Diese Aufgabe kann der beliebteste Webproxy Squid nicht schultern, bei ihm kann der Admin nur zwischen kompletter Verschleierung oder vollständiger Preisgabe wählen.

Tor und Privoxy

Aber der durch das Tor-Projekt bekannte Proxyserver Privoxy schafft den Kompromiss. Noch bis vor Kurzem war er jedoch nicht für den produktiven Einsatz geeignet, schon weil er keinen Cache besaß. Das hat sich mit Version 3.0.17 [18] geändert, die Unterstützung für große Dateien, Keep-alive und stabiles IPv6 implementiert.

Privoxy lässt sich auch als Stand-alone-Proxy auf dem Localhost betreiben. Wer dabei nach der Standardinstallation den lokalen Rechner mit Port 8118 in seine Browserkonfiguration aufnimmt, findet unter der URL http://config.privoxy.org keine externe Webseite, sondern die umfangreiche Konfigurationsseite des Proxyservers (Abbildungen 5 und 6) und ist fortan uneingeschränkt Herr seiner eigenen Privatsphäre.

Abbildung 5: Nach der Installation aus den Ubuntu- oder Suse-Repositories oder dem Quelltext meldet sich Privoxy, indem es eine Webseite umleitet.

Abbildung 6: Auch wenn das lokale Webinterface von Privoxy alle Einstellungen schnell zugänglich macht, ist Vorsicht geboten.

In Unternehmen liegt der Fokus aber vielleicht anders: Hier gilt es, den Anwendern einen gewissen Grad an Anonymität automatisch zu sichern, und da kommt die angesprochene Proxykaskade ins Spiel: Wer Squid mit einer vorgeschalteten Privoxy-Instanz ergänzt, kann die Vorteile beider Proxyserver nutzen. Squid speichert beantwortete Anfragen zwischen und führt eine grobe Liste zulässiger Header, Privoxy kümmert sich um die feingranulare Weiterleitung und das kontrollierte Entfernen unerwünschter Informationen aus den Headern.

Auch ohne Webinterface

Admins, die den Anwenderzugriff auf das Privoxy-Webinterface im lokalen Netz unterbinden wollen – etwa weil für alle Anwender eine verbindliche Policy gilt oder sie einen transparenten Proxy verwenden, von dem die User gar nichts mitbekommen –, müssen diesen Zugriff mit den passenden Squid-Regeln verhindern. Dafür legen sie in der Datei »squid.conf« eine Accessliste an, die eine Sammlung von Domains aus einer Datei einliest, und definieren eine »http_access« -Direktive, die Zugriffe auf diese ACL mit dem Codewort »deny« verweigert.

In Squids Konfigurationsdatei lässt sich (auch im laufenden Betrieb) bereits eine minimale Kontrolle über die gesendeten Header einrichten. Eine sinnvolle Ergänzung zeigt das Listing 1, abgeleitet aus den Headern in Tabelle 1. Welche Optionen zusätzlich das Protokollieren der beschriebenen Proxys deaktivieren, zeigt der Kasten “Anonymes Logging”.

access_log /dev/null
cache_store_log /dev/null
cache_log /dev/null
# IDENT Lookups deaktivieren
ident_lookup_access deny all
# Internet-Cache-Protocol deaktivieren
icp_port 0
icp_access deny all

01 [...]
02 # Header HTTP_VIA nicht preisgeben
03 via off
04 # Header HTTP_X_FORWARDED_FOR nicht preisgeben
05 forwarded_for off
06 # Header User-Agent durch Standardvorgabe ersetzen
07 header_replace User-Agent Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
08 ## Header mittels Whitelist preisgeben
09 header_access Accept allow all
10 header_access Accept-Encoding allow all
11 header_access Accept-Language allow all
12 header_access Authorization allow all
13 header_access Cache-Control allow all
14 header_access Content-Disposition allow all
15 header_access Content-Encoding allow all
16 header_access Content-Length allow all
17 header_access Content-Location allow all
18 header_access Content-Range allow all
19 header_access Content-Type allow all
20 header_access Cookie allow all
21 header_access Expires allow all
22 header_access Host allow all
23 header_access If-Modified-Since allow all
24 header_access Location allow all
25 header_access Range allow all
26 # Header an Privoxy weiterleiten
27 header_access Referrer allow all
28 header_access Set-Cookie allow all
29 header_access WWW-Authenticate allow all
30 ## Default-Deny-Prinzip fuer restliche Header
31 header_access All deny all
32 # Alle Anfragen an Privoxy weiterleiten
33 cache_peer localhost parent 8118 7 no-digest no-query max-conn=256 default
34 never_direct allow all
35 [...]

Ein üblich konfigurierter Privoxy bringt bereits alles mit, was nötigt ist, um einen Basisschutz der Privatsphäre zu gewährleisten. Fast immer reicht es aus, die in der Regel ausreichend aktuelle Version aus der Softwaresammlung der gewählten Distribution zu installieren. Für alle anderen Fälle bietet das Projekt vorbereitete Binärpakete für gängige Distributionen und Windows auf der Projektseite bei Sourceforge [19] an.

Die Voreinstellung von Privoxy ist aber nicht optimal auf den produktiven Einsatz mit vielen Clients ausgelegt, hier muss der Admin selbst Hand anlegen, er tut dies am besten in den Konfigurationsdateien. Nach der Installation befinden sich diese im Verzeichnis»/etc/privoxy/« . Drei Dateien entscheiden über die anzuwendenden Filter:

• »match-all.action« beschreibt die Aktionen rund ums Banner-Blocken, Pop-up-Kontrolle und Content-Modifikationen.
• »default.action« listet Ausnahmen (White- und Blacklist) von den Regeln in »match-all.action« als Regelwerk.
• »user.action« beinhaltet lokale Settings, Vorlieben und Einstellungen.

Wer Privoxy nur als neutralen Proxy einsetzen will, muss alle für fest definierte Domains geltenden Filter in »default.action« deaktivieren. Gleiches gilt für die Datei »user.action« . Der gleiche Effekt lässt sich übrigens auch durch »#« -Kommentarzeichen vor den Zeilen mit den »actionsfile« -Einträgen in der Datei »config« erreichen. Die in Listing  2 angegebenen Filter sollte der Admin entweder in die Datei »match-all.action« übernehmen oder sie in einem entsprechenden Actionsfile aktiv schalten.

HTTP-Referrer entfernen

Details zu den umfangreichen Einstellungsmöglichkeiten von Privoxy bietet die hervorragende Dokumentation auf der Webseite. Vorsicht ist aber geboten, denn die schiere Fülle an Settings gerät schnell unübersichtlich und legt viele Fallstricke aus. Ein Schritt-für-Schritt-Vorgehen ist bei eigenen Anpassungen ratsam, egal ob der Admin das Webinterface nutzt oder die Dateien selbst editiert.

Privoxys Hauptaufgabe in der Proxykaskade ist das intelligente Weiterleiten des Referrer-Headers, ohne die Benutzbarkeit von Webseiten, die diesen Header benötigen, einzuschränken. Hier ist die Option »+hide-referrer« in Zeile 11 von Listing 2 zuständig. Die passt der Admin an seine Bedürfnisse an und hinterlegt sie in »match-all.action« .

01 {
02 # 1x1 Pixel-Tracking blockieren
03 +filter{webbugs} \
04 # Fenster nicht bewegbar durch JS
05 +filter{jumping-windows} \
06 # InternetExplorer Bugs blockieren
07 +filter{ie-exploits} \
08 # E-Mail Adresse verbergen
09 +hide-from-header{block} \
10 # Referer-Fix
11 +hide-referrer{conditional-block} \
12 # Cookies immer ablaufen lassen
13 +session-cookies-only \
14 }
15 / # Match all URLs

Die Anweisung »+hide-referrer« kennt mehrere Optionen: Die verwendete »{conditional-block}« entfernt den Header, wenn der Browserbenutzer den Host gewechselt hat, »{conditional-forge}« gibt im gleichen Fall einen vordefinierten Eintrag an, »{block}« löscht ihn immer, »{forge}« ersetzt den Eintrag immer durch den des angefragten Webservers. Jeder andere Eintrag setzt einen vom User definierten Referrer, der immer verwendet wird.

In größeren Installationen gehören außerdem alle lokalen Webseiten in die Privoxy-Whitelist in der Datei namens »trust« . Wer dort eine Domain mit dem Präfix »~« versieht, veranlasst Privoxy dazu, die Filterung für diese URL zu überspringen. Ein stattdessen vorangestelltes »+« -Zeichen unterbindet auch die Prüfung für alle Domains, die dort verlinkt sind, also quasi rekursiv und Domain-übergreifend.

Fazit

Die Proxykaskade aus Squid und Privoxy erweist sich als zuverlässiger und hilfreicher Schutz der Privatsphäre und eignet sich dank Webinterface und Konfiguration via Klartextdateien auch für Privatanwender mit eigenem Server. Ist dieser richtig eingestellt, dann bekommt der Anwender gar nichts von dem zusätzlichen Schutz mit. Doch wer wirklich erhöhte Anonymität gewährleisten will, ist auf die lieben Kollegen angewiesen: Erst die Nutzung eines solchen Dienstes durch mehr als eine Person vereitelt die Zuordnung auch ohne weitergeleitete Header. Hier kämen dann Projekte wie Tor ([21], [22]) oder Dienstleister wie Jon Donym [23] ins Spiel.