Facebook-Blockade direkt im Bind9-Nameserver

Zensur ist schlecht, Medienkompetenz ist gut

Hier geht es explizit nicht darum, ein Zensurwerkzeug zu schaffen. Vielmehr soll diese Anleitung helfen, die eigene Privatsphäre zu schützen. Leider gibt es nicht überall für Facebook und Konsorten sogenannte 2-Klick-Lösungen, um die Datenübermittlung erst zu aktivieren. Meistens würde wohl auch ein einfacher Link genügen (so wie bei juergen.rocks), der keine Skripte benötigt und nicht irgendwelche Daten von externer Seite nachladen muss und damit schonmal rein prophylaktisch den Besuch meldet und Daten überträgt, auch wenn keine Interaktion mit dem sozialen Netzwerk stattfand.

Wenn man selbst eine solche Sperrlösung, wie im Rahmen dieses Artikels beschrieben, implementiert, hat man auch die Freiheit, sie jederzeit wieder abzuschalten oder neu zu konfigurieren. Niemand soll dazu gezwungen werden, sich hinter einem solchen Filter aufzuhalten. Ich bin der Meinung, dass es nicht Aufgabe von Telekommunikationsprovidern, Regierungen oder Behörden sein kann, solche Sperren zwangsweise auszurollen. Das Internet bietet freien Zugang zu Information und Vernetzungsmöglichkeiten, wie sie für eine demokratische Grundordnung unverzichtbar sind. Leider gibt es auch bei uns in Deutschland immer wieder Beißreflexe von Politikern, für die das Internet gefährliches Neuland ist und die flächendeckende Überwachung zum eigenen Macht- und Kontrollerhalt unabdingbar erscheint. Diese Personen ignorieren mehr oder weniger bewusst die Chancen einer aufgeklärten und medienkompetenten Nutzung und betonen immer wieder die Gefahren. Statt mehr Geld in Medienkompetenzförderung zu stecken, konstruieren immer wieder die gleichen Personen immer wieder lautstarke stammtischkompatible Rufe nach Regulierung, Zensur und Vorratsdatenspeicherung.

Natürlich gibt es dunkle Ecken im Internet - genau so wie in jeder größeren Stadt. Ich möchte sicherlich die Gefahren nicht kleinreden, denn ich sehe das große soziale Netzwerk mit dem weißen »f« auf blauem Grund durchaus als Gefahr. Allerdings nur für meine Privatsphäre. Ich möchte selbst entscheiden, ob ich mich dagegen schütze oder ob ich das Tracking in Kauf nehmen möchte. Auch ich erhalte jeden Tag tolle Mails, die mir pharmazeutische Prodkute zu tollen Preisen, Erbschaften und staatliche Geldmittel im Austausch für meine Bankverbindung anbieten, bin aber durchaus in der Lage, selbst zu entscheiden, dass es sich hier um Betrugsversuche handelt. Ich lade auch nicht bei irgendwelchen Downloadportalen wild irgendwelche »Optimierungssoftware« herunter und erfreue mich dann an neuen Browser-Toolbars, ständigen Werbeeinblendungen und dem Paket an Extra-Bloat- und Adware.

Ich kann hier nur an meine Generation, die mit dem Internet aufgewachsen ist, appellieren: Helft euren Kindern, Elten und Großeltern, Medienkompetenz zu erlangen. Macht sie zu mündigen digitalen Bürgen. Ja, dazu zählt auch der Umgang mit den eigenen Daten und sozialen Netzwerken. Erlebt die Freiheit des Internets gemeinsam. Erforscht seine Stärken und Schwächen, Chancen und Risiken. Inzwischen gehört das Internet untrennbar zu unserem täglichen Leben. Bleibt kritisch bei allen Inhalten. Nur weil etwas im Internet steht, heißt es nicht automatisch, dass es wahr ist. Es heißt aber auch nicht automatisch, dass es falsch ist. Und nicht alles, was gratis angeboten wird, ist auch ohne Kosten.

Jetzt aber zur Anleitung, die garantiert ohne weitere Kosten angeboten wird.

Grundlage

Wer bereits Bind9 als Nameserver verwendet, kann mit ganz einfachen Mitteln eine schwarze Liste für Domains bauen. Diese Domains lässt man dann auf einen eigenen kleinen Webserver auflösen, um beim Aufruf im Browser zum einen eine entsprechende Meldung zu erhalten und, zum anderen, um den HTTP-Fehlercode 404 für »Element nicht gefunden« für alle Aufrufe zurückzuliefern.

Der Vorteil einer solchen Lösung besteht darin, dass so auch alle Geräte und Browser geschützt sind, bei denen man nicht so einfach selektiv JavaScript deaktivieren oder Anti-Ad-Plugins benutzen kann, z. B. für Tablets, Smartphones, Smart-TV und Set-Top-Boxen.

Natürlich lässt sich auch mit anderen DNS-Servern implementieren, der Weg ist überall ähnlich.

Teil 1: Das schwarze Loch

Zunächst erzeugt man eine Vorlage für alle Domains, die wir nicht haben wollen. Dies erledigt die folgende Zone-Datei, die unter /etc/named.d/blackhole.zone.file abgelegt wird. Dabei gehen wir davon aus, dass der Hostname unseres Nameservers ns.lan.mydomain.de ist. Der Webserver, den wir später noch konfigurieren werden, hört auf die IP-Adresse 192.168.1.91.

$TTL    86400                    ; one day

@       IN      SOA ns.lan.mydomain.de. blackhole.ns.lan.mydomain.de. (
                2015051700       ; serial number YYMMDDNN
                28800            ; refresh        8 hours
                7200             ; retry          2 hours
                864000           ; expire        10 days
                86400 )          ; min ttl        1 day
        NS      ns.lan.mydomain.de.

        A       192.168.1.91

@       IN      A       192.168.1.91
*       IN      A       192.168.1.91

Jede Domain, auf die diese Zone-Datei später angewandt wird, löst mit allen Subdomains nun nach 192.168.1.91 auf.

Teil 2: Die schwarze Liste

Für die Liste der blockierten Domains ist eine weitere Datei zuständig: /etc/named.d/blackhole.conf. Sie hat folgenden Aufbau:

zone "facebook.com" IN { type master; notify no; file "/etc/named.d/blackhole.zone.file"; };
zone "facebook.de" IN { type master; notify no; file "/etc/named.d/blackhole.zone.file"; };
zone "facebook.net" IN { type master; notify no; file "/etc/named.d/blackhole.zone.file"; };
zone "facebook.mobi" IN { type master; notify no; file "/etc/named.d/blackhole.zone.file"; };
zone "facebook.org" IN { type master; notify no; file "/etc/named.d/blackhole.zone.file"; };
zone "facebook.com.au" IN { type master; notify no; file "/etc/named.d/blackhole.zone.file"; };
zone "fbcdn.com" IN { type master; notify no; file "/etc/named.d/blackhole.zone.file"; };
zone "fbcdn.net" IN { type master; notify no; file "/etc/named.d/blackhole.zone.file"; };
zone "facebook.com.nl" IN { type master; notify no; file "/etc/named.d/blackhole.zone.file"; };
zone "fb.com" IN { type master; notify no; file "/etc/named.d/blackhole.zone.file"; };
zone "fb.net" IN { type master; notify no; file "/etc/named.d/blackhole.zone.file"; };
zone "fb.me" IN { type master; notify no; file "/etc/named.d/blackhole.zone.file"; };
zone "facebook.me" IN { type master; notify no; file "/etc/named.d/blackhole.zone.file"; };

Hier wird jeder Domain die oben erstelle Zone-Datei zugewiesen. Damit der Nameserver die neuen Zonen nun auch kennt, muss die folgende Zeile am Ende der /etc/named.conf angefügt:

include "/etc/named.d/blackhole.conf";

Wird openSUSE und yast verwendet, sollte man die /etc/named.conf nicht bearbeiten und stattdessen die /etc/sysconfig/named an dieser Stelle erweitern:

[...]
NAMED_CONF_INCLUDE_FILES="blackhole.conf"
[...]

Nun muss noch der Nameserver neu gestartet werden:

service named reload

Den Zustand kann man mit service named status prüfen.

Ein erster Test

Das Ergebnis der Konfiguration kann man mit dem Befehl dig @192.168.1.90 www.facebook.de (192.168.1.90 ist die IP des Nameservers) testen - und das sollte so aussehen:

; <<>> DiG 9.9.5-rpz2+rl.14038.05-P1 <<>> @192.168.1.90 www.facebook.de
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50269
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.facebook.de.               IN      A

;; ANSWER SECTION:
www.facebook.de.        86400   IN      A       192.168.1.91

;; AUTHORITY SECTION:
facebook.de.            86400   IN      NS      ns.lan.mydomain.de.

;; ADDITIONAL SECTION:
ns.lan.mydomain.de.     172800  IN      A       192.168.1.90

;; Query time: 0 msec
;; SERVER: 192.168.1.90#53(192.168.1.90)
;; WHEN: Fri Apr 17 18:55:03 CEST 2015
;; MSG SIZE  rcvd: 100

Teil 3: Einen Webserver aufsetzen

Hier benötigt man keinen großen und umfangreichen Webserver. Es genügt der kleine thttpd, der fast von jeder Linux-Distribution über die normalen Paketquellen bereitgestellt wird. Für den minimalen Webserver ist nicht viel Konfigurationsarbeit erforderlich. In der /etc/thttpd.conf sind folgende Punkte wichtig:

[...]
port=80
[...]
dir=/srv/www/blackhole
[...]
host=192.168.1.91

Das port sollte immer auf Port 80, dem Standard-Port für unverschlüsselten HTTP-Verkehr stehen. Das dir gibt an, wo thttpd die Dinge findet, die er ausliefern soll, also unsere Sperrinformationsseite. Die Angabe host bringt thttpd dazu, sich nur auf der angegebenen IP-Adresse an das besagte Port 80 zu binden und nicht an jeder verfügbaren. Das ist recht praktisch, wenn der Server über mehrere IP-Adressen verfügt und man an einer anderen Adresse vielleicht doch noch einen anderen Server betreiben will.

Um nun entsprechende Fehlermeldungen zu erhalten, müssen diese erzeugt werden. Dazu wird zunächst ein entsprechendes errors-Verzeichnis angelegt und dorthin gewechselt, und ein Editor für die Datei blackhole.html geöffnet (sie wird automatisch angelegt, wenn sie noch nicht existiert:

mkdir -p /srv/www/blackhole/errors
cd !:2
nano blackhole.html

Diese Datei bekommt den folgenden Inhalt:

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <title>Blockiert</title>
        <meta charset="UTF-8" />
    </head>
    <body>
        <h1>Dieser Zugriff ist leider unerwünscht.</h1>
        <p>Tracker müssen draußen bleiben</p>
    </body>
</html>

Diese Datei muss nun noch an die richtigen Stellen verknüpft werden, damit sie thttp standardmäßig bei direktem Aufruf und auch bei nicht gefundenen Dateien ausliefert:

ln -s blackhole.html err401.html
ln -s blackhole.html err403.html
ln -s blackhole.html err404.html
cd ..
ln -s errors/blackhole.html index.html

Nun muss man thttpd noch aktivieren und starten und gegebenenfalls die Firewall-Konfiguration für Port 80 anpassen. Ein kleiner Testaufruf von http://192.168.1.91 im Browser sollte die soeben gestaltete Fehlerseite zeigen. Und auch ein Aufruf von http://www.facebook.de/ sollte nun hier landen. Einziger Haken: Möglicherweise halten DNS-Caches der jeweiligen Clients noch die alte Adresse vor. Also einfach das DNS-Cache leeren. Sollte man facebook.de zuvor besucht haben, so meldet ein vernünftiger Browser nun, dass er eigentlich per HTTPS mit Facebook sprechen wollte, aber keinen Anschluss bekommen hat. thttpd antwortet derzeit auch nur unverschlüsselt auf Port 80, für verschlüsselte Kommunikation über Port 443 muss uns stunnel helfen, was auch bei den meisten Distributionen direkt vorhanden ist. Bei openSUSE 13.2 muss man allerdings vor der Installation noch ein weiteres Repository aktivieren:

zypper ar http://download.opensuse.org/repositories/security:/Stunnel/openSUSE_13.2/ stunnel

Nach der Installation benötigt stunnel erst einmal ein Paket an Sschlüsseln und Zertifikaten, um überhaupt verschlüsselte Verbindungen anbieten zu können. Doch diese Dinge sind schnell erzeugt und konfiguriert. Wichtig ist eigentlich bei der Beantwortung der Fragen nur der Common Name, der sollte auf den Hostnamen von 192.168.1.91 lauten, muss aber nicht. Außerdem sollte kein Passwort angegeben werden.

openssl req -new -x509 -days 3650 -nodes -out /etc/stunnel/stunnel.pem -keyout /etc/stunnel/stunnel.pem
# [... Fragen beantworten ...] #
chmod 0400 !:10

Natürlich sind diese Zertifikate für den Browser später ungültige Zertikate - und das ist auch gut so. Wir wollen ja niemandem vorgaukeln, dass er zum Beispiel wirklich mit Facebook spricht. Wenn der Browser beschließt, dann keine Verbindung zuzulassen, ist unser Ziel ja auch erreicht. Die weitere Konfiguration von stunnel findet in /etc/stunnel/stunnel.conf statt. Hier ist eigentlich alles auskommentiert bis auf diese Zeilen:

cert = /etc/stunnel/stunnel.pem

[https]
accept  = 192.168.1.91:443
connect = 192.168.1.91:80
TIMEOUTclose = 0

Nun muss auch stunnel noch aktiviert und gestartet werden und gegebenenfalls die Firewall-Konfiguration für Port 443 angepasst werden. Danach kann man einen Testaufruf bei https://www.facebook.com starten und sollte über ein ungültiges Zertifikat informiert werden.

Damit ist das Ziel erreicht. Facebook-Plugins auf Webseiten funktionieren nun nicht mehr und man kann ohne Tracking durch diese das Netz durchstreifen.

Umgehung der Sperre

Natürlich ist es problemlos möglich, die Sperre zu umgehen. Man trägt zum Beispiel einfach einen anderen DNS-Server in seine eigene Client-Konfiguration ein, z. B. 8.8.8.8 von Google. Damit werden nun dort Anfragen an Facebook aufgelöst und es kann eine Kommunikation stattfinden.

Dies könnte man dadurch einschränken, dass man seine Firewall so konfiguriert, dass sie alle Anfragen in Richtung Port 53 an den eigenen Nameserver umleitet. Doch vom Gefühl her nimmt man damit seinen Nutzern die Möglichkeit, freiwillig auf den Schutzmechanismus zu verzichten und sich Facebook auszuliefern. Diese Freiheit sollte jeder haben.

Weitere Sperrlisten?

Natürlich gibt es im Internet mehr oder weniger leicht zu findende Listen von Werbe- und Trackinganbietern, für die sich für den einen oder anderen vielleicht auch ein Platz im schwarzen Loch findet. Ich veröffentliche bewusst keine Links zu solchen Listen. Manche Seiten finanzieren sich durch Werbung, und ich liefere hier keine Anleitung, wie diese Werbung zu unterdrücken ist.