Ein Tor im Hafen – Tor Server mit Docker erstellen und betreiben

Vorbemerkung

Update: Aktuelle Version läuft nun mit 0.3.1.9 (17.12.2017)
Nachtrag: ARM Monitor läuft nun unter dem Namen nxy (https://nyx.torproject.org/) und wird noch später hier beschrieben

Wer Tor einsetzt sollte sich vorab um die Funktionsweise, wie Einstellungen usw. aber auch um die Risiken kümmern und bewusst sein. Im weiteren Text wird nicht explizit auf Gefahren hingewiesen da vorausgesetzt wird das diese bekannt sind !

Dazu noch ein Link:

http://www.golem.de/news/anonymisierung-zur-sicherheit-den-eigenen-tor-knoten-betreiben-1506-114438.html

und natürlich die Tor Homepage:

https://www.torproject.org/index.html.en

Wer sich weiter für Privacy im Internet interessiert dem ist folgender Link hilfreich:
https://www.privacy-handbuch.de/handbuch_22.htm

Weiterhin macht es unter Docker KEINEN Sinn und ist ggf. gefährlich mehr als einen Tor-Server auf einer IP / Subnet zu betreiben. Angreifer können hier u.U. eine Verbindung „kurzschließen“ weil der Entry oder Exit Knoten mit einem Mittel-Knoten auf dem gleichen Server befinden. Also diesen neuen Container nicht im Swarm 200x starten !

Warum dann Tor im Docker ? Weil es geht !
Und weil es im Swarm Betrieb ausfallsicherer ist und u.U. auch sicherer für das eigene Netzwerk, da unklar von außen ist welcher Traffic aus dem Tor-Browser kommt und welcher aus dem Tor Knoten. Beim letzten Punkt streiten sich jedoch die Gelehrten:

Wenn also alles klar ist, dann geht es weiter.

Tor erstellen

Zunächst werden hier die Sourcen benötigt. Zur Sicherheit werden keine bereits erstellen Binarys genutzt. Wer kann hier ausschließen, dass Backdoors ect. eingebaut wurden ? Bei den Sourcen kann dies natürlich auch geschehen, aber die Community kann dies schneller aufdecken.

Die Sourcen können bequem unter https://www.torproject.org/download/download.html.en bezogen werden. Hier auf <SOURCE CODE>klicken und das jeweils aktuelle Paket runterladen. Auf der Console geht das natürlich einfach mit:

(Warum auch immer finde ich das Tor System selber nicht im GitHub sondern nur auf der o.g. Internetseite)

mkdir tor-server
cd tor-server
wget https://www.torproject.org/dist/tor-0.3.1.9.tar.gz

Hier wird also im neuen Verzeichnis die derzeit gültige Version 0.3.1.9 geladen. Die aktuelle Version findet man im o.a. Link.

Zusätzlich installieren wir ein kleines Monitoring Tool in den Container.
Anonymizing Relay Monitor (arm) kann hier geladen werden:

https://www.torproject.org/projects/arm.html.en

bzw.

https://www.atagar.com/arm/download.php

Der Tar liegt dann hier:

https://www.atagar.com/arm/resources/static/arm-1.4.5.0.tar.bz2

Unter Linux:

wget https://www.atagar.com/arm/resources/static/arm-1.4.5.0.tar.bz2

Leider wird das Tool nicht mehr weiterentwickelt, aber es macht das was es soll und ist sehr klein.

Im weiteren wir folgende Vorgehensweise gewählt:

  1. Alpine Image als Basis
  2. Dockerfile.build welches ein neues Image erzeugt und die Sourcen übersetzt
  3. Kopieren der Executables & Files auf das Host System
  4. Kopieren der Executables & Files in ein neues Images.

Schritt 3&4 scheinen zunächst unnötig. Im neuen Image aus 2 liegt am Ende des Compile-Prozesses das tor als Executable vor. Ebenso das ARM Tool zur Anzeige des Tor Monitors. Warum also der Prozess aus diesem  Dateien heraus und dann wieder in ein neues Images hinein zu kopieren ?

Das Problem liegt daran, dass Docker Build keine Verzeichnis zum Build-Zeitpunkt einbinden kann. Dies liegt z.T. an der Architektur und ist auch gewollt. Wenn man nun innerhalb er Toolpath jedoch fertige Libs erstellen möchte, diese aber in anderen Containern nutzen will, kann man dies mit speziellen virtuellen Containern anstellen. Das würde jedoch hier unser kleines Projekt sprengen.

Das erste Dockerfile für unser Build heißt entsprechend auch: Dockerfile.build:

FROM alpine

# MOUNT LOCAL SOURCE PATH ! FULL
ARG TOR_SOURCE_FILE
ARG TOR_ARM_MONITOR_FILE

RUN apk update

# Add Tar
RUN apk upgrade
RUN apk add tar

# Add needed Libs for build
RUN apk add gcc g++ make libffi-dev openssl-dev libevent-dev

RUN mkdir /tor

#Arg from command line
COPY ${TOR_SOURCE_FILE} /tor/tor.tar.gz
COPY ${TOR_ARM_MONITOR_FILE} /tor/tormonitor.tar.bz2

WORKDIR /tor
RUN mkdir tor-source
RUN mkdir tor-monitor-source

#Extract Source to path
RUN tar -xvzf tor.tar.gz -C tor-source –strip-components 1
RUN tar -xvjf tor-monitor.tar.bz2 -C tor-monitor-source –strip
components 1
#Create TOR ARM Monitor
WORKDIR /tor/tor-monitor-source/
RUN ./install
#Grab ARM File
WORKDIR /tor
RUN cp /usr/bin/arm /usr/share/arm
RUN tar -zcvf tor-arm-monitor.tar.gz /usr/share/arm/
#CREATE TOR SERVER
WORKDIR /tor/tor-source/
RUN ./configure
RUN make

Das neue Build Image wird dann erzeugt mit

 docker build -f Dockerfile.build –build-arg TOR_SOURCE_FILE=tor-0.3.1.9.tar.gz –build-arg TOR_ARM_MONITOR_FILE=arm-1.4.5.0.tar.bz2 . -t  torbuilder

Hierbei wird das Build aufgerufen und das Dockerfile.build abgearbeitet. Die Parameter TOR_SOURCE_FILE beinhalten den File Namen des Source Paketes und TOR_ARM_MONITOR_FILE die Sourcen des Monitor Paketes.

Das Dockerfile zum Build sorgt für die korrekte Umgebung und arbeitet die Einzelschritte zur Erstellung ab. Nach dem Build Prozess wird das Image den Namen torbuilder tragen.

Im weiteren wird dieses Image genutzt um die Executables und weiterer Dateien zu kopieren. Dazu:

docker run -t –volume /<localhost path>/tor-server/:/local  –rm torbuilder /bin/cp /tor/tor-source/src/or/tor /local

Kopiert die Executable „tor“ nach /local. Wobei Local gemoutet wurde und sich auf das lokale Host Verzeichnis „tor-server“ bezieht.

 docker run -t –volume /<localhost path>/tor-server/:/local  –rm torbuilder /bin/cp /tor/tor-arm-monitor.tar.gz /local

Kopiert das im Container erzeugte ARM Tool, gezippt.

docker run -t –volume <localhost path>/tor-server/:/local  –rm torbuilder /bin/cp /tor/tor-source/src/config/geoip6 /local/config

docker run -t –volume  /<localhost path>/tor-server/:/local  –rm torbuilder /bin/cp /tor/tor-source/src/config/geoip /local/config

Bei den letzten beiden Schritten werden einfach noch Konfigurationen die Tor benötigt aus dem Tor Sourcen kopiert.

Doch nun liegen diese Dateien alle auf dem Host System. Dabei wird doch eigentlich ein Docker Image und damit ein Docker Container benötigt.

Dazu benötigen wir ein weiters Dockerfile welches die Daten in ein neues Image kopiert: Dockerfile.copy:

FROM alpine
RUN apk update
RUN apk upgrade
RUN apk add libevent-dev net-tools

#Create Tor Monitor

WORKDIR /tor
COPY tor-arm-monitor.tar.gz /tor
RUN tar -xvzf tor-arm-monitor.tar.gz -C /
RUN rm tor-arm-monitor.tar.gz
RUN cp /usr/share/arm/arm /usr/bin
RUN mkdir /torlog/

COPY tor /tor/tor
RUN chmod +x /tor/tor

#Copy Geo Files
RUN mkdir /usr/local/share/tor
COPY ./config/geoip /usr/local/share/tor
COPY ./config/geoip6 /usr/local/share/tor

ENTRYPOINT [„/bin/sh“]

Zur Erstellung des Eigentlichen Docker Images wird der Build nun mit:

 docker build -f Dockerfile.copy . -t raspitor

ausgeführt. Das neue Image mit den Tor File heißt nun raspitor.

Tor Server starten

(Siehe Hinweis oben !)

Zunächst wird das Image raspitor im Container gestartet.

docker run -t -i -p 9035:9035 -p 9030:9030 -v <localhost path>/config/:/torconfig raspitor

Port 9035 und 9030
Dazu müssen die Port 9035 und 9030 freigegeben werden. Damit ist der Container von außen zu erreichen. Dies bedeutet natürlich auch, dass diese Ports auch in der Firewall des Internet Routers freigeschaltet werden.

Zusätzlich werden die lokalen Host Pfade in den Container gemountet und sind damit im Container verfügbar.

<localhost path>/config
Beinhaltet die Konfigurationsdatei. Diese liegt nicht im Container sondern lokal. Hat den Vorteil, dass diese nicht bei jedem Update / Neuerstellung des Images wieder in den Container kopiert wird. Erreichbar im Container unter /torconfig

Nach dem starten des Containers passiert zunächst einmal wenig. Die Shell meldet sich mit /tor #

Mit

/tor # ./tor -v
May 01 05:57:53.305 [notice] Tor 0.3.0.6 (git-47d2e4f06ec26a79) running on Linux with Libevent 2.0.22-stable, OpenSSL 1.0.2k and Zlib 1.2.8.
May 01 05:57:53.305 [notice] Tor can’t help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning

wird geprüft ob die richtige Version hier gestartet wurde. In diesem Fall Version Tor 0.3.0.6 und auch der Hinweis:

Tor can’t help you if you use it wrong!

Damit wir später mit dem TOR Tool ARM auf den Tor Server zugreifen können muß noch ein Hash/Password erstellt werden. Dazu hier zunächst :

/tor # ./tor –hash-password „Das_Ist_Geheim#AB12“
May 01 06:01:15.366 [warn] You are running Tor as root. You don’t need to, and you probably shouldn’t.
16:75E29300355323E2603D088C84D8701142B8255ED526E2A527113D3B84

16:A02606E546817632605C481E55CFFF9316C4EBE2CEC74A9ABF4B3BEC31

Hierbei wird der erzeugte Hash für die Konfiguration benötigt.

Mit Exit wird die Session und damit auch der Container beendet.

Tor Server Konfiguration

Im Internet finden sich einige Beispiel für entsprechende Konfigurationsdateien. An dieser Stelle eben auch ein Beispiel welches an die jeweiligen Ansprüche angepasst werden sollte und muss ! Eine Anleitung und weitere Erklärung findet man hier https://www.torproject.org/docs/tor-manual.html.en

Log notice file /torlog/notices.log
RunAsDaemon 1
ControlPort 127.0.0.1:9044
#ControlListenAddress 0.0.0.0
HashedControlPassword 16:75E29300355323E2603D088C84D8701142B8255ED526E2A527113D3B84
ORPort 9035
#SocksPort 9050 ## Default ist 9050
Nickname FreeSpeech
RelayBandwidthRate 512 KB
RelayBandwidthBurst 1280 KB
#
NewCircuitPeriod 600
MaxCircuitDirtiness 600
ContactInfo MyMail AT protonmail com
DirPort 9030

ExitPolicy reject *:*

DisableDebuggerAttachment 1
AvoidDiskWrites 1
MaxMemInQueues 300 MB

 

Log notice file /torlog/notices.log
Speicherort des Log Files

RunAsDaemon 1
Bei 1 wird der Tor Server im Hintergrund ausgeführt.

ControlPort 127.0.0.1:904
Um Tor von außen zu kontrolieren wird die genutze IP und ein frei gewählter Port genutzt. Hier ist zu sehen, dass dieser Port außerhalb des Containers nicht erreichbar ist, da dieser beim Start des Containers auch nicht angegeben ist.

HashedControlPassword 16:75E29300355323E2603D088C84D8701142B8255ED526E2A527113D3B84Das verhashte Passwort um auf die Tor Server, hier ARM,  zuzugreifen.

Nickname FreeSpeech
Ein frei gewählter Name

RelayBandwidthRate 512 KB
Genutzte Bandbreite des eigenen Netzes. Hier werden in beide Richtungen 512 KB/s freigegeben

RelayBandwidthBurst 1280 KB
Max. Bandbreite die überhaupt genutz werden darf. Hier sind das 256KB/s über der möglichen Bandbreite.

NewCircuitPeriod 60
Anzahl Sekunden in der ein neue Verbindung hergestellt wird. Default sind hier 30sec

MaxCircuitDirtiness 600
Max. alter in Sekunden einer Verbindung die genutzt werden darf.

#DirPortFrontPage /torconfig/tor-exit-notice.html
Hier kann eine HTML Seite angegeben werden die Infos zu diesem Knoten angiebt. Namen usw. sollte man hier natürlich nicht angeben.

ContactInfo <meine email> AT protonmail com
Sollte es zu Störungen kommen geben viele Betreiber hier eine eMail Adresse an. Diese sollte natürlich keinen Rückschluß auf den Konten Betreiber geben ! Zum empfehlen ist hier Protonmail.

DirPort 9030
Verzeichnisdienst der über den Port 9030 angeboten wird.

ExitPolicy reject *:*
Der wichtigste Eintrag über den man sich Gedanken machen muß. Der Eintrag bedeutet, dass KEINE Verbindung das verschlüsselte Tor Netzwerk über diesen Anschluß verlässt.
Für alle anderen Einstellung hier, bitte das o.a. Manual lesen und verstehen !

DisableDebuggerAttachment 1
Verhindert die Erstellung von Core Dump Files.

AvoidDiskWrites 1
Damit werden unötigen Zugriffe auf das Dateisystem verhindert. Dies ist bei SD Basierten Systemen wie Raspberry Pi usw. sinvoll um die SD zu schonen.

MaxMemInQueues 300 MB
Reservierter Speicher für dan Tor Server. Dieser sollte nicht zu klein gewählt werden.

Einige Einstellung werden auch als default gesetzt. Welche sind dem Manual zu entnehmen.

Datei torrc wird dann auf dem Host lokal abgelegt im Verzeichnis <localhost path>/config/

Tor Server starten

Zunächst muss erneut der Container mit dem Image raspitor gestartet werden jedoch mit einem Unterschied:

docker run -t -i -p 9035:9035 -p 9030:9030 -v <localhost path>/config/:/torconfig -v <loclhost past>/root/:/root raspitor

<loclhost past>/root
Hier wird das Home Verzeichnis des Root Users des Containers auf ein lokales Verzeichnis des Host gemountet. Das bedeutet, dass alle Dateien die sich im Container Verzeichnis /root/ befinden nun auf dem Host gespeichert werden. Warum ?
Der Tor Server speichert sich einen sog. Fingerprint ab, um sicherzustellen, dass bei Restart es sich genau um diesen Server handelt. Je länger ein Server Uptime ist, desto mehr Traffic bekommt diese, da er als stabil gilt. Zum Status des Tor Servers später noch mehr.

Jedoch werden alle Dateien und Änderungen nach End Of Life des Container gelöscht. Um genau dies zu verhindern werden diese Daten nach außen geführt. Beim stoppen/starten des Containers sind also immer die gleichen Dateien im Verzeichnis root vorhanden. Ebenso können diese Dateien auch in einem separatem Docker Storage Image gespeichert werden. Dies wurde nicht beim ersten Aufruf durchgeführt, damit das Klarschrift Kennwort sich nicht in der Console History wiederfindet.

Der eigentliche Tor-Server wird nun mit

./tor -f /torconfig/torrc

gestartet.

/tor # ./tor -f /torconfig/torrc
May 01 08:43:04.076 [notice] Tor 0.3.0.6 (git-47d2e4f06ec26a79) running on Linux with Libevent 2.0.22-stable, OpenSSL 1.0.2k and Zlib 1.2.8.
May 01 08:43:04.076 [notice] Tor can’t help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
May 01 08:43:04.081 [notice] Read configuration file „/torconfig/torrc“.
May 01 08:43:04.118 [notice] Opening Socks listener on 127.0.0.1:9050
May 01 08:43:04.118 [notice] Opening Control listener on 127.0.0.1:9044
May 01 08:43:04.118 [notice] Opening OR listener on 0.0.0.0:9035
May 01 08:43:04.118 [notice] Opening Directory listener on 0.0.0.0:9030

Mit /tor # tail -f /torlog/notices.log kann man den Start des Tor Servers verfolgen. Der erste Start kann dabei durchaus mehrere Minuten dauern, weil noch keine Directory Informationen über andere Knoten, mit dem man verbunden wird, vorliegen. Dies wird jedoch auch angezeigt.

May 01 08:45:13.000 [notice] Starting with guard context „default“
May 01 08:45:13.000 [notice] Bootstrapped 80%: Connecting to the Tor network
May 01 08:45:14.000 [notice] Bootstrapped 85%: Finishing handshake with first hop
May 01 08:45:15.000 [notice] Bootstrapped 90%: Establishing a Tor circuit
May 01 08:45:16.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
May 01 08:45:16.000 [notice] Bootstrapped 100%: Done

Mehr passiert hier erstmal nicht.

Tor Status

Um den Zustand des eignen Tor Servers zu prüfen wird nun ARM genutzt. Dazu

/tor # arm -i 127.0.0.1:9044

ARM starten. Hier wird dann noch das Passwort benötigt.

Es wird die Tor-Nutzung des Servers angezeigt.

Mit den Tasten Cursor Tasten [Rechts] / [Links] können die Panel gewechselt werden:

Anzeige der Connections.

Weiter kann man sich die Konfiguration ansehen und mit der Taste [m] das Menü anzeigen lassen.

Die Ausgabe sieht ein wenig fehlerhaft aus. Dies liegt am falschen Charset, der im Container noch nicht korrekt eingestellt wurde.

Mit der Taste [q] gefolgt von der Taste [q] wird ARM Monitor gestoppt.

Jetzt jedoch den Container nicht mit exit verlassen. Dies würde den Container zerstören als auch Tor Server sofort stoppen.

Mit der Taste [STRG]-[P] gefolgt von [STRG]-[Q] wird die Console des Container verlassen, ohne das dieser beendet wird.

Später kann man den laufenden Container mit

docker ps

prüfen ob dieser noch läuft und mit

docker attach <ContainerID>

erneut wieder aufrufen.

Möchte man außerhalb des Containers den Zustand des eigene  Servers prüfen kann man dies leicht mit einer der vielen Tor Status Seiten erledigen. Hier eine kleine Auswahl:

https://torstatus.rueckgr.at/

https://torstatus.blutmagie.de/

https://torflow.uncharted.software/

Nach dem ersten Aufruf kann es jedoch mehrere Stunden dauern bevor der eigene Server hier erscheint. Dieser wird mit dem Namen, der in der Konfiguration unter Nickname angegeben wurde, in der Liste geführt.

Weiterhin auch hier nochmal der Hinweis, sich unter unter https://blog.torproject.org/blog stehts auf dem laufenden zu halten.

 

Was noch zu tun ist:

  • Konfiguration Verzeichnis und Root-Home auf NFS Server speichern, damit von allen Docker Servern aus hier der Container gestartet werden kann.
  • Alternatives Monitoring Tool zu ARM finden und einbinden.
Dieser Beitrag wurde unter Docker & Container veröffentlicht. Setzen Sie ein Lesezeichen auf den Permalink.

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.