trusted
Anmeldungsdatum: 30. April 2011
Beiträge: 207
Wohnort: Deutschland 635
|
Hallo, habe auch gerade die zweite Variante mal getestet, von 3 versuchen hat einer funktioniert. Ich glaube man muss ein Update machen bevor man das Skript ausführt.
sry, für die falsch Meldung nach einem Neustart des Systems funktioniert es nicht mehr. LG
|
jake1776
Anmeldungsdatum: 10. März 2012
Beiträge: 86
|
Hallo, Ich finde den Artikel richtig gut! 👍
Würde es gut finden, wenn sich jemand bereit findet und ihn mal aktualisiert. Beispielsweise was mein Vorredner schon ansprach: gibt es bei (/ab) Precise Pangolin keine /etc/dhcp3/dhclient.conf mehr(?), wie ich von DNS Problembehebung (Abschnitt „Konfiguration-bis-Ubuntu-8-04“) entnehmen konnte... Vielen Dank
Jake
|
jake1776
Anmeldungsdatum: 10. März 2012
Beiträge: 86
|
Also damit es unter 12.04 funktioniert muss man statt: | 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
|
dass hier: | cp /etc/resolvconf/resolv.conf.d/head /etc/resolvconf/resolv.conf.d/head.backup-VM-based-anonymization
echo "nameserver 127.0.0.1" >> /etc/resolvconf/resolv.conf.d/head
|
schreiben... MfG
Jake
|
jake1776
Anmeldungsdatum: 10. März 2012
Beiträge: 86
|
Darf ich den Artikel jetzt einfach überarbeiten oder muss er erst in die Baustelle verschoben werden? MfG Jake
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29454
Wohnort: WW
|
Hallo, wenn die Zeile die einzige Änderung ist kannst du das so machen. Gruß, noisefloor
|
jake1776
Anmeldungsdatum: 10. März 2012
Beiträge: 86
|
Aber dann würde das Skript doch nicht mehr für Lucid Lynx funktionieren.
Oder ist das egal und ich nehme einfach das getestet für Lucid Lynx raus?
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29454
Wohnort: WW
|
Hallo,
Oder ist das egal und ich nehme einfach das getestet für Lucid Lynx raus?
Weder noch. Du fügst die Zeile _zusätzlich_ ein und schreibst halt noch, welche Version für welche Ubuntu-Version gilt. Der Rest vom Artikel gilt auch so für Precise? Dann kannst du bitte den "getestet" Tag direkt erweitern ☺ Gruß, noisefloor
|
DaGerba
Anmeldungsdatum: 15. Mai 2007
Beiträge: 16
|
SLXViper schrieb: Ich vermisse noch einen Hinweis, wie man die Umleitung über Tor zeitweise deaktivieren kann, bspw. um größere Updates zu fahren oder um größere Pakete zu installieren, ohne Ewigkeiten warten zu müssen.
Wäre nicht schlecht, wenn jemand etwas dazu schreiben könnte.
Hallo zusammen, die Frage mit den Updates beschäftigt mich auch. Nicht nur, dass es ewig dauert durchs TOR-Netzwerk, man sollte das Netzwerk auch nicht durch unnötig große Downloads belasten. Kann ich einfach vor Ausführung des Scriptes ein Backup der /etc/network/interfaces erstellen, das dann zurücksichern - natürlich erst, nachdem ich die neue /etc/network/interfaces auch wieder weggesichert habe. Dann einmal /etc/init.d/networking restart ausführen. Dann müsste ich doch wieder ohne den TOR-Proxy mit dem Internet verbunden sein. Kann flott updaten, anschließend wieder die /etc/network/interfaces mit dem Proxy zurücksichern, einmal /etc/init.d/networking restart und ich bin wieder vermummt. Müsste doch klappen so. Oder muss ich das Hin-und-Her-sicher-Spiel auch mit der /etc/iptables.rules machen? Kanns leider grade nicht testen, weil ich die VM noch garnicht aufgesetzt habe. Bin noch in der Planungsphase. Gruß
Michael
|
Hans9876543210
Anmeldungsdatum: 2. Januar 2011
Beiträge: 3741
|
Hallo, ich habe den Artikel etwas ergänzt bzw. umstrukturiert Verweise auf ältere Ubuntuversionen / Tor-Versionen entfernt für alle aktuellen LTS getestet iptables umgestellt ("Experteninfos" als Kommentare reingepackt) Verweis auf IPv6 eingestellt imho überflüssige Elemente rausgenommen
Freue mich über Feedback. Hier kommt der Vorschlag:
Dieser Artikel wurde für die folgenden
Ubuntu-Versionen getestet:
Du möchtest den Artikel für eine weitere Ubuntu-Version testen? Mitarbeit im Wiki ist immer willkommen! 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. Eine Ausnahme stellen DNS-Anfragen dar, die Tor über einen gesonderten DnsPort weiterleiten kann. 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 IPv4 Netzwerkverkehr die Instanz verlassen kann. Die Betrachtung von IPv6 erfolgt in diesem Artikel nicht. Zu Beginn sollte 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:
Befehl zum Installieren der Pakete:
sudo apt-get install polipo tor
Oder mit apturl installieren, Link: tor Anschließend muss noch die Konfiguration von polipo angepasst werden: | 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
## in 14.04 muss der Pfad des Logs angepasst werden
# echo 'logFile = /var/log/polipo/polipo.log' >> /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: | 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 geladen werden. 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 | #!/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
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
## bis 12.04 auskommentieren
# /etc/init.d/networking restart
# /etc/init.d/polipo restart
## ab 14.04 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 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. 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:
Befehl zum Installieren der Pakete:
Oder mit apturl installieren, Link: apt://tor Anschließend muss noch die Konfiguration von tor angepasst werden: | cp /etc/tor/torrc /etc/tor/torrc.backup
## bis 12.04 auskommentieren
# echo "VirtualAddrNetwork 172.16.0.0/12" > /etc/tor/torrc
## ab 14.04 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: | 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
66
67
68
69 | #!/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
## bis 12.04 auskommentieren
# /etc/init.d/networking restart
# /etc/init.d/tor restart
## ab 14.04 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:
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29454
Wohnort: WW
|
Hallo, ich habe dir den Artikel in die Baustelle verschoben, da kannst du alle Änderungen / Ergänzungen machen. Das Fertigstellungsdatum bitte bei Bedarf anpassen. Und bitte hier kurz posten, wenn du fertig bist. Gruß, noisefloor
|
Hans9876543210
Anmeldungsdatum: 2. Januar 2011
Beiträge: 3741
|
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29454
Wohnort: WW
|
Hallo, von der Syntax etc. her ist es ok, inhaltlich kann ich selber nichts dazu sagen. Wenn keine Einwände kommen, können wir den Artikel kommendes WE wieder zurück ins Wiki schieben. Gruß, noisefloor
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29454
Wohnort: WW
|
Hallo, Artikel ist wieder im Wiki, Danke für die Überarbeitung. Gruß, noisefloor
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29454
Wohnort: WW
|
Hallo, im Artikel steht 2x der Satz "# Schnittstellenbezeichnung ab 16.04 anpassen ". Wenn jemand diese VM basierende Anonymisierung unter Bionic oder neuer einsetzt wäre es schön, wenn das angepasst würde. Gruß, noisefloor
|