ubuntuusers.de

Hinweis: Dies ist ein statischer Snapshot unseres Wikis vom 25. März 2013 und kann daher nicht bearbeitet werden. Der aktuelle Artikel ist unter wiki.ubuntuusers.de zu finden.

VM basierende Anonymisierung

Dieser Artikel wurde für die folgenden Ubuntu-Versionen getestet:

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.

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). Dabei bietet sich an, das gesamte System mit Hilfe der Alternate - Installation zu verschlüsseln.

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 Netzwerkverkehr die Instanz verlassen kann. Variante 1 kann mit der in den Paketquellen von Ubuntu 8.04 "Hardy Heron" enthaltenen Tor-Version genutzt werden, wohingegen die Variante 2 ab der Ubuntu Version 8.10 "Intrepid Ibex" genutzt werden kann. Alternativ kann für Ubuntu-Versionen älter als 8.10 die benötigte Tor-Version aus einer Fremdquelle installiert werden. Die Vor- und Nachteile der beiden Varianten werden jeweils kurz dargestellt.

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!

 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
#!/bin/bash

apt-get install polipo tor

iptables -F 
iptables -P INPUT DROP  
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

iptables -A OUTPUT -m owner --uid-owner debian-tor -j ACCEPT
iptables -A INPUT -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A OUTPUT -j REJECT

iptables-save > /etc/iptables.rules
chmod a-rwx,ug+r /etc/iptables.rules

cp /etc/network/interfaces /etc/network/interfaces.backup-VM-based-anonymization
echo -e "auto lo\niface lo inet loopback\n\n" > /etc/network/interfaces
echo -e "auto eth0\niface eth0 inet dhcp\npre-up iptables-restore < /etc/iptables.rules" >> /etc/network/interfaces
chmod a-rwx,ug+r /etc/network/interfaces

cp /etc/polipo/config /etc/polipo/config.backup-VM-based-anonymization
echo 'socksParentProxy = "localhost:9050"' >> /etc/polipo/config
echo 'socksProxyType = socks5' >> /etc/polipo/config
echo 'diskCacheRoot = ""' >> /etc/polipo/config
echo 'proxyPort = 8118' >> /etc/polipo/config

/etc/init.d/networking restart
/etc/init.d/polipo restart

Experten-Info:

Als Erstes werden alle gegebenenfalls bestehenden iptables-Regeln des Paketfilters gelöscht. Als Standardverhalten für alle drei (INPUT, OUTPUT, FORWARD) Verarbeitungsketten des Paketfilters wird "verwerfe alle Pakete" festgelegt. Abweichend von diesem Standardverhalten werden folgende Ausnahmen definiert: Alle Pakete zu und von der loopback-Schnittstelle werden zugelassen, um die System-lokale Kommunikation zwischen den einzelnen Prozessen zu ermöglichen. Alle ausgehenden als auch die korrespondierenden eingehenden Pakete, die von Prozessen losgeschickt worden sind, welche mit den Rechten des Benutzers "debian-tor" laufen, werden zugelassen. Als letzte Regel wird definiert, dass alle ausgehenden Pakete, auf die keine der bisher definierten (nicht Standard-) Regeln zutraf, verworfen werden und entsprechende Antworten an die sendenden Prozesse verschickt werden - dadurch erhält der Benutzer eine schnelle Rückantwort auf erfolglose Verbindungsversuche.

Diese iptables-Konfiguration wird in die Datei /etc/iptables.rules abgespeichert. Da in diesem Artikel davon ausgegangen wird, dass die Ubuntu-Instanz in einer VM läuft, wird die /etc/network/interfaces-Konfiguration überschrieben und durch eine neue Konfiguration der Netzwerkschnittstellen lo und eth0 ersetzt; dabei wird unter anderem festgelegt, dass vor jeder Aktivierung der Netzwerkschnittstelle eth0 die abgespeicherte iptables-Konfiguration geladen wird.

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. Ein solcher DNS-Proxy ist ab der Tor-Version 0.2.0 verfügbar. Diese Tor-Version ist ab Ubuntu 8.10 "Intrepid Ibex" in den Paketquellen vorhanden.

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 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 ungewollte Information gesendet.

Ein weiterer Nachteil dieser Variante liegt darin, dass gegebenenfalls ein Paket aus einer Fremdquelle bzw. von Hand installiert werden muss.

Hinweis:

Diese Konfigurationsvariante ist erst ab der Tor-Version 0.2.0 möglich, die nicht in den Paketquellen von Ubuntu 8.04 "Hardy Heron" vorhanden ist. Außerdem müssen alle nachfolgenden Instruktionen innerhalb der virtualisierten Instanz mit Root-Rechten ausgeführt werden.

Achtung!

Die Schnittstellenkonfiguration für das Netzwerk der virtualisierten Instanz wird überschrieben!

 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
#!/bin/bash

apt-get install tor

iptables -F
iptables -t nat -F

iptables -P INPUT DROP
iptables -A INPUT -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -d 127.0.0.0/8 -j ACCEPT

iptables -t nat -A OUTPUT -m owner --uid-owner "debian-tor" -j RETURN
iptables -t nat -A OUTPUT -d 10.0.0.0/8 -j RETURN       # privates Netzwerk der Klasse A
iptables -t nat -A OUTPUT -d 172.16.0.0/12 -j RETURN    # privates Netzwerk der Klasse B
iptables -t nat -A OUTPUT -d 192.168.0.0/16 -j RETURN   # privates Netzwerk der Klasse C
iptables -t nat -A OUTPUT -d 169.254.0.0/16 -j RETURN   # privates Netzwerk (link local)
iptables -t nat -A OUTPUT -p tcp -d 127.192.0.0/10 -j REDIRECT --to-ports 9040
iptables -t nat -A OUTPUT -d 127.0.0.0/8 -j RETURN
iptables -t nat -A OUTPUT -p udp --dport 53 -j REDIRECT --to-ports 53
iptables -t nat -A OUTPUT -p tcp --syn -j REDIRECT --to-ports 9040

iptables -P OUTPUT DROP
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -d 127.0.0.0/8 -j ACCEPT
iptables -A OUTPUT -m owner --uid-owner "debian-tor" -j ACCEPT
iptables -A OUTPUT -j REJECT

iptables-save > /etc/iptables.rules 
chmod a-rwx,ug+r /etc/iptables.rules 

cp /etc/tor/torrc /etc/tor/torrc.backup-VM-based-anonymization
echo "TransPort 9040" >> /etc/tor/torrc
echo "DNSPort 53" >> /etc/tor/torrc
echo "AutomapHostsOnResolve 1" >> /etc/tor/torrc

cp /etc/network/interfaces /etc/network/interfaces.backup-VM-based-anonymization
echo -e "auto lo\niface lo inet loopback\n\n" > /etc/network/interfaces
echo -e "auto eth0\niface eth0 inet dhcp\npre-up iptables-restore < /etc/iptables.rules" >> /etc/network/interfaces
chmod a-rwx,ug+r /etc/network/interfaces

cp /etc/dhcp3/dhclient.conf /etc/dhcp3/dhclient.conf.backup-VM-based-anonymization
echo "supersede domain-name-servers 127.0.0.1;" >> /etc/dhcp3/dhclient.conf

/etc/init.d/networking restart
/etc/init.d/tor restart 

Als Vorlage für diesen Code diente Tor Wiki - Transparently Routing Traffic Through Tor {en}.

Experten-Info:

Als Erstes werden alle gegebenenfalls bestehenden iptables-Regeln des Paketfilters und der "Network Address Translation" gelöscht.

Als Standardverhalten für die INPUT- und OUTPUT-Verarbeitungsketten des Paketfilters wird "verwerfe alle Pakete" festgelegt. Abweichend von diesem Standardverhalten werden folgende Ausnahmen definiert: Alle Pakete zu und von der loopback-Schnittstelle werden zugelassen, um die System-lokale Kommunikation zwischen den einzelnen Prozessen zu ermöglichen. Alle ausgehenden als auch die korrespondierenden eingehenden Pakete, die von Prozessen losgeschickt worden sind, welche mit den Rechten des Benutzers "debian-tor" laufen, werden zugelassen. Als letzte Regel wird definiert, dass alle ausgehenden Pakete, auf die keine der bisher definierten (nicht Standard-) Regeln zutraf, verworfen werden und entsprechende Antworten an die sendenden Prozesse verschickt werden - dadurch erhält der Benutzer eine schnelle Rückantwort auf erfolglose Verbindungsversuche.

Für die "Network Address Translation" werden folgende Regeln festgesetzt: Pakete, die an die loopback-Schnittstelle gesendet werden, und Pakete, die von einem Prozess mit den Rechten des Benutzers "debian-tor" gesendet worden sind, werden ohne Paketmanipulation durchgereicht. Damit Netzwerkverkehr, der an private bzw. lokale Netzwerke gerichtet ist, nicht durch Tor in die Welt geleitet wird, muss die NAT-Abarbeitung entsprechender Pakete abgebrochen werden, bevor diese Pakete durch die folgende iptables-Regel an den transparenten Tor-Proxy geleitet werden würden. Alle anderen TCP-Pakete und UDP-Pakete mit dem Zielport 53 werden an die lokale loopback-Schnittstelle umgeleitet. (für eine Übersicht über private/lokale Netzwerkadressen siehe private IP-Adressen)

Diese iptables-Konfiguration wird in die Datei /etc/iptables.rules abgespeichert. Da in diesem Artikel davon ausgegangen wird, dass die Ubuntu-Instanz in einer VM läuft, wird die /etc/network/interfaces-Konfiguration überschrieben und durch eine neue Konfiguration der Netzwerkschnittstellen lo und eth0 ersetzt; dabei wird unter anderem festgelegt, dass vor jeder Aktivierung der Netzwerkschnittstelle eth0 die abgespeicherte iptables-Konfiguration geladen wird.

Der Tor interne transparente Proxy wird aktiviert und an Port 9040 gebunden. Durch das Setzen von "AutomapHostsOnResolve" werden die Top-Level-Domains ".exit" und ".onion" durch einen Tor internen Mechanismus aufgelöst und auf unbenutzte IP-Adressen aus dem Bereich 127.192.0.0/10 (siehe man torrc "VirtualAddrNetwork") abgebildet. Die iptables-Regeln leiten folglich Anfragen an IP-Adressen aus diesem Bereich an den lokalen transparenten Proxy um.

Mit "supersede domain-name-servers" wird der DHCP-Client angewiesen, immer die angegebene IP-Adresse für den Nameserver zu benutzen, unabhängig davon, was der DHCP-Server antwortet.

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 {en}).

Weitere Gefahrenhinweise:

ubuntuusers.local › WikiVM basierende Anonymisierung