Namensauflösung ohne Zensur und Überwachung
Vorbemerkung
Zu den Methoden, das Nutzungsverhalten von Internetnutzern zu überwachen und / oder deren Zugriff auf Inhalte im Internet zu zensieren, was von Befürwortern als "Internet-Sperre" bezeichnit wird, zählen Manipulationen der Namensauflösung und des Domain Name System (DNS). Bekannt sind Manipulationen in Ländern wie China. In Deutschland wurden in der Vergangenheit ähnliche Eingriffe vorgenommen oder Versuche zur Entwicklung nationaler Zensur-Infrastrukturen gestartet. Der letzte Vorstoß in Deutschland wurde mit dem Beschluss des Zugangserschwerungsgesetz im Jahr 2009 unternommen.
Zu den Methoden zur Abwehr der eigenen Überwachung und der Eingriffe in die Rezipientenfreiheit über die oben genannten Manipulationen gehört die Änderung der Konfiguration der Namensauflösung und Nutzung des DNS, um Zensur-Infrastrukturen und manipulierte DNS Server zu umgehen.
Linux (Debian)
pdnsd
Bei pdnsd handelt es sich um einen sogenannten DNS-Proxy, der lokal auf dem eigenen Computer installiert Anfragen zur Namensauflösung entgegennimmt, um sie an die eigentlichen DNS-Server weiterzuleiten.
Die Antworten werden von pdnsd in der lokalen Cache Datei /var/cache/pdnsd/pdnsd.cache für einen selbst zu definierenden Zeitraum vorgehalten, so dass zu einem späteren Zeitpunkt auch dann eine Namensauflösung stattfinden kann, wenn DNS-Server ausfallen. Andere DNS-Proxys und -Server verwenden nur das Caching im Arbeitsspeicher. Das hat wie bei allen DNS-Caches auch den Vorteil, dass Anfragen zur Namensauflösung schneller beantwortet und weniger Anfragen weitergeleitet werden müssen, wenn die Daten bereits im Cache von pdnsd vorliegen, was zudem die von pdnsd verwendeten DNS-Server entlastet.
Mit reduziertem Umfang kann pdnsd nicht nur als DNS-Proxy, sondern auch als DNS-Server eingesetzt werden.
Installation & Konfiguration
Ist das Paket des DNS-Servers bind installiert, wird zuerst bind entfernt und danach pdsnd installiert:
sudo aptitude purge bind9 sudo aptitude install pdnsd
Nach der Installation von pdnsd wird der Auto-Modus in /etc/default/pdnsd deaktiviert, damit eine eigene pdnsd Konfigurationsdatei nicht überschrieben wird:
AUTO_MODE=
- Beispiel der /etc/pdnsd.conf Konfigurationsdatei
global { perm_cache = 2048; cache_dir = "/var/cache/pdnsd"; server_port = 53; server_ip = 127.0.0.1; linkdown_kluge = off; max_ttl = 7d; min_ttl = 2h; run_as = pdnsd; strict_setuid = on; paranoid = on; status_ctl = on; verbosity = 2; query_method = udp_tcp; run_ipv4 = on; debug = off; proc_limit = 15; procq_limit = 30; tcp_qtimeout = 30s; par_queries = 1; timeout = 60s; randomize_recs = on; query_port_start = 1025; query_port_end = 65535; use_nss = on; } server { label = tor; ip = 127.0.0.1; port = 1053; uptest = none; timeout = 30s; purge_cache = off; caching = on; lean_query = on; preset = on; proxy_only = on; exclude = .meine-bank.de,security.debian.org; policy = included; } server { label = gpf; ip = 87.118.100.175,94.75.228.29; randomize_servers = on port = 110; uptest = query; interval = ontimeout; timeout = 15s; purge_cache = off; caching = on; lean_query = on; preset = on; proxy_only = on; reject = 0.0.0.0/8,169.254.0.0/16,127.0.0.0/8,192.254.0.0/16,192.168.0.0/16,10.0.0.0/8,172.16.0.0/12; reject_policy = fail; reject_recursively = on; exclude = .meine-bank.de; policy = included; } server { label = myispdns; ip = n.n.n.n; port = 53; uptest = query; interval = ontimeout; timeout = 15s; purge_cache = off; caching = on; lean_query = on; preset = on; proxy_only = on; reject = 0.0.0.0/8,169.254.0.0/16,127.0.0.0/8,192.254.0.0/16,192.168.0.0/16,10.0.0.0/8,172.16.0.0/12; reject_policy = fail; reject_recursively = on; include = .meine-bank.de; policy = excluded; } server { label = "resolvconf"; proxy_only = on; } source { owner = localhost; file = "/etc/hosts"; } rr { name = localhost; reverse = on; a = 127.0.0.1; owner = localhost; soa = localhost,root.localhost,42,86400,900,86400,86400; }
Die Definitionen der verschiedenen Optionen sind online in der pdnsd Dokumentation auf der pdnsd Homepage oder nach Installation in der lokalen pdnsd Dokumentation nachzulesen.
Im Beispiel wird in der global Sektion zuerst der pdnsd selbst konfiguriert.
Wenn status_ctl mit "on" aktiviert wurde, wird das /var/cache/pdnsd/pdnsd.status Socket aktiviert und der pdnsd kann mit dem pdnsd-ctl Tool zur Laufzeit im Terminal konfiguriert und gesteuert werden. Ein paar Beispiele:
# listet alle Optionen, Kommandos und Argumente auf pdnsd-ctl help # Ausgabe des gesamten pdnsd Cache sudo pdnsd-ctl dump # Leeren des gesamten pdnsd Cache sudo pdnsd-ctl empty-cache # Ausgabe von Informationen zum Status und zur Konfiguration sudo pdnsd-ctl status # myispdns auf Erreichbarkeit testen sudo pdnsd-ctl server myispdns retest # Einträge für .meine-bank.de erneuern lassen sudo pdnsd-ctl record .meine-bank.de invalidate
In jeder server Sektion wird ein "DNS-Server" oder eine Liste von "DNS-Servern" konfiguriert.
Der erste DNS-Server, an den pdnsd die Anfragen weiterleitet, ist Tor. Tor (TCP Onion-Router) ist der Name einer lokal laufenden Router Software und eines Netzwerks, die der Anonymisierung des TCP basierten Netzwerkverkehrs dienen. Daneben enthält Tor Funktionen eines DNS-Proxy, der die UDP basierten Anfragen von pdnsd entgegennimmt und sie per TCP über das Tor Netzerk weiterleitet, um die Namensauflösung zu anonymisieren.
Kann oder soll (z. B. für den Webserver des eigenen Kreditinstituts) Tor die Anfragen nicht auflösen, werden die Anfragen direkt und nicht anonymisiert an zwei weitere DNS-Server der German Privacy Foundation (GPF) weitergeleitet. Der letzte Fall ist in dem Umstand begründet, dass Tor Ausgangs-Router die Namenauflösung durchführen, die ihrerseits die Antworten manipulieren können, um den Anfragenden z. B. auf manipulierte Webseiten umzuleiten (Phishing).
Im obigen Beispiel wird Port 110, der eigentlich POP3-Servern vorbehalten ist, für die GPF DNS-Server verwendet, was von der GPF angeboten wird, um möglichen Analysen der Anfragen zur Namensauflösung an den Standardport 53 oder Sperren von ausgehenden Anfragen an Port 53 auszuweichen. Um nicht beide Server für jede Anfrage zu kontaktieren, wurde die "randomize_servers" Option aktiviert.
Können oder sollen die GPF Server die Anfragen nicht auflösen, werden sie direkt und nicht anonymisiert an den DNS-Server des Internet Zugangsproviders weitergeleitet.
Um einzelne Hostnamen bzw. Domains nicht über bestimmte DNS-Server aufzulösen bzw. einen DNS-Server nur bestimmte Hostnamen bzw. Domains auflösen zu lassen, können in jeder Server-Sektion Einschluss- (include) oder Ausschluss-Listen (exlude) und inluce / exlude Policies angewendet werden, wobei für die include / exclude Listen "first match wins" gilt.
Im Beispiel sieht das Schema so aus:
tor
exclude = .meine-bank.de,security.debian.org; policy = included;
→ Sobald eine Anfrage für .meine-bank.de oder security.debian.org an pdnsd gestellt wird, treffen sie auf die Muster in der exclude Liste zu und werden deshalb nicht durch Tor aufgelöst. Alle anderen Anfragen (z. B. nach .torproject.org) treffen nicht auf die Muster der exclude Liste zu und da die Standardregel (policy) definiert, in diesem Fall den Server zu verwenden, wird die Anfrage an Tor weitergeleitet.
gpf1,gpf2
exclude = .meine-bank.de; policy = included;
→ Da auch die GPF Server nicht für die Auflösung von .meine-bank.de, aber für security.debian.org verwendet werden sollen, weil man z. B. den GPF Servern für .meine-bank.de nicht, aber für security.debian.org "vertraut", wird nur .meine-bank.de in die exclude Liste aufgenommen. Da die gleiche Standardregel (policy) wie für Tor definiert ist, werden für alle anderen Anfragen, also auch security.debian.org, die GPF Server zur Auflösung verwendet.
myispdns
include = .meine-bank.de; policy = excluded;
→ Sobald die Anfrage für .meine-bank.de an pdnsd gestellt wird, trifft sie auf die Muster in der exclude Liste des Tor und der GPF Server zu und wird deshalb nicht durch Tor und GPF aufgelöst. Sie trifft aber auf die Muster in der include Liste des myispdns Server zu und wird deshalb von pdnsd an den myispdns Server weitergeleitet, weil man z. B. nur dem DNS-Server des Internet Zugangsproviders für .meine-bank.de "vertraut".
Da der DNS-Server von myispdns in der Regel für alle Anfragen mit Ausnahme der Hostnamen und Domains in der include Liste umgangen und für alle anderen Anfragen ausgeschlossen werden soll, dass ihn Anfragen zur Namensauflösung erreichen, wird für den myispdns Server die Standardregel (policy) auf "excluded" gesetzt. Da alle anderen Anfragen nicht auf das Muster in der include Liste zutreffen, wird sie pdnsd deshalb nicht an den myispdns Server weiterleiten.
DNS-Server Listen
Anstatt der DNS-Server der German Privacy Foundation können alternativ andere DNS-Server eingesetzt werden, die ebenfalls keine Manipulationen vornehmen.
Quellen für Adressen nicht manipulierender DNS-Server
Tor
Nach der Installation von Tor laut der Anleitung für Debian / Ubuntu des Tor Projekts wird in die Tor Konfigurationsdatei /etc/tor/torrc eingefügt:
DNSListenAddress 127.0.0.1 DNSPort 1053
Konfiguration Namensauflösung
Sofern noch nicht installiert, das resolvconf Paket nachinstallieren:
sudo aptitude install resolvconf
Danach ist dafür Sorge zu tragen, dass in der letztendlich genutzten resolv.conf Konfigurationsdatei nur auf localhost und damit pdnsd als "DNS-Server" zur Namensauflösung verwiesen wird:
nameserver 127.0.0.1
Bei dynamischer Konfiguration der Netzwerkkarte per DHCP wird die resolv.conf Datei überschreiben und die Adressen der DNS-Server eingesetzt, die der DHCP Client vom DHCP-Server erhält, so dass man dafür Sorge tragen muss, dass ein Überschreiben der resolv.conf Datei unterbleibt.
Unter Debian erreicht man das durch Auskommentieren des Eintrags in /etc/dhcp3/dhclient.conf:
prepend domain-name-servers 127.0.0.1;
und Entfernung von domain-name-servers in der request Zeile:
request subnet-mask, (…)
domain-name-servers
ttdnsd
Der ttdnsd oder "Tor TCP DNS Daemon" des Tor Projekts nimmt auf einem UDP Port Anfragen zur Namensauflösung entgegen und konvertiert sie in TCP, um sie über den SOCKS Port an Tor weiterzureichen. Die Anfrage wird danach über das Tor Netzwerk anonymisiert vom Tor Exit Knoten an einen oder mehrere alternative bzw. "offene" rekursive Nameserver weitergeleitet. Die IP-Adressen der Nameserver werden dazu in der ttdnsd Konfigurationsdatei hinterlegt. Bei mehreren hinterlegten Nameserver Adressen wird aus dem Pool zufällig ein Nameserver für Anfragen ausgewählt. In der mitgelieferten ttnsd Konfigurationsdatei ist bereits und vorerst nur die IP-Adresse 8.8.8.8 des Google Namservers eingetragen.
Im Unterschied zur obigen pdnsd Konfiguration wird eine Anfrage also nicht anonymisiert über den DNSPort von Tor an einen Tor Exit Knoten gerichtet, der seinerseits seinen konfigurierten Nameserver abfragt oder als Fallback-Lösung eine Anfrage nicht anonymisiert direkt an einen oder mehrere alternative bzw. "offene" Nameserver gerichtet, sondern Anfragen "direkt", aber über Tor anonymisiert an einen oder mehrere alternative bzw. "offene" Nameserver gerichtet.
Mögliche Vorteile:
- jenseits des reduzierten Satzes von Anfragetypen bzw. deren Antwortinhalte, die per DNSPort / Tor genutzt werden können, können alle Anfragetypen (z. B. auch MX Records) genutzt werden, die von den eingetragenen Nameservern unterstützt werden
- Anfragen zu alternativen bzw. "offenen" Nameservern werden ebenfalls per Tor anonymisiert (u. a. Anfragen an GPF, CCC, FoeBuD Nameserver)
- statt vom Nameserver eines Tor Exit Knotens abhängig zu sein, der u. U. Anfragen blockiert oder verfälscht, bestimmt man selbst, welche Nameserver genutzt werden sollen
Mögliche bzw. weiter bestehende Nachteile:
- ohne zusätzliche Absicherung der Abfragen (DNSSEC, Kryptografie) kann ein böswilliger Tor Exit Knoten oder der böswillige Internet Zugangsprovider des Tor Exit Knotens weiterhin Anfragen umleiten oder blockieren und Antworten verfälschen
- ttdns verfügt z. Zt. über weniger Funktionen zur Abwehr verfälschter Antworten als Tor (z. B. ClientDNSRejectInternalAddresses)
- die hinterlegten Nameserver könnten ihrerseits in Traffic-Analysen eingebunden sein oder Manipulationen der Anfragen und Antworten vornehmen (Wahl der "richtigen" Nameserver wichtig)
- die hinterlegten Nameserver können nur auf dem Standardport 53 angefragt werden und nicht, wie z. B. bei den GPF Nameservern, auf Port 110
Installation & Konfiguration
Sofern ttdnsd (bereits) im Tor Repository vorhanden ist:
sudo aptitude install ttdnsd
Per git Repository:
sudo aptitude install git-core # falls git nicht installiert ist mkdir ~/.git && cd .git git clone git://git.torproject.org/ioerror/ttdnsd cp -R ttdnsd/ /tmp/ && cd /tmp/ttdnsd/ make deb sudo dpkg -i ../ttdnsd_version.deb
Bei Nutzung des git Repository sollten die Änderungen und Neuerungen verfolgt und die lokale Kopie und die Installation öfters aktualisiert werden.
In der ttdnsd Konfigurationsdatei /etc/ttdnsd.conf sind nur die Nameserver einzutragen, die zusätzlich oder anstatt des Google Nameservers genutzt werden sollen:
- Beispiel mit GPF, CCC, FoeBuD Nameservern
# Google # 8.8.8.8 # GPF1 87.118.100.175 # GPF2 94.75.228.29 # CCC 213.73.91.35 # FoeBuD 85.214.73.63
In der /etc/default/ttdnsd Datei kann man die IP-Adresse der Schnittstelle und den Port für den ttdnsd ändern und das Logging aktivieren:
Schnittstelle: ADDR_ARG="-b 127.0.0.1" Port: PORT_ARG="-p 53" Logging in /var/lib/ttdnsd/ttdnsd.log: # DEBUG_LOGGING="-l" DEFAULTS="$ADDR_ARG $PORT_ARG" # ohne Logging DEFAULTS="$ADDR_ARG $PORT_ARG $DEBUG_LOGGING" # mit Logging
Als Abhängigkeit für den Start von ttdnsd ist im ttdnsd Initscript das Tor Initscript angegeben. Wer Tor anders (z. B. manuell oder nach ttdnsd) startet / beendet, muss im ttdnsd Initscript "tor" in den beiden folgenden Zeilen entfernen:
# Required-Start: $remote_fs $syslog tor # Required-Stop: $remote_fs $syslog tor
mit & ohne pdnsd
Ohne pdnsd wird ttdnsd durch das ttdnsd Initscript automatisch beim Systemstart gestartet und lauscht danach am UDP Port 53 der localhost Schnittstelle auf Anfragen.
Mit pdnsd (oder bind, unbound usw.) muss im in der /etc/default/ttdnsd Datei die Portnummer von 53 auf eine noch unbenutzte Portnummer geändert werden, zum Beispiel 1153.
PORT_ARG="-p 1153"
Die Änderungen in der /etc/pdnsd.conf:
server {
label = tor;
ip = 127.0.0.1;
port = 1053;
uptest = none;
timeout = 30s;
purge_cache = off;
caching = on;
lean_query = on;
preset = on;
proxy_only = on;
exclude = .meine-bank.de,security.debian.org;
policy = included;
}
server {
label = ttdnsd;
ip = 127.0.0.1;
port = 1153;
uptest = none;
timeout = 15s;
purge_cache = off;
caching = on;
lean_query = on;
preset = on;
proxy_only = on;
reject = 0.0.0.0/8,169.254.0.0/16,127.0.0.0/8,192.254.0.0/16,192.168.0.0/16,10.0.0.0/8,172.16.0.0/12;
reject_policy = fail;
reject_recursively = on;
exclude = .meine-bank.de;
policy = included;
}
bind
Die Einrichtung von bind zur Umgehung manipulierter DNS-Server und anonymisierter Namensauflösung per Tor wird in der Anleitung DNS-Server für Linux konfigurieren im Privacy Handbuch der der German Privacy Foundation beschrieben.
Windows
Unter Windows können in den "Eigenschaften der LAN-Verbindung" die Adressen nicht manipulierender DNS-Server direkt eingetragen werden, was auf der Seite DNS-Server in Windows konfigurieren im Privacy Handbuch der German Privacy Foundation beschrieben wird.
Wie man unter Windows Tor für anonymisierte Anfragen zur Namensauflösung mit einem DNS-Proxy nutzt, kann auf der Seite Tor Namensauflösung für das Betriebssystem der Raven Homepage nachgelesen werden.
Sonstiges
Das .p2p Projekt plant neben der Einrichtung der .p2p TLD die Umsetzung eines dezentralen P2P-DNS Systems mit DHT, Verschlüsselung und Einsatz von Techniken der Netzwerk-Steganografie.
