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

HELLO HELLO

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.

Ethereum auf Docker

HELLO HELLO

 

Die Ethereum Clients, wie hier geth, entwickeln sich derzeit rasend schnell. So schnell, das die Anleitung hier auch schon nicht mehr aktuell ist. Mit der aktuellen geth Version 1.5.9 kann Alpine hier nicht mehr als Basis genutzt werden. Es wird eine libusb Library benötigt die es jedoch unter UBUNTU gibt. Nachteil ist, das nun das neue Zielimage 230MB groß geworden ist.

 

Blockchain ist derzeit ein top aktuelles Thema. Banken, Versicherungen, Internet der Dinge, Energie- und Verkehrsunternehmen versuchen sich an dem Thema.
Einen ersten verständlichen Erklärungsversuch findet man hier:

https://www.it-finanzmagazin.de/

und auch eine sehr gute Zusammenfassung hier:

http://kingpassive.com/what-is-ethereum

Was man damit alles machen kann scheint schon phantastisch. Doch was wirklich dran ist und welche Möglichkeiten damit eröffnen zeigt sich erst im ersten praktischen Einsatz.
Was man dazu braucht ? Eine private Blockchain die hier mit Hilfe von Docker auf einem Raspberry Pi Cluster erzeugt wird.

Docker Image erstellen

Damit Ethereum genutzt werden kann wird zunächst ein Ethereum Client benötigt. Dieser wird hier in einem Docker Image erstellt und läuft später im Raspberry Pi Cluster.

Damit das neue Image möglichst klein gehalten wird, erfolgt die Erstellung in einem RUN Step. So bleibt das neue Image bei < 60MB ! Von Versuchen, das Source Verzeichnis mit ADD in das Image zu Linken kann abgeraten werden. Alle Versuche landen bei über 700MB.

Zur Erstellung folgenden Inhalt in das File „Dockerfile-alpine“ kopieren:

FROM alpine:3.3

RUN apk update && \
apk add git go gcc make musl-dev nano && \
git clone https://github.com/ethereum/go-ethereum && \
cd go-ethereum && \
make geth && \
mv build/bin/geth / && \
apk del gcc go make musl-dev && \
rm -rf /go-ethereum && \
rm -rf /var/cache/apk/*

#EXPOSE 8545
#EXPOSE 30303

ENTRYPOINT /bin/sh

(Alternative ist zu empfehlen, ein eigenes Basis Image zu erstellen als ein Image zu Docker Hub zu laden)

Das Image dann mit

docker build -f Dockerfile-alpine -t micsen/ethereum-alpine:v1 .

erstellen und zum Test einmal starten mit

docker run -it micsen/ethereum-alpine:v1

Im Prompt den eigentlichen Ethereum Client mit „./geth“ starten:

Das Docker Image besitzt nun den benötigten Ethereum Client. Damit dieses Image nun im gesamten LAN zur Verfügung steht muß es noch um die Server Adresse umbenannt und in die Registry geladen werden:
(Dieser Schritt kann übersprungen werden, wenn man das Image nicht auf einem anderen System zur Verfügung stellen will.)

docker tag micsen/ethereum-alpine:v1  <REG SERVER>:<PORT>/ethereum-alpine:v1

docker push <REG SERVER>:<PORT>/ethereum-alpine:v1

Der letzte Aufruf transportiert schließlich das Docker Image in das private Registry und ist dann LAN weit zu erreichen. Weitere Schritte sind nun auf dem gleicher Server oder auf einem andere sog. Node durchzuführen.

Erzeugen privater Blockchains

Zum erzeugen privater Blockchains wird ein allererster Block ‚0‘ erzeugt, dieser sog. Genesis Block wird wie folgt definiert:

{„nonce“: „0x0000000000000068“,
„mixhash“: „0x0000000000000000000000000000000000000000000000000000000000000000“,
„difficulty“: „0x4000“,
„alloc“: {},
„coinbase“: „0x0000000000000000000000000000000000000000“,
„timestamp“: „0x00“,
„parentHash“: „0x0000000000000000000000000000000000000000000000000000000000000000“,
„extraData“: „Custom Ethereum Genesis Block“,
„gasLimit“: „0xffffffff“}

Dies Daten in einer einfachen Textdatei mit dem Namen genesis.json speichern.

Zunächst wird ein neues Verzeichnis benötigt in der die privaten Ethereum Daten gespeichert werden so. Diese liegen bei mir in einem Netzlaufwerk welches mit

sudo mount -t nfs 10.0.0.150:/nfs/ethereum/ /var/ethereum

netzwerkseitig gemountet wird.

Der eigentliche Container in dem der Ethereum Client läuft wird gestartet mit

docker run -it -v /var/ethereum/mychain/:/ethData -v /home/pirate/ethereum/:/root/ dockerserver:5000/ethereum-alpine:v1

oder mit Ports

docker run -it -v /var/ethereum/mychain/:/ethData -v /home/pirate/ethereum/:/root/ -p 8545:8545 -p 30303:30303  dockerserver:5000/ethereum-alpine:v1

oder allgemein

docker run -it -v <HOST PATH>:/ethData -v <LOCAL PATH>:/root/ -p <LOCAL PORT>:<CONTAINER PORT> ethereum-alpine:v1

 

Hierbei wird das gemountete ethData Verzeichnis  und das lokale Verzeichnis mit dem Container verbunden. Nach dem Start erscheint nur eine Bash Aufforderung.

Um die lästige Eingabe des Passworts zu vermeiden wird ein Flat Password-File benötigt. Diese einfach unter dem privaten Ethereum Verzeichnis erstellt:

mkdir /ethData/etc
sudo echo dasganzsollgeheimsein123!  > /ethData/etc/passwordfile

Der Konto (Konto-Hash) für das hinterlegte Passwort wir dann mit

/geth –datadir /ethData \
–password /ethData/etc/passwordfile \
account new

erstellt.

Wichtig hier ist die Angabe des Data Directorys. Dieses ist durch den Container Aufruf in das entsprechende Verzeichnis gemountet. Daher ist innerhalb des Container hier immer /ethData anzusprechen. Dies vereinfacht später die Nutzung unterschiedlicher private und public Ethereum Blockchains. Entsprechendes gilt auch für den Aufruf für die Console:

 geth –datadir /ethData –dev –nodiscover \
–mine –minerthreads 1 –maxpeers 0 –verbosity 3 \
–unlock 0 –password /ethData/etc/passwordfile \
–rpc console

Nach dem Aufruf folgt:

und kurze Zeit später wird bereits private Ether erzeugt:

mit

balance = web3.fromWei(eth.getBalance(eth.accounts[0]), „ether“);

wird das geschürfte in der Währung Ether ausgegeben.

Nach 30min waren dies schon 450 Ether. Dies sind private Ether die nur für den Blockchain Besitzer einen Wert haben !

In diesem Fall zum erstellen erster Contract Apps.

http://solidity.readthedocs.io/en/latest/

https://de.wikipedia.org/wiki/Solidity

http://dapps.ethercasts.com/

 

https://blog.ethereum.org/2016/07/12/build-server-less-applications-mist/

 

 

Neue Docker Version V1.13.0 für Raspberry (ARMv7) erstellen

HELLO HELLO

Das Team um Docker hat eine neue Version veröffentlicht. Neben vielen Bugfixes gibt es auch einige Erweiterungen. Genauere Informationen findet man auf der Docker

https://github.com/docker/docker/releases

Das Problem ist, das es aktuell keine Debian Paket (z.b. für Raspbian) gibt aus der man Docker für die aktuelle Version installieren kann. Derzeit ist in den offiziellen Debian (Jessie) Paketen nur die Version 1.10.3, build enthalten.

Also muss man das Debian-Paket hier selber erstellen um in den Genuss der aktuellsten Version zu kommen. Alles was man dafür braucht ist ein lauffähigen Raspberry Pi 3 .Version 2 geht auch, aber dauert leider etwas länger. Das weitere Vorgehen sieht dann wie folgt aus:

Vorher jedoch auch das lokale System auf einen aktuellen Stand bringen mit:

sudo apt-get update

Aktuelle Version unter https://github.com/docker/docker.git prüfen. Derzeit aktuell ist die Version 1.13.0.

Neues Arbeitsverzeichnis Verzeichnis erstellen:

mkdir docker13
cd docker13

Um die entsprechenden Source auf den Raspberry aus dem GIT Repository zu kopieren, klont man das Docker Quellen Verzeichnis mit:

git clone https://github.com/docker/docker.git
cd docker

Das jeweilige release, hier V1.13.0 abrufen:

git checkout v1.13.0

Die anstehende Erstellung der Pakete kann hier im nächsten Schritt mehrere Stunden dauern. Da meine Server alle im Headless Betrieb laufen, wäre es tragisch, wenn nach einer Zeit die Terminal Session automatisch abgemeldet wird, oder der Laptop hier kein Strom mehr hat.

Aus diesem Grund startet man screen welches eine Session als Daemon startet, die nicht beendet wird wenn die Sitzung stoppt. Dazu einfach

screen

aufrufen. Wenn dies noch nicht installiert ist mit „sudo apt-get install screen“ installieren.

Nun die Source übersetzen und das Installation Paket erstellen lassen. Dies erfolgt fast schon langweilig automatisch mit:

make deb

Hier nur als Randnotiz. Die Docker Erstellung selber läuft in einem Docker Container ab. D.h. alle benötigten Werkzeuge usw. werden automatisch in den Container geladen und belasten nicht zusätzlich die eigene Entwicklungsumgebung. Lediglich ausreichend Speicher sollte man zur Verfügung stellen.

Wer mag, kann sich nun die Ausgaben ansehen und lernen. Alternativ kann mit der Tastenkombination STR (gedrückt halten!) A und dann D drücken. Dann läuft die Sitzung im Hintergrund weiter. Die Erstellung kann bis zu 4 Stunden auf dem Raspberry Pi 3 dauern. Später die Session wieder mit

screen -r

die Sitzung öffnen um zu prüfen wie weit die Erstellung gekommen ist.

Ist die Erstellung abgeschlossen befinden sich unter „docker13/docker/bundles/1.13.0/build-deb/debian-jessie“ die Debian Installationspakete:

Dieses wird mit

 sudo dpkg -i docker-engine_1.13.0-0~debian-jessie_armhf.deb

auf das lokale System installiert. Die Installation wir jedoch ggf. fehlschlagen, da ein Paket zusätzlich erwartet wird:

$ sudo dpkg -i docker-engine_1.13.0-0~debian-jessie_armhf.deb
(Reading database … 20379 files and directories currently installed.)
Preparing to unpack docker-engine_1.13.0-0~debian-jessie_armhf.deb …
Unpacking docker-engine (1.13.0-0~debian-jessie) over (1.12.5-0~raspbian-jessie) …
dpkg: dependency problems prevent configuration of docker-engine:
docker-engine depends on libltdl7 (>= 2.4.2); however:
Package libltdl7 is not installed.

dpkg: error processing package docker-engine (–install):
dependency problems – leaving unconfigured
Processing triggers for systemd (215-17+deb8u6) …
Processing triggers for man-db (2.7.0.2-5) …
^Cdpkg: error processing package man-db (–install):
subprocess installed post-installation script was interrupted
Errors were encountered while processing:
docker-engine
man-db

Um das fehlende Paket zu installieren muß nun noch

sudo apt-get install libltdl7

ausgeführt werden.

Dann sollte hier auch mit

 sudo dpkg -i docker-engine_1.13.0-0~debian-jessie_armhf.deb

die Installation erfolgreich sein:

Was bleibt ist neben diesem DockerServer auch seine Swarm-Nodes zu aktualisieren. Dies klappte auch bei 4 von 5 Nodes. Vermute ein Node hat hier die falsche Kernel Version, warum das prüfe ich noch:

Update 24.01.2017:

Tatsächlich gab es ein Problem beim Upgrade. Hier wurde auf einem Node ein Kernel ausgewählt, der kein overlay erlaubte. So wurde einfach der Node neu aus dem Master kopiert und neu gestartet. Nach dem Update/Upgrade lief auch dieser Node mit 1.13.0.

 

Tor goes Docker

HELLO HELLO

Tor (The Onion Routing) ist eine Netzwerk das zur Anonymisierung eingesetzt wird. Dafür wird als Transport das bekannte Internet genutzt.
Nutz man im Internet eine Verbindung zu einem Server, um z.B. eine Internet Seite abzurufen, erkennt dieser Server die IP Adresse und kann sehr wohl Rückschlüsse auf Herkunftsland und sogar Stadt / Land ziehen. Verschlüsselt hier der Web-Server die Anfrage nicht, kann man im jeweiligen Netzwerk nicht nur den Nutzer der Seite identifizieren, sondern auch welcher Inhalt abgerufen wird.

Na, wer interessiert sich schon dafür, wie of ich die bild.de aufrufe ? Keiner. Aber wenn man sich noch aktiv als Menschenrechtler oder Journalist betätigt kann man hier große Probleme bekommen. Ohne sicheres und freies Internet, wird es keine freie Meinungsäußerung mehr geben. Grade in diesen Zeiten, wo jeder seine Halbwahrheiten in den Dunstkreis des Netzes blasen kann, fällt das schwer. Aber Demokratie kann auch schmerzen.

Tor schützt also gegen Aufdeckung, sei es beim Browsen im Netz, für Instant Messaging (Twitter, FB, Hangout usw), IRC, E-Mail oder auch bei P2P. Dabei wird der Datenverkehr zufällig über mehrere Tor Stationen geleitet. Wie bei „stiller Post“ wird dann jeweils immer nur der nächste Router angesprochen, nie direkt der Ziel Server. Der erste Tor-Router „kennt“ also noch den Aufrufer, der nächste und alle weiteren Router ist der Aufrufer unbekannt. Der Zielserver kennt dann nur noch die IP des sog. Exit Routers. Nach 10 Minuten wird dann auch wieder eine neue Route durch das Tor Netzwerk aufgebaut.

Derzeit unterstützen knapp 7.000 Router weltweit dieses Netzwerk. Diese Router bestehen aus einer Software der Kontakt ins Tor Netzwerk aufbaut und Verbindungen entgegennimmt und wieder weiterleitet.

Um diese Netzwerk zu Unterstützen gibt

man ein Teil seiner Internet Ressourcen an das Tor Netzwerk ab und lässt dazu einen Tor Router mitlaufen. Blöd, das dieser Laptop oder Rechner erheblich Strom verbraucht.

Jetzt kommt Docker-Cluster auf Raspberry Pi Rechner zum Einsatz. Erstellt man sich ein Tor Image kann dies einfach auf den Nodes mitlaufen. Tor befindet sich in einer gesicherten Umgebung, verbraucht wenig Strom und ist ausfallsicher.

Man kann sich dazu leicht aus dem Docker-Hub ein entsprechendes Images laden und ausführen. Selbst für ARM Prozessoren gibt es fertige Images. Wenn man jedoch die jeweils aktuellste Tor Version im Einsatz haben will, muß man selber zum Compiler greifen und sich den Tor Server anhand der Quellen erstellen. Vorteil ist dabei, man weiß das ausschließlich Tor im Container läuft und sonst nichts.

Nach kurzer Recherche und einem Abend arbeit war es soweit. Neben dem eigentlichen Tor Router habe ich zusätzlich ein Image erstellt, was nur zur Erstellung des Tor Servers dient. Bei einer neuen Version braucht man so nicht wieder die Entwicklung Umgebung herstellen. Nach knapp 30min hat man eine lauffähige  und aktualisierte Version die dann im eigentlichen Tor-Image kopiert wird. Damit ist der eigentliche Tor Router-Image (Alpine Basis) nur 25MB groß.

Seit gestern Abend läuft nun der Tor Server im Bridge-Mode. D.h. er nimmt Anfragen entgegen und sendet diese dann wieder weiter ohne den ursprünglichen Absender noch das Ziel zu kennen. Um das Netz sicherer zu machen benötigt man eigentlich noch viel mehr Bridge Router.

Das How-To dazu erfolgt in den nächsten Tagen dazu hier auf der Seite.

Update: 22.01.2016
Die Download und Upload Raten sind sehr, sehr niedrig, so das man annimmt, dass irgendetwas falsch ist. Dem ist jedoch nicht so. Als neuer Node, und das ist der gerade erstellte, durchläuft dieser eine Staging. Die ersten 0-3 Tage kommen nur gelegentlich inbound/outbound Verbindungen zustande. Erst dann, also nach 3 Tagen bis 8 Tagen, erhöht sich der Traffic. In dieser Zeit wird der Datendurchsatz gemessen. Dann nach 8-68 Tagen bekommt der neue Node mehr Traffic und nach 68 Tagen ist dieser für das Tor Netzwerk als stabil anzusehen:

https://blog.torproject.org/blog/lifecycle-of-a-new-relay

Aktuell: Download

 und Upload