TOR: Viele wollen es, nur wenige machen es!

TOR: Viele wollen es, nur wenige machen es!

Nein, beim Schreiben der Überschrift hatte ich weder einen Krampf in der linken Hand noch stand meine Katze auf der Feststelltaste. Hier widme ich mich der Thematik TOR; die Kurzschreibweise von The Onion Router. Doch was heißt das?

Das, was die meisten vereinfacht als Internet kennen, ist das sogenannte Clearnet (auch: Clear Web, Surface Web oder Visible Web). Jeder Teilnehmer des Internets – die Server in den Rechenzentren, dein Smartphone während du unterwegs deine Lieblingsmusik streamst oder die Spielkonsole zu Hause – erhält eine IPv4 und/ oder IPv6-Adresse. Abgesehen von Sonderformen wie Carrier-grade NAT oder privaten IP-Adressbereichen ist jede IP-Adresse einmalig. Es wäre doch sehr ärgerlich, wenn du deine bestellte Pizza nie geliefert bekommst, weil das Haus im Nachbarsdorf dieselbe Adresse hat. Ähnlich funktioniert die Kommunikation in Netzwerken. Bei jeder Anfrage – sprich: beim Aufruf einer Website, beim Versand einer E-Mail, bei Online-Spielen – teilst du dem entfernten Server deine IP-Adresse mit. Glaubst du mir nicht? Öffne doch die Website myip.is. Die dort hinterlegte IP-Adresse ist nun auch meiner Server-Infrastruktur bekannt, weil du gerade diesen Artikel auf meiner Website liest.

Bereits die IP-Adresse ohne Zuhilfenahme der Informationen, die viele Browser mitsenden, verrät so manches über die Person hinter dem Bildschirm: Welche (Mutter)Sprache spricht der Mensch? Wo wohnt er ungefähr bzw. wo hält er sich auf? Mit VPN-Anbietern wie NordVPN oder CyberGhost lässt sich zwar die eigene IP-Adresse gegenüber Websites wie meiner verschleiern, doch von Anonymität kann nicht gesprochen werden, weil fortan der VPN-Dienstleister deine Identität exklusiv kennt.

So funktioniert TOR

Wie eingangs geschrieben, steht TOR für The Onion Router; der Name ist hier Programm. Wie bei einer Zwiebel mit mehreren Ringen wird jede Anfrage – sprich: du rufst eine Website auf – über mehrere Server geleitet. Im TOR-Fachjargon unterscheidet man zwischen zwei Arten von Nodes: middle relays und exit relays. Zwar gibt es auch bridges, doch die ignoriere ich ganz bewusst.

Exit Relays sind für das TOR-Netzwerk essentiell. Das Angebot ist überschaubar. Das hat vor allem rechtliche Hintergründe. Exit Relays sind jene Server, die letztendlich die Webinhalte aufrufen. Mögliche Straftaten, die über den Server laufen, werden zunächst auf den Server-Betreiber zurückgeführt. Zwar ist der Justiz die Funktionsweise von TOR nicht mehr völlig fremd, doch wer Schreiben von netten Abmahnanwälten oder eine Hausdurchsuchung vermeiden möchte, sollte insbesondere keinen Exit Relay über den heimischen DSL-Anschluss betreiben. Ob das vertraglich gestattet ist, beantworte ich in einem späteren Absatz.

Das Angebot an Middle Relays ist höher, doch hier gilt ausnahmsweise „viel hilft viel“ oder „mehr ist besser„. Wer die entsprechenden Server-Ressourcen hat, um einen performanten Middle Relay zu betreiben, sollte das unbedingt tun. Ein Middle Relay agiert innerhalb des TOR-Netzwerks, sodass auch darüber illegale Aktivitäten stattfinden können, doch fragt der Server niemals die Daten selbst an, sondern erhält sie lediglich vom Exit Relay oder einem weiteren Middle Relay.

Wer aufgrund fehlenden Know-Hows oder Sorge vor rechtlichen Konsequenzen kein Relay betreiben möchte, erhält dennoch Zugang zum Netzwerk über den TOR-Browser. Wer etwas Geld übrig hat, kann über eine Spende an das Projekt generell oder über eine Spende an Relay-Betreiber nachdenken.

TOR-Relay-Dienst selbst betreiben

Über eine Dauer von drei Wochen betrieb ich zeitweise zwei Middle Relays. Warum ich zwischenzeitlich schrieb und was ich dabei gelernt habe, erfährst du jetzt.

Das solltest du wissen

Solange es vermeidbar ist, wollte ich für meine Tests mit TOR kein weiteres Geld ausgeben. Daher habe ich zunächst auf meine bestehende öffentliche Server-Infrastruktur aufgebaut.

Als Hobby-ITler ist nicht jedes meiner Systeme gleich kritisch. Manche Services müssen dauerhaft erreichbar sein während andere Dienste ohnehin redundant konfiguriert sind, sodass die mögliche Downtime eines Hosts mich nicht negativ beeinflusst oder nur ein nice-to-have statt must-have sind. Zu den Hosts, die funktionieren müssen, zählt mein Webhost inklusive E-Mail-Server als auch meine Nextcloud. Bei E-Mail und Nextcloud kommt hinzu, dass dort Daten hinterlegt sind, die nicht für Dritte bestimmt sind. Somit habe ich über das Ausschlussverfahren den Host gewählt. Einige Tage später konnte ich beobachten, wie richtig und wichtig die Entscheidung war.

In einem englischsprachigen Blogpost wird der Lebenszyklus eines neuen TOR-Relays erklärt. Demnach wird es einige Tage dauern ehe das eigene Relay vom TOR-Netzwerk angenommen wird. Anfänglich habe ich die Verbindungen zu meinem Server regelmäßig beobachtet. Dann wurde es weniger bis ich es ganz ließ; ein Fehler. Ab dem zweiten Tag wurde mein Relay so sehr genutzt, sodass ich knapp zwei weitere Tage später über die Sperrung meines Servers per E-Mail informiert wurde. Die Entsperrung war kein Problem, auch wenn der Support wenig erfreut war, doch bis zur Entsperrung waren alle Services dieses Hosts offline.

Der zweite Host bei einem anderen Provider wurde bis zum Ende nie gesperrt, doch konnte ich mich plötzlich nicht mehr zu jeglichen Diensten auf dem Server verbinden. Grund war meine heimische Firewall. Mit dem UniFi Security Gateway lassen sich Verbindungen in das TOR-Netzwerk oder Verbindungen zu Servern, die im TOR-Netzwerk agieren, unterbinden. Im UniFi Controller im Menüpunkt Alarme heißt es: Threat Management Alarm 2: Misc Attack. Signatur ET TOR Known Tor Relay/Router (Not Exit) Node Traffic group 764. Von: XX.XXX.X.XX:443, auf: XXX.XXX.XXX.109:38014, Protokoll: TCP. Für das eigene Homelab kann das Problem mit Firewall-Ausnahmen oder der Deaktivierung des TOR-Verbots umgegangen werden, doch für die Netzwerke von Firmen wird das nicht funktionierten. Blöd, wenn über dieselbe IP-Adresse Websites und E-Mails oder die eigene Cloud laufen. Sobald mein Relay von metrics.torproject.org verschwand, haben auch die Firewall-Warnungen aufgehört.

Einen Hoster finden

Wer ein TOR-Relay/ -Node betreiben möchte, hat für dieses Vorhaben nicht die Qual der Wahl aus der enormen Bandbreite an Hosting Providern wählen zu dürfen. Grund ist, dass das TOR-Netzwerk unvermeidbar viel Traffic verursachen wird. Wer vermeiden möchte, dass ihm der Server früher oder später gekündigt wird, sollte einen Hoster finden, der das TOR-Hosting zumindest nicht explizit verbietet. Für einige namhafte Anbieter in Deutschland habe ich das bereits getan. Selbst wenn dein präferierter Anbieter nicht gelistet sein sollte, bietet die Liste entsprechene Anhaltspunkte, welche Begriffe relevant sein könnten.

STRATO: In den allgemeinen Geschäftsbedingungen unter Punkt 2 Leistungen der STRATO heißt es einerseits „Eine Nutzungsüberlassung von Servern (ganz oder teilweise) an anonyme Dritte ist untersagt.“ und „Eine Nutzung von Servern zur Bereitstellung von Anonymisierungsdiensten ist ausgeschlossen.“ Zwar lässt sich darüber streiten, ob man mit TOR seinen Server (teilweise) anonymen Dritten überlässt, doch mit dem Ausschluss von Anonymisierungsdiensten ist es das Aus für ein TOR-Node bei STRATO. Weiter heißt es: „Für einige zusätzliche Dienste entstehen STRATO Kosten, die wir an unsere Kunden in Form einer Servicegebühr weitergeben. Dabei handelt es sich um Dienste wie z.B. der Vertragsübergabe, der Reaktivierung eines Auftrags, oder des erneuten Rechnungsversands.“

Prepaid-Hoster.de: Zwei Server habe ich beim norddeutschen Unternehmen Prepaid-Hoster.de gemietet. Zwischenzeitlich war auch hier ein Middle Relay aktiv. Allerdings habe ich die Gewalt von TOR-Traffic unterschätzt, sodass es in den FAQ nun heißt: „Folgende Arten von Traffic sind nicht erlaubt: […] Traffic durch Tor-Nodes jeglicher Art“.

In den AGB von Hetzner lassen sich unter Punkt 5 „Administrationsrechte und -pflichten / Datensicherheit“ einige Anhaltspunkte finden, womit der TOR-Betrieb unterschwellig untersagt wird. So dürfen Kund:innen die „Integrität und Verfügbarkeit der Netze, Server und Daten Dritter nicht gefährde[n] werden. [Strikt untersagt sind] (d)DOS-Attacken […] offene Mail-Relays oder […] Systeme […], die diese Aktionen durchführen können.“ Außerdem sind „missbräuchliche und rechtswidrige Handlungen“ untersagt.

IONOS (1&1 SE) geht einen Schritt weiter. Dort sind die verbotenen Aktivitäten in den „Eingriffs- und Kündigungsrechte[n]“ gelistet. Namentlich genannt werden offene Mail-Relays und ähnliche Dienste, die den Spam-Versand ermöglichen. Darüber hinaus ist der „exzessive Verbrauch von Ressourcen“ mit dem expliziten Beispiel Netzwerk verboten.

Bei OVH habe ich nicht einmal in die AGB geschaut. Für einen anderen Beitrag habe ich auch dort einen vServer gemietet. Zwar konnte ich TOR problemlos installieren, doch die Verbindung zu meinem Server war nicht möglich. Selbst ein geänderter Port von 9001 auf 443 löste nicht das Problem. Welchen Port ich auch wählte, dieser Port hatte laut nmap den Status filtered. Um meine Software-Firewall als Fehlerquelle auszuschließen, habe ich ufw ganz abgeschaltet.

Auf das TOR-Hosting über den heimischen Internetanschluss gehe ich hier und jetzt nicht genauer ein. Für den Artikel „VPN: Der rechtliche Aspekt“ habe ich bereits die AGB von Telekom und Vodafone untersucht. Die Antworten lassen sich auf TOR übertragen.

Auch wenn derweil meine Middle Relays eingestellt sind, werde ich wohl auf lange Sicht ein TOR-Node beim Anbieter Netcup hochziehen. In den allgemeinen Geschäftsbedingen wird lediglich der E-Mail-Massenversand, Angebote für urheberrechtlich geschütztes Material oder Pornografie, Organisation von Extremismus und Aufrufe zur Gewalt, Mining von Cryptowährung sowie Dienste, die generell eine hohe Rechnerlast erzeugen, untersagt. Letzteres gilt allerdings nicht für virtuelle oder dedizierte Server. Im Netcup-Forum bestreiten Netcup-Mitarbeiter nicht den Betrieb eines Tor-Nodes, doch legen sie ihren Kunden das Spenden an bereits existierende Relay-Betreiber nahe.

Konfigurationstipps

Veraltete Paketquellen

Bereits bei der Installation habe ich einen Fehler gemacht, der mir erst einige Stunden später durch einen Blick auf meine Metriken unter metrics.torproject.org aufgefallen ist. Ich habe TOR über die Standard-Ubuntu-Paketquellen mittels apt-get install tor installiert. Allerdings ist die dort hinterlegte Versionen in Kombination mit LTS-Betriebssystemen oftmals veraltet. Um den Fehler zu beheben, musste ich die Anleitung unter torproject.org befolgen.

/etc/tor/torrc – Das Herz deines Relays

In der Datei /etc/tor/torrc wird der TOR-Relay-Dienst konfiguriert. Einige Einstellungen sind für fortgeschrittene Benutzer – insbesondere für TOR-Exit-Node-Betreiber – und andere Einstellungen sollten für jeden TOR-Relay entsprechend konfiguriert werden. Wie es für Konfigurationsdateien üblich ist, werden benutzerdefinierte Einstellungen erst durch das Löschen des vorangestellten Hashtags aktiviert.

Die wichtigste Einstellung verbrigt sich in der Zeile #ExitPolicy reject *:* # no exits allowed. Damit wird die Funktionalität als Exit-Node abgeschaltet bzw. verhindert.

Im Auslieferungszustand lauscht TOR auf Port 9001. Um das zu ändern, kann bei ORPort der Wert 9001 durch einen beliebigen, noch freien Port ersetzt werden. Wenn der Port nicht bereits in Verwendung ist, sollte TOR auf einem gängigen Port wie 80 oder 443 gelegt werden, der selbst in streng reglementierten Netzwerken freigegeben ist. Wenn der Server mit einer IPv6-Adresse ausgestattet ist, muss folgende Zeile manuell angelegt werden; füge in die eckigen Klammern deine IPv6-Adresse ein: ORPort [2001:41d0:701:1100::3d1d]:9001

Die Einstellung Adress ist optional. Hier lassen sich IP-Adressen, der Hostname des Servers oder ein Domain-Name nach dem Schema tor.deinedomain.de eintragen.

Nickname ist ebenso freiwillig, doch sehr zu empfehlen. Hier kannst du den Namen des Relays bestimmen. Dieser taucht auch in den Metriken unter metrics.torproject.org  auf. Meine Relays hießen scenario und scenario02.

Gelegentlich versendet das torproject.org-Team E-Mails rund um das Projekt selbst oder du wirst auf einen Konfigurationsfehler oder eine länger anhaltende Downtime deines Servers hingewiesen. Die E-Mail-Adresse kann über die Zeile ContactInfo bestimmt werden. Die dort angegebene Adresse ist öffentlich. Verwende nur eine Adresse, die bei zu viel eingehendem Spam abgeschaltet werden kann. Fortgeschrittene Anwender können hier auch ihren PGP-Schlüssel für eine verschlüsselte E-Mail-Kommunikation hinterlegen.

Um zu vermeiden, dass bei einer Anfrage mehrere Server eines Betreibers verwendet werden, lassen sich Relays in Familien organisieren. Dazu das Hashtag bei #MyFamily löschen und die Fingerabdrücke aller (!) Relays kommasepariert eintragen.

Über RelayBandwidthRate 100 KB und RelayBandwidthBurst 200KB wird festgelegt, wie viel Bandbreite TOR für sich beanspruchen darf. Dem TOR-Netzwerk helfen schnelle Nodes, auch wenn sie nur wenige Tage (im Monat) online sein sollten mehr als ein dauerhafter langsamer Relay-Dienst. Hier musst du selbst entscheiden, wie viel Bandbreite du maximal hast und wie viel du für TOR freigeben kannst. Bei meinem Test-Server mit 100 Mbit/s im Up- und Download habe ich auf RelayBandwidthRate 10 MB #entspricht 80 Mbit/s und RelayBandwidthBurst 11 MB #entspricht 88 Mbit/s fuer eventuelle Peaks konfiguriert.

Datenvolumen richtig einstellen

Wer verhindern möchte, dass TOR das gesamte Datenvolumen des Servers verbraucht, aber dennoch einen schnellen Relay anbieten möchte, kann das über die Einstellung AccountingMax tun; ganz egal, ob 90 GB, 1 TB oder noch mehr. Hierbei habe ich einen Fehler gemacht, der glücklicherweise von meinem Hoster bemerkt wurde ehe mein gesamtes Datenvolumen für den Monat verbraucht war. AccountingMax zählt Einweg. Allerdings verursacht TOR sowohl Down- als auch Upload. Bei meinen eingestellten 1000 GB hätte das 2000 GB Datenverkehr zur Folge. Vielleicht setzt sich das verbrauchte Datenvolumen deines Servers mitten im Monat zurück oder du möchtest zur Stelle sein, wenn andere Server ihr Traffic-Limit ausgereizt haben. Über AccountingStart month 13 17:00 setzt TOR seinen Zähler am 13. des Monats um 17:00 Uhr zurück.

Nyx für Informationen in Echtzeit

Nyx ist ein Werkzeug für TOR-Nodes, das über die Befehlszeile läuft. Laut der offiziellen Website des Projekts präsentiert Nyx Informationen über die beanspruchte Bandbreite, aktuelle Verbindungen, Logs und vieles mehr in Echtzeit. Die Software wird über die offiziellen Paketquellen mittels apt-get install nyx installiert. Über den Befehl nyx wird das Programm geöffnet und wird durch das Drücken der Tastenkombination Cmd+C oder schlicht q geschlossen. Bei der ersten Verwendung wird es zu der Fehlermeldung kommen, dass Nyx keine Verbindung zu TOR aufbauen kann. Aktiviere die Parameter ControlPort 9051 und CookieAuthentication 1 in der /etc/tor/torrc-Datei und starte TOR via service tor restart neu.

© Leon Ebersmann