Leitfaden für versteckte (.onion) Tor-Dienste

The Onion Router

Wie diese Anleitung zu benutzen ist

Hier findest du Informationen zum Betrieb eines versteckten (.onion) Tor-Dienstes mit unseren Praxiserfahrungen und Tipps von hilfreichen Menschen wie dir. Wenn du einen hilfreichen Tipp hast, oder diese Seite in eine andere Sprache übersetzen kannst, trage etwas bei!

Tor Hidden Services wurden umbenannt, weil “Hidden Service” beschrieb nicht genau was damit möglich ist, sodass der Name in .onion-Dienste (“onion Services”) umbenannt wurde, in dieser Anleitung werden wir diesen Namen benutzen.

Installation und Konfiguration von .onion-Diensten

Für Informationen zum Konfigurieren von .onion-Diensten siehe Anleitung des Tor-Projektes

Stelle sicher, dass sie Software aktuell ist

Es reicht nicht, Tor zu installieren, deinen .onion-Dienst zu konfigurieren und dann zu vergessen. Du musst ihn aktuell halten, damit kritische Sicherheitslücken geschlossen werden. Jede Software hat Fehler und Tor ist keine Ausnahme. Stelle sicher, dass die Software aktuell bleibt.

Viele Dinge können zu .onion-Diensten gemachten werden

Eine Menge ist möglich mit .onion-Diensten, nicht nur das Veröffentlichen von Webseiten! Du kannst IMAP und SMTP anbieten, oder Mails zwischen MTA austauschen, neben vielen anderen Möglichkeiten. Verteile Zwiebeln weit und breit! Aber sei vorsichtig, wenn der Dienst aus irgendwelchen Gründen DNS-Anfragen stellt (z.B. auf der Suche nach einem SMTP-Server, um eine Mail zu verschicken), dann gibst du Informationen preis. Eine Möglichkeit das zu vermeiden ist, deinen Computer mit iptables so einzustellen, dass alles immer komplett über Tor geleitet wird.

Betreibe kein Relay zur gleichen Zeit

Betreibe kein Relay neben einem .onion-Dienst auf derselben Instanz. Wenn du ein Relay und einen .onion-Dienst auf einer IP-Adresse bzw. demselben System betreibst, ist es möglich, dich durch Analyse deines Verkehrs mittels Korrelationen und Fingerabdrücken zu enttarnen. Allerdings ist Tor schlau genau genug, sich nicht sellbst als Node für diese Tor-Verbindung (Circuit) auszuwählen, also ist es kein Disaster, aber idealerweise solltest du es vermeiden.

Überprüfe die Verfügbarkeit deines .onion-Dienstes

Obwohl ihre Stabilität stark zugenommen hat, können .onion-Dienste immer noch aus vielen Gründen ausfallen. Konfiguriere eine Beobachtung (monitoring), welche sich regelmäßig mit deinem .onion-Dienst verbindet, um sicherzustellen, dass er immer noch funktioniert.

Mehrere Ports für einen .onion-Dienst

Du musst nicht für jeden Dienst einen eigenen .onion-Dienst erstellen. Um ihn verfügbar zu machen, brauchst du nur eine weitere HiddenServicePort-Zeile hinzufügen:

HiddenServiceDir /usr/local/etc/tor/other_hidden_service/
HiddenServicePort 6667 127.0.0.1:6667
HiddenServicePort 22 127.0.0.1:22

Wenn du mehrere .onion-Dienste mit derselben Tor-Anwendung betreiben willst, füge eine weitere HiddenServiceDir-Zeile der Konfigurationsdatei hinzu.

SSL/TLS ist nicht nötig

Du brauchst nicht wirklich SSL/TLS auf einer .onion-Adresse (wie https), denn es ist ein komplett verschlüsselter Tunnel mit Vorwärtssicherheit (perfect forward secrecy), aber es schadet nicht, das trotzdem zu machen, um eine zusätzliche Verschlüsselung auf diesem .onion zu haben!

Obwohl es wahr ist, dass zusätzliche Verschlüsselungsschichten gut sind, beachte, dass das SSL/TLS-Zertifikat nicht valide sein wird, es sei denn du registrierst es für deine *.onion-Adresse.

Onion-Dienste und Rails 4

Um eine .onion-Seite mit Rails und HTTPS zu betreiben, müssen einige Standard-Einstellungen verändert werden.

Als erstes muss die Option config.force_ssl = true ausgestellt werden. Diese ist standardmäßig aktiviert für produktive Rails-Anwendungen. Sie erzwingt sichere Cookies and HSTS. Ändere my_rails_app/config/environments/production.rb zu:

config.force_ssl = false

Mit force_ssl = false sollen nun sichere Cookies aktiviert mit HTTPS aktiviert werden. Dafür muss sicher gestellt sein, dass der Webdienst HSTS-Kopfzeilen für den HTTPS virtualhost setzt und wir fügen das secureheaders gem, um sichere Cookies zu erzwingen. Damit werden sichere Cookies für alle HTTP-Anfragen aktiviert (anders als mit force_ssl). Das ermöglicht uns, sichere Cookies für HTTPS und unsichere Cookies für die .onion-Seite zu schicken.

Installiere das gem secureheaders für unsere Anwendung, in rails_app/Gemfile:

gem 'secure_headers', '~> 3.5'

(ersetze 3.5 mit der jeweils neuesten verfügbaren Version)

Füge die Konfiguration für secureheaders config/initializers/secureheaders.rb hinzu:

bc..
SecureHeaders::Configuration.default do |config|
config.cookies = {
secure: true,
httponly: true,
samesite: {
strict: true
}
}
end

Beachte dass für apache oder nginx die Variable X_FORWARDED_PROTO nicht auf https gesetzt werden darf.

.onion-Dienste können gefunden werden

Wenn du nicht vorsichtig bist und deinen Server davor bewahrst, Informationen über dich, deinen Computer, oder deinen Ort zu enthüllen, ist dein .onion-Dienst nicht mehr versteckt!

Ein häufiger Fehler sind Server-Signaturen, z.B. ist es einfach festzustellen, ob als Webserver thttpd oder Apache läuft, oder dein System festzustellen, denn das Banner nennt die Version und das Betriebssystem des laufendes Diestes.

Eine andere Möglichkeit, deine Adresse herauszufinden, sind Referrer-Kopfzeilen, wenn ein Browser die Webseite deines .onion-Dienstes öffnet und dann auf einen Link auf eine unverschlüsselte Webseite geklickt wird. Tor Browser kümmert sich um viele kleine solcher Leaks, also ermuntere deine Nutzer*innen einen aktuellen Tor Browser zu benutzen, statt einen eigenen Browser über Tor verbinden zu lassen.

Je länger ein .onion-Dienst online ist, umso größer ist die Gefahr, dass dieser gefunden wird. Die bekanntesten Angriffe bilden ein Profil über die Verfügbarkeit eines .onion-Dienstes und sammeln Übereinstimmungen in deinen Verkehrsmustern.

Das Tor-Protokoll bietet aktuell Möglichkeiten, mit denen ein bösartier Relay deine .onion-Adresse finden kann, selbst wenn du niemensch davon erzählst. Folge dieser Diskussion über das Thema, wenn du auf dem Laufenden bleiben willst, wie beim Tor-Projekt versucht wird, das Problem zu beheben.

.onion-Dienste brauchen nicht versteckt werden!

Du kannst .onion-Dienste für öffentlich beworbene Dienste auf Servern, die nicht versteckt sind, anbieten. .onion-Dienste sind nützlich, um Nutzer*innen vor passiver Netzwerküberwachung zu schützen, sie lassen die Spione im Dunkeln darüber, von wo und wohin sich wer verbindet.

Mach deine .onion-Dienste einfach auffindbar

Wenn du .onion-Dienste anbietest, bewirb sie unter deinen Nutzer*innen mit der .onion-Adresse und den angebotenen Ports auf eine Weise, dass diese als die legitimen angebotenen Dienste authentifiziert sind (du könntest die Liste der .onion-Adressen digital signieren, so wie Riseup das macht, oder in DNS txt-Einträge schreiben).

Bitte deine Lieblings-Onlinedienste, einen .onion-Dienst anzubieten!

Tritt ein für mehr .onion-Dienste, indem du die Betreiber*innen deiner Dienste bittest, diese als .onion-Dienste anzubieten. Sie sind einfach aufzusetzen und aufrecht zu erhalten und es gibt keinen Grund, sie nicht anzubieten!

.onion-Dienste verschieben

Du kannst .onion-Dienste einfach zwischen Systemen verschieben. Kopiere dazu den Ordner /var/lib/tor/<hidden_service> auf das neue System und stelle sicher, dass torrc auf dem neuen System die gleiche Einstellung wie das alte hat. Stelle sicher, dass der alte Dienst gestoppt und deaktiviert ist, bevor der neue gestartet wird. Das Verzeichnis des .onion-Dienstes enthält den Hostname des .onion-Dienstes und den privaten Schlüssel.

Schütze deine Dienste

Schütze deine privaten Schlüssel

Behalte deinen privaten Schlüssel privat! Der Schlüssel sollte nicht für die Öffentlichkeit erreichbar sein, nicht geteilt werden und die richtigen Dateirechte gesetzt haben, damit er nicht von anderen Nutzenden deines Systems lesbar ist, außer dem Tor-Prozess.

Mach ein Backup deiner privaten Schlüssel

Wenn du vorhast, deine Dienste über lange Zeit anzubieten, solltest du ein Backup deiner private_key-Datei an einem sicheren Ort behalten.

Vorsicht vor localhost-Bypässen!

Du solltest sehr vorsichtig sein, nicht aus Versehen Dinge auf deinem Server öffentlich sichtbar zu machen, die nur für die lokale Benutzung gedacht sind. Apache bietet z.B. den /server-status (das Modul mod_status ist standardmäßig aktiviert in Debian’s Apache-Paket) an, um die Gesundheit des Webservers zu beobachten. Dieser ist typischerweise nur von 127.0.0.1 erreichbar, oder du kannst .htaccess-Regeln einstellen, die nur localhost erlauben, etc.

Es gibt einige wenige Wege, dieses Problem zu lösen:

  • andere Maschine: überlege, den .onion-Dienst auf einem anderen Rechner (real oder virtuell) laufen zu lassen, als die betreffenden Dienste. Das hat den Vorteil, dass beide Dienste isoliert sind (wenn einer kompromittiert wird, bleibt der andere unbehelligt) und es hilft, die Preisgabe von Informationen zu vermeiden.
  • Isolation: ähnlich zum eben Genannten kannst du Tor und andere Dienste isolieren, indem sie in verschiedenen Netzwerk-Namensbereichen laufen. Der Paketfilter von Tails stellt nur Verbindungen über Tor her und bricht ansonsten Verbindungen ab.
  • öffentliche IP-Adresse: lass den .onion-Dienst zur öffentlichen IP-Adresse des Dienste verbinden, anstatt nach localhost/127.0.0.1, sodass tor nicht 127.0.0.1 als Quelle auffängt und verhindert die meisten Fehlkonfigurationen, wie z.B. diese:
HiddenServiceDir /var/lib/tor/hidden/ftp/
HiddenServicePort 80 192.168.1.1:81

Beachte: Dies macht den Server oder vhost evtl. über das offene Internet erreichbar. Es gibt zunehmend Versuche, den wahren Ort von Seiten hinter cloudflare festzustellen, indem über Massenscans per zmap der gesamte IPv4-Bereich nach Übereinstimmungen mit onion-Diensten durchsucht wird.

Bei Apache kann das Ausliefern auf einem anderen Port als dem tatsächlichen zu einem Leak führen, weil z.B. bei 301-Fehlerseiten der tatsächliche Port angegeben wird. Für den Ordner foo.onion/css/ würde eine Anfrage nach foo.onion/css zu einer 301-Umleitung mit dem tatsächlichen Port führen: foo.onion/css/ anstatt foo.onion:81/css/.

  • unix socket: benutze unix socket-Unterstützung, anstatt TCP socket (benötigt tor 0.26 oder neuer) – in diesem Fal läuft der .onion-Dienst auf dem gleichen Server wie der Dienst selbst. Per socket sollte es möglich sein, privatenetwork=yes in systemd einzustellen, was wirklich gute Isolation bietet, z.B.:
HiddenServicePort 80 unix:/etc/lighttpd/unix.sock

Allerdings muss der Dienst selbst auch unix sockets unterstützen, andererseits muss eine socat-Weiterleitung von tcp <→ unix (nginx, twisted, lighttpd unterstützen das) eingestellt werden.

  • sorgfältige Sicherheitsprüfung: mache eine sorgfältige Sicherheitsprüfung (und wiederhole diese regelmäßig) deiner Systemeinstellungen, die localhost/127.0.0.1 erlauben, aber verbiete alle anderen und konfiguriere diese, um das Problem herum zu arbeiten (z.B. indem /server-status auf einer anderen IP-Adresse angeboten wird; lass den Webserver auf einem anderen Port lauschen für /server-status; schütze es mit einem Passwort, etc.).

Schütze .onion-Dienste mit Authentfizierung

Wenn du HiddenServiceAuthorizeClient einstellst (siehe Anleitung), ist der Dienst nur für Autorisierte verfügbar. Des bedeutet, dass der Dienst nicht angegriffen werden kann, ohne Tor zu brechen (oder an den Autorisations-Schlüssel zu gelangen).