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.

Inhaltsverzeichnis
  1. Einrichtung einer virtualisierten Ubuntu-I...
  2. Anonymisierung des Netzverkehrs
    1. Variante 1: socks- & http-Proxy als Gate...
    2. Variante 2: transparenter Proxy als Gate...
  3. Bewertung der Sicherheit
  4. Weiterführende Links
    1. intern
    2. extern

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:

Dagegen ergeben sich folgende Nachteile:

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 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:

Paketliste zum Kopieren:

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:

Paketliste zum Kopieren:

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:

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:

intern

extern