[[Vorlage(Getestet, bionic)]]

[[Vorlage(Fortgeschritten)]]

[[Inhaltsverzeichnis()]]

Dieser Artikel beschreibt die [wikipedia:Anonymität_im_Internet:Anonymisierung] des gesamten Netzwerkverkehrs einer Ubuntu-Instanz innerhalb einer [wikipedia:Virtuelle_Maschine: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 "[:Tor/Gefahren#DNS-Leaking: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.


{{{#!vorlage Hinweis
Alle nachfolgenden Instruktionen müssen innerhalb der virtualisierten Instanz mit Root-Rechten ausgeführt werden.
}}}

{{{#!vorlage Warnung
Die Schnittstellenkonfiguration für das Netzwerk der virtualisierten Instanz wird überschrieben!
}}}

Zunächst müssen die Pakete tor und polipo installiert werden:
{{{#!vorlage Paketinstallation
polipo, universe
tor, universe
}}}

Anschließend muss noch die Konfiguration von polipo angepasst werden:

{{{#!code bash
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:

{{{#!code bash
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:]).

{{{#!code bash
#!/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 [wikipedia:Proxy_(Rechnernetz)#Transparenter_Proxy: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.

{{{#!vorlage Hinweis
Alle nachfolgenden Instruktionen müssen innerhalb der virtualisierten Instanz mit Root-Rechten ausgeführt werden.
}}}

{{{#!vorlage Warnung
Die Schnittstellenkonfiguration für das Netzwerk der virtualisierten Instanz wird überschrieben!
}}}

Zunächst muss tor installiert werden:
{{{#!vorlage Paketinstallation
tor, universe
}}}

Anschließend muss noch die Konfiguration von tor angepasst werden:

{{{#!code bash
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:

{{{#!code bash
echo -e "\niface eth0 inet dhcp\n" >> /etc/network/interfaces
}}}

Zur Absicherung wird iptables eingesetzt: 

{{{#!code bash
#!/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 [https://wiki.torproject.org/noreply/TheOnionRouter/TransparentProxy Tor Wiki - Transparently Routing Traffic Through Tor] {en}.


= 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. [github:jevinskie/TorVTL:TorVTL] {en}).

Weitere Gefahrenhinweise:
 * Besonders wird vor [:Tor/Gefahren#Boese-Exit-Nodes:"bösen" Exit-Nodes] gewarnt. 
 * Die Grenzen der von Tor erreichten Anonymität sind unter [https://www.torproject.org/docs/faq.html.en#WhatProtectionsDoesTorProvide Tor FAQ - What protections does Tor provide?] {en} aufgezeigt.
 * Es wird empfohlen, die erfolgreiche Umsetzung mit Hilfe von [https://check.torproject.org/?lang=de Testen, ob man mit Tor surft] {de} zu prüfen.

= Weiterführende Links =
== intern ==
 * [:Tor:]
 * [:Sicherheit/Anonym Surfen:]
== extern ==
 * [https://wiki.torproject.org/noreply/TheOnionRouter/TransparentProxy Tor Wiki - Transparently Routing Traffic Through Tor] {en}
 * [https://www.torproject.org/docs/faq.html.en#WhatProtectionsDoesTorProvide Tor FAQ - What protections does Tor provide?] {en}
 * [https://check.torproject.org/?lang=de Testen, ob man mit Tor surft] {de} 
 * [https://www.whonix.org/ Whonix - Anonymisierte VM der Tor-Community] {en}
 * 
# tag: Anonymität, Emulation und Virtualisierung, Sicherheit, Tor, Internet