VM basierende Anonymisierung
Dieser Artikel wurde für die folgenden Ubuntu-Versionen getestet:
Dieser Artikel ist mit keiner aktuell unterstützten Ubuntu-Version getestet! Bitte teste diesen Artikel für eine Ubuntu-Version, welche aktuell unterstützt wird. Dazu sind die Hinweise zum Testen von Artikeln zu beachten.
Artikel für fortgeschrittene Anwender
Dieser Artikel erfordert mehr Erfahrung im Umgang mit Linux und ist daher nur für fortgeschrittene Benutzer gedacht.
Dieser Artikel beschreibt die Anonymisierung des gesamten Netzwerkverkehrs einer Ubuntu-Instanz innerhalb einer virtuellen Maschine mit Hilfe von Tor und iptables. Insbesondere kann kein nicht-anonymisierter Netzwerkverkehr die VM-Instanz verlassen.
Das Aufsetzen einer dedizierten Ubuntu-Instanz ermöglicht dem Benutzer eine tiefgreifende Trennung zwischen normalem (alltäglichem) und anonymisiertem System. Dadurch wird der Benutzer angehalten, zwischen seinem normalen System (Gastgebersystem) - mit allen installierten Anwendungen und Daten - und dem anonymisierten System (Gast) zu trennen und somit "Benutzerfehler" bezüglich seiner Anonymität zu vermeiden.
Folglich sind die Ziele dieser Anleitung sowohl die Trennung der Systeme als auch die Zusicherung, dass kein nicht-anonymisierter Netzwerkverkehr das anonymisierte System verlassen kann. Dabei ist anzumerken, dass kein UDP-Verkehr die VM verlassen kann, da Tor das Weiterleiten von UDP noch nicht unterstützt. Ausnahme stellen DNS-Anfragen, die Tor über einen gesonderten DnsPort weiterleiten kann, sowie die Anfragen für die Zeitsynchronisation dar.
Der hier vorgestellte Ansatz bietet weitere Vorteile gegenüber der Anonymisierung des Netzwerkverkehrs einzelner Programme:
Firefox-Plugins wie z.B. Java und Flash, die die Proxy-Einstellungen des Browsers gegebenenfalls nicht beachten, können keine Verbindung mit dem Internet herstellen und die tatsächliche IP-Adresse offenlegen.
das Problem des "DNS-Leaking" ist nicht gegeben. Programme müssen den konfigurierten Proxy für die DNS-Auflösung benutzen, sonst werden entsprechende DNS-Anfrage-Pakete von iptables verworfen.
Dagegen ergeben sich folgende Nachteile:
höhere Anforderungen an die Hardware durch die Virtualisierung. Insbesondere ist mehr Arbeitsspeicher erforderlich.
höherer Konfigurations- und Wartungsaufwand. Für Einsteiger ist dies sicherlich nicht einfach zu bewältigen.
Einrichtung einer virtualisierten Ubuntu-Instanz¶
Die Einrichtung einer virtualisierten Ubuntu-Instanz ist in den Artikeln zu QEMU und VirtualBox beschrieben (weitere Virtualisierungsmöglichkeiten werden durch XEN und KVM angeboten).
Anonymisierung des Netzverkehrs¶
Im Folgenden werden zwei Varianten der Anonymisierung des Netzwerkverkehrs einer dedizierten Ubuntu-Instanz vorgestellt. Beide Varianten stellen sicher, dass kein nicht anonymisierter IPv4 Netzwerkverkehr die Instanz verlassen kann. Die Betrachtung von IPv6 erfolgt in diesem Artikel nicht. Um sicherzustellen, das kein IPv6 Verkehr die VM verlassen kann, sollte zu Beginn IPv6 daher systemweit per Grub-Bootoption deaktiviert werden, siehe Tuning.
Variante 1: socks- & http-Proxy als Gateway¶
Alle aus- und eingehenden Pakete werden durch entsprechende iptables-Regeln verworfen - außer sie gehören zum Tor-Netzwerkverkehr. Als Gateway zum Tor-Netzwerk stehen ein socks- und ein http-Proxy zur Verfügung. Der Tor-Client interne socks-Proxy lauscht auf Port 9050. Als http-Proxy dient Polipo; er lauscht auf Port 8118.
Der Nachteil dieser Variante ist, dass Programme - wie zum Beispiel Firefox - sowohl eine Proxy-Konfiguration anbieten müssen als dass diese auch pro Programm konfiguriert werden muss (siehe Tor/Programme zur Nutzung von Tor konfigurieren; die Gefahr des "DNS-Leaking" besteht bei diesem Vorgehen nicht).
Der Vorteil dieser Variante liegt darin, dass nur explizit konfigurierte Programme Pakete senden können; dadurch ist sowohl eine rudimentäre Abschottung von Programmen möglich als auch eine Protokoll-individuelle Filterung auf Anwendungsebene durch den genutzten Proxy.
Hinweis:
Alle nachfolgenden Instruktionen müssen innerhalb der virtualisierten Instanz mit Root-Rechten ausgeführt werden.
Achtung!
Die Schnittstellenkonfiguration für das Netzwerk der virtualisierten Instanz wird überschrieben!
Zunächst müssen die Pakete tor und polipo installiert werden:
polipo (universe)
tor (universe)
Befehl zum Installieren der Pakete:
sudo apt-get install polipo tor
Oder mit apturl installieren, Link: apt://polipo,tor
Anschließend muss noch die Konfiguration von polipo angepasst werden:
1 2 3 4 5 | cp /etc/polipo/config /etc/polipo/config.backup echo 'socksParentProxy = "localhost:9050"' > /etc/polipo/config echo 'socksProxyType = socks5' >> /etc/polipo/config echo 'diskCacheRoot = ""' >> /etc/polipo/config echo 'proxyPort = 8118' >> /etc/polipo/config |
Des Weiteren sollte das automatische Aktivieren der Netzwerkschnittstelle beim Bootvorgang deaktiviert werden. Dazu wird ein Eintrag in der interfaces vorgenommen, wodurch die Schnittstelle nicht mehr per Networkmanager verwaltet wird:
1 | echo -e "\niface eth0 inet dhcp\n" >> /etc/network/interfaces |
Zur Absicherung wird iptables eingesetzt. Denkbar ist nachfolgendes Script, das bei Bedarf oder automatisch (z.B. per Cron) gestartet werden kann. Aus didaktischen Gründen werden im Script die Langform der Parameter und Optionen von iptables verwendet. Alternativ können die iptables auch automatisch bei Systemstart bzw. beim Hochfahren der Netzwerkschnittstelle geladen werden (siehe iptables).
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 | #!/bin/bash # Kernelmodule laden modprobe ip_tables modprobe ip_nat_ftp modprobe ip_nat_irc modprobe ip_conntrack_irc modprobe ip_conntrack_ftp modprobe iptable_filter modprobe iptable_nat modprobe ipt_REJECT modprobe xt_recent modprobe ipt_mac # alle bisherigen Regeln und Ketten löschen iptables --flush iptables --table nat --flush iptables --delete-chain # jeglichen Traffic verwerfen iptables --policy INPUT DROP iptables --policy OUTPUT DROP iptables --policy FORWARD DROP # localhost zulassen iptables --append INPUT --in-interface lo --jump ACCEPT iptables --append OUTPUT --out-interface lo --jump ACCEPT # Proxy Einstellungen # Schnittstellenbezeichnung ab 16.04 anpassen ip link set eth0 up #manuelles Hochfahren der Schnittstelle dhclient eth0 #DHCP beantragen iptables --append OUTPUT --match owner --uid-owner "debian-tor" --jump ACCEPT iptables --append INPUT --protocol tcp --match state --state ESTABLISHED,RELATED -j ACCEPT # der Rest wird verworfen iptables --append OUTPUT --jump REJECT ## auskommentieren # service networking restart # service polipo restart |
Besonders ist zu beachten, dass die apt-Konfiguration angepasst werden muss, damit Sicherheitsaktualisierungen gefunden und nachgeladen werden können. Dazu muss mit einem Editor mit Root-Rechten die Datei /etc/apt/apt.conf editiert bzw., wenn noch nicht vorhanden, erstellt werden:
gksudo gedit /etc/apt/apt.conf
Es muss folgende Zeile eingetragen werden:
Acquire::http::Proxy "http://localhost:8118";
Variante 2: transparenter Proxy als Gateway¶
Der Tor-Client bietet einen internen transparenten Proxy an, der genutzt werden kann, um sämtlichen TCP-Netzwerkverkehr zu anonymisieren. Zur Umsetzung dieser Variante wird ein DNS-Proxy benötigt, der die DNS-Anfragen entgegennimmt und anonymisiert durch das Tor-Netzwerk auflöst.
Der Vorteil dieser Variante ist, dass keine weitere Konfiguration von Programmen nötig ist. Insbesondere müssen Programme keine Proxy-Unterstützung anbieten. Alle TCP-Pakete werden durch iptables-Regeln automatisch durch das Tor-Netzwerk anonymisiert (UDP-Pakete werden jedoch aufgrund der fehlenden Funktionalität von Tor grundsätzlich nicht weitergeleitet).
Ein Nachteil dieser Variante ist, dass jeder TCP-Netzwerkverkehr durch Tor geleitet wird. Protokoll-individuelle Filter auf Anwendungsebene wie Polipo oder Prixoxy werden nicht angewandt, dadurch werden gegebenenfalls unbewusst nicht anonymisierte Informationen gesendet.
Hinweis:
Alle nachfolgenden Instruktionen müssen innerhalb der virtualisierten Instanz mit Root-Rechten ausgeführt werden.
Achtung!
Die Schnittstellenkonfiguration für das Netzwerk der virtualisierten Instanz wird überschrieben!
Zunächst muss tor installiert werden:
tor (universe)
Befehl zum Installieren der Pakete:
sudo apt-get install tor
Oder mit apturl installieren, Link: apt://tor
Anschließend muss noch die Konfiguration von tor angepasst werden:
1 2 3 4 5 6 7 8 | cp /etc/tor/torrc /etc/tor/torrc.backup ## auskommentieren # echo "VirtualAddrNetworkIPv4 172.16.0.0/12" > /etc/tor/torrc echo "TransPort 9040" >> /etc/tor/torrc echo "DNSPort 9053" >> /etc/tor/torrc echo "AutomapHostsOnResolve 1" >> /etc/tor/torrc |
Des Weiteren sollte das automatische Aktivieren der Netzwerkschnittstelle beim Bootvorgang deaktiviert werden. Dazu wird ein Eintrag in der interfaces vorgenommen, wodurch die Schnittstelle nicht mehr per Networkmanager verwaltet wird:
1 | echo -e "\niface eth0 inet dhcp\n" >> /etc/network/interfaces |
Zur Absicherung wird iptables eingesetzt:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 | #!/bin/bash # Kernelmodule laden modprobe ip_tables modprobe ip_nat_ftp modprobe ip_nat_irc modprobe ip_conntrack_irc modprobe ip_conntrack_ftp modprobe iptable_filter modprobe iptable_nat modprobe ipt_REJECT modprobe xt_recent modprobe ipt_mac # alle bisherigen Regeln und Ketten löschen iptables --flush iptables --table nat --flush iptables --delete-chain # jeglichen Traffic verwerfen iptables --policy INPUT DROP iptables --policy OUTPUT DROP iptables --policy FORWARD DROP # zugelassene Verbindungen # Schnittstellenbezeichnung ab 16.04 anpassen ip link set eth0 up #manuelles Hochfahren der Schnittstelle dhclient eth0 #DHCP beantragen iptables --append INPUT --in-interface eth0 --match state --state ESTABLISHED,RELATED --jump ACCEPT iptables --append OUTPUT --out-interface eth0 --match state --state ESTABLISHED,RELATED --jump ACCEPT # localhost zulassen iptables --append INPUT --in-interface lo --jump ACCEPT iptables --append OUTPUT --out-interface lo --jump ACCEPT # Ruleset for Tor Transparent Proxy iptables -t nat --append OUTPUT --out-interface lo --jump RETURN iptables -t nat --append OUTPUT --match owner --uid-owner "debian-tor" --jump RETURN iptables -t nat --append OUTPUT --protocol udp --dport 53 --jump REDIRECT --to-ports 9053 iptables -t nat --append OUTPUT --protocol tcp --syn --jump REDIRECT --to-ports 9040 iptables --append OUTPUT --match state --state ESTABLISHED,RELATED --jump ACCEPT iptables --append OUTPUT --match owner --uid-owner "debian-tor" --jump ACCEPT for NET in 127.0.0.0/8; do iptables --append OUTPUT --destination $NET --jump ACCEPT done ## optional Zugriff aus dem lokalen Netzbereich 192.168.1.0 ermöglichen, z.B. für ssh #for NET in 192.168.1.0/24; do # iptables --append INPUT --destination $NET --jump ACCEPT # iptables --append OUTPUT --destination $NET --jump ACCEPT #done ## alternativ kann der Port auch ohne Einschränkung freigeschaltet werden # iptables --append INPUT --protocol tcp --dport 22 --jump ACCEPT # iptables --append OUTPUT --protocol tcp --sport 22 --jump ACCEPT # zur Zeitsynchronisation wird der Port 123 freigeschaltet iptables --append OUTPUT --protocol udp --match udp --dport 123 --jump ACCEPT # der Rest wird verworfen iptables --append OUTPUT --jump REJECT ## auskommentieren # service networking restart # service tor restart |
Als Vorlage für diesen Code diente Tor Wiki - Transparently Routing Traffic Through Tor 🇬🇧.
Bewertung der Sicherheit¶
Die VM dient als Trennung zwischen normalem und dem anonymisierten System. Dabei stellt die VM zwar eine erhebliche, aber doch wegen möglicher Sicherheitslücken nicht unüberwindliche Hürde dar. Innerhalb der VM-Instanz kann nicht ohne weiteres auf das Dateisystem des Gastgebersystems zugegriffen werden; vom Gastgebersystem ist das Dateisystem des Gastes bei aktivierter Verschlüsselung des VM-Containers mittels der Alternate-Installation nicht zugreifbar.
Bezüglich der Vertraulichkeit der Daten innerhalb der VM ist besonders zu beachten:
Das Gastgebersystem muss vertrauenswürdig sein. Prozesse des Gastgebers dürfen die VM nicht ausspionieren - sie dürfen zum Beispiel nicht das Speicherabbild oder die Tastatureingaben analysieren.
Besonders ist zu beachten, dass bei einem mit Hilfe der Alternate-Installation verschlüsselten System unverschlüsselte Inhalte des VM-Arbeitsspeichers in den Auslagerungsspeicher (swap) des Gastgebersystems gelangen können.
Um die beiden genannten Nachteile zu umgehen, kann ein dediziertes nicht-virtualisiertes System zur Anonymisierung mit Hilfe der aufgezeigten iptables-Regeln eingesetzt werden.
Durch die iptables-Regeln kann kein nicht-anonymisierter Netzwerkverkehr die VM verlassen. Wenn aber Schadcode innerhalb der VM durch eine Sicherheitslücke die Rechte des root-Benutzers erlangen könnte, dann könnten die iptables-Regeln außer Kraft gesetzt und somit die wahre IP-Adresse offengelegt werden. Eine mögliche Abhilfe gegen das skizzierte Angriffsszenario wäre das Anonymisieren des VM-Netzverkehrs außerhalb der VM (siehe z.B. TorVTL 🇬🇧).
Weitere Gefahrenhinweise:
Besonders wird vor "bösen" Exit-Nodes gewarnt.
Die Grenzen der von Tor erreichten Anonymität sind unter Tor FAQ - What protections does Tor provide? 🇬🇧 aufgezeigt.
Es wird empfohlen, die erfolgreiche Umsetzung mit Hilfe von Testen, ob man mit Tor surft 🇩🇪 zu prüfen.
Weiterführende Links¶
intern¶
extern¶