.titleBar { margin-bottom: 5px!important; }

Tor Onion Router als Server einrichten

Dieses Thema im Forum "Freetz" wurde erstellt von alpha1974, 11 Sep. 2008.

  1. alpha1974

    alpha1974 Neuer User

    Registriert seit:
    5 Sep. 2006
    Beiträge:
    185
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    #1 alpha1974, 11 Sep. 2008
    Zuletzt bearbeitet: 4 Okt. 2008
    Unter Freetz gibt es ja bereits das Tor-Paket. Jedoch kann man Tor damit nicht so ohne weiteres als Server/Relay laufen lassen. Ich habe einmal ein bisschen "herumgefrickelt" und versucht, das vorhandene Paket so abzuändern, dass Tor auch als Server genutzt werden kann.

    Nach dem Einspielen des angehängten Patches kann Tor über das Webmenü auch als Server konfiguriert werden. Der secret_id_key wird im Flash abgespeichert und nicht jedesmal neu erzeugt (was bei einem evtl Ausbau des Patches für Hidden-Services relevant ist). Er kann bei Bedarf jedoch über die Weboberfläche geändert werden.

    Es wäre nett, wenn sich ein Freetz-Profi den Patch einmal näher ansehen könnte. Bei mir läuft Tor damit auf einer 7170 (mit USB-Root und sehr viel Swap) als Nonexit-Node. Wichtig ist, dass für den ORPort und den DirPort lokale Portfreigaben auf der Box eingerichtet sind (muss derzeit manuell z.B. über das AVM-Firewall-Paket erledigt werden).

    Das ganze ist z.Zt. nur ein Experiment! Daher die ausdrückliche Warnung, dass ein Tor-Server nur von Leuten eingerichtet und betrieben werden sollte, die wissen, was sie tun. Das gilt insbesondere für die ExitPolicy, damit man nicht ungewollt einen ExitNode betreibt (per Default wird der Server NICHT als ExitNode gestartet)!

    TODO:
    - Weboberfläche um Hinweise ergänzen (z.B. auf erforderliche Portfreigabe)
    - Konfiguration von Hidden-Services

    Gruß
    alpha1974
     

    Anhänge:

  2. yazoo83

    yazoo83 Neuer User

    Registriert seit:
    8 Juli 2008
    Beiträge:
    33
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    Gelsenkirchen
    diese idee habe ich auch schon gehabt...
    und ähnlich wie Du es auch geschafft, ich habe aber eines festgestellt.
    tor belastet die cpu scheinbar doch extremst (meist bei lasten um 90%).
    das ergebnis war bei mir zumindest, das sich die box öfter mal rebootet hat, und so ein sinnvolles nutzen von tor nicht wirklich möglich war.
     
  3. alpha1974

    alpha1974 Neuer User

    Registriert seit:
    5 Sep. 2006
    Beiträge:
    185
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    #3 alpha1974, 12 Sep. 2008
    Zuletzt bearbeitet: 12 Sep. 2008
    Bei mir kommt es zu gelegentlichen Reboots, wenn Tor auch als DirectoryServer läuft (also ein DirPort konfiguriert ist). Dann steigt die CPU-Last teilweise stark an. Außerdem steigt der Speicherbedarf so, dass ständig "geswappt" wird, wodurch die Box insgesamt träge wird.

    Ohne DirServer, also nur mit ORPort, konnte ich bislang keine Reboots feststellen. Auch die CPU-Last ist im Schnitt nicht höher als 20 Prozent (für ALLE laufenden Anwendungen lt. rrdstats).

    Probier doch mal aus, den DirPort leer zu lassen. Außerdem sollten ein paar MB Swap zur Verfügung stehen. Vielleicht hilft es auch, bei der Option "MaxOnionsPending" den Default-Wert (100) herunterzusetzen.

    Gruß, alpha1974

    EDIT: Ich habe den Patch in Post #1 aktualisiert. Man kann nun die Option MaxOnionsPending über die Web-Oberfläche ändern.
     
  4. alpha1974

    alpha1974 Neuer User

    Registriert seit:
    5 Sep. 2006
    Beiträge:
    185
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Keine Reboots mit "MaxOnionsPending"=20

    Hier ein Zwischenbericht zum Thema Tor-Server und Reboots:
    Ich habe den Parameter "MaxOnionsPending" vom Default-Wert 100 auf 20 heruntergesetzt. Die sonstigen Einstellungen wie auf dem Screenshot ersichtlich (Server-Name wurde geändert). Die Box hat seitdem Reboot mehr durchgeführt und der Tor-Server läuft fleißig... ;-)

    In einem Mailinglisten-Archiv habe ich zur Option "MaxOnionsPending" folgende Aussage gefunden:
    Code:
    Usually relays are well under the 100 mark. The only cases I've seen in practice where it happens are:
    a) If the Tor relay doesn't have much cpu to spare, and it's advertising
       a really high bandwidth value.
    b) If some client goes berserk and starts sending hundreds of create
       cells.
    
    Möglicherweise ist beim Default-Wert 100 der Punkt a) (wenig CPU bei hoher Bandbreite) die Ursache für die Reboots der Box.

    Vielleicht können andere Freetz-/Tor-User entsprechende Tests durchführen und hier eine kurze Rückmeldung geben. Wichtig ist auch, dass ausreichend Swap vorhanden ist.

    Gruß
    alpha1974
     

    Anhänge:

  5. alpha1974

    alpha1974 Neuer User

    Registriert seit:
    5 Sep. 2006
    Beiträge:
    185
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Hallo Tor-Freunde ;-)

    Ich habe den Patch im ersten Beitrag so geändert, dass der Tor-Daemon nicht mehr als root-Prozess läuft, sondern entsprechend der Autoren-Empfehlung mit eigener Benutzerkennung. Dazu werden der user tor und die group tor im Init-Skript angelegt, bevor der Daemon gestartet wird. Dass Tor als user tor laufen soll, wird ihm über torrc mitgeteilt.

    Unschön ist, dass der Tor-Daemon als Nicht-Root-Prozess keinen Schreibzugriff auf /var/run/ hat. Deshalb wird durch das Init-Skript erst mit Root-Rechten eine leere /var/run/tor.pid angelegt und dann die Besitzrechte per chown auf tor:tor geändert. Der Tor-Daemon kann anschließend die Datei ändern. Beim Beenden mittels rc.tor stop wird die pid-Datei durch die Funktion modlib_stop wieder gelöscht.

    Hier läuft es auf einer 7170... Übrigens ist es bei mir mit folgenden Parametern zu keinem Reboot mehr gekommen (die Box hängt hinter einem Kabelmodem):
    Code:
    User tor
    Group tor
    SocksPort 0
    SocksListenAddress 0.0.0.0
    CircuitIdleTimeout 300
    Nickname xxxxx
    Address xxxxx
    BandwidthRate 25 KB
    BandwidthBurst 40 KB
    ORPort 9001
    MaxOnionsPending 10
    ExitPolicy reject *:*
    
    Entscheidend ist wohl, dass nicht zuviel Brandbreite bereit gestellt wird, aber dass Tornetz freut sich ja auch so über aber jedes KB mehr Bandbreite. Durch SocksPort = 0 läuft Tor übrigens nicht mehr als Client auf der Box, aber dafür sehe ich auch keine Veranlassung (wenn mein PC läuft, kann dort auch der Client laufen).

    Gruß, alpha1974
     
  6. olistudent

    olistudent IPPF-Urgestein

    Registriert seit:
    19 Okt. 2004
    Beiträge:
    14,756
    Zustimmungen:
    2
    Punkte für Erfolge:
    0
    Beruf:
    Softwareentwickler
    Ort:
    Kaiserslautern
    Hi.
    Hab grad mal in dein Patch geschaut.
    Code:
    + if [ ! -e "/tmp/flash/.tor/secret_id_key" ]; then
    +  [ -d "/tmp/flash/.tor" ] || mkdir /tmp/flash/.tor
    +  cp /var/tmp/tor/keys/secret_id_key /tmp/flash/.tor/secret_id_key
    +  /usr/bin/modsave flash
    + fi
    Was passiert, wenn man hier kein "modsave flash" macht? Ist das ein Problem? Wo kommt der secret_id key her?

    MfG Oliver
     
  7. alpha1974

    alpha1974 Neuer User

    Registriert seit:
    5 Sep. 2006
    Beiträge:
    185
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Der secret_id key wird von Tor beim Starten angelegt, sofern er nicht bereits vorhanden ist. Er dient dazu, den Server unabhängig von der IP-Adresse zu identifizieren; relevant ist das vor allem dann, wenn man hidden services anbietet. Diese sind über eine eindeutige URL nach dem Muster http://zufaelligezeichenkette.onion erreichbar. Damit der hidden service auch beim Wechsel der IP-Adresse des Servers unter der URL erreichbar bleibt, muss der secret_id key dauerhaft gespeichert werden und auch einen Reboot "überleben".

    ... denke ich ;)
     
  8. olistudent

    olistudent IPPF-Urgestein

    Registriert seit:
    19 Okt. 2004
    Beiträge:
    14,756
    Zustimmungen:
    2
    Punkte für Erfolge:
    0
    Beruf:
    Softwareentwickler
    Ort:
    Kaiserslautern
    Noch was:
    Code:
    +  deffile='/mod/etc/default.tor/secret_id_key.def'
    +  modreg file 'secret_id_key' 'Tor: Secret ID Key' 0 "$deffile"
    Ich kann das deffile in deinem Patch nicht finden?

    MfG Oliver
     
  9. alpha1974

    alpha1974 Neuer User

    Registriert seit:
    5 Sep. 2006
    Beiträge:
    185
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    #9 alpha1974, 19 Okt. 2008
    Zuletzt bearbeitet: 19 Okt. 2008
    Das Def-File sieht so aus:
    Code:
    CAPTION='Secret ID Key (Tor Server)'
    CONFIG_FILE='/tmp/flash/.tor/secret_id_key'
    CONFIG_SAVE='modsave flash'
    CONFIG_TYPE='text'
    Ich habe den Patch mit "svn diff" erstellt, war aber offenbar zu blöd, um es richtig zu machen :rolleyes: Gibt es einen Parameter, der neue Dateien in den Patch einbezieht?

    EDIT: Ein "svn add" für das def-File scheint zu helfen. Jedenfalls taucht das File jetzt im Patch mit auf. Im angehängten Patch gibt es eine neue Option DataDirectory (wahlweise persistent).

    Gruß, alpha1974
     

    Anhänge:

  10. olistudent

    olistudent IPPF-Urgestein

    Registriert seit:
    19 Okt. 2004
    Beiträge:
    14,756
    Zustimmungen:
    2
    Punkte für Erfolge:
    0
    Beruf:
    Softwareentwickler
    Ort:
    Kaiserslautern
    Gut. Und jetzt nochmal wegen dem "modsave flash". Wird dieses Keyfile ins Webinterface gepastet oder warum braucht man da eine Editiermöglichkeit? Ansonsten würde ich das "modsave" aus der rc.tor entfernen.

    MfG Oliver
     
  11. alpha1974

    alpha1974 Neuer User

    Registriert seit:
    5 Sep. 2006
    Beiträge:
    185
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Über den Link "Secret ID Key bearbeiten" im Webinterface kann man das Keyfile ändern. Die Editiermöglichkeit ermöglicht z.B. den Austausch des Server Keys, wenn man mit einem hidden service "umziehen" möchte (Szenario: Der Tor-Server lief auf einem anderen Rechner und ist unter dem Key mit einer eindeutigen *.onion-URL bekannt. Um ihn auf einen anderen Rechner zu verschieben, muss das Keyfile kopiert werden, da sich ansonsten die Identität des Servers im Tor-Netz ändert). Das ist übrigens nicht nur für hidden services (die derzeit vom Patch noch gar nicht unterstützt werden...) relevant, sondern auch für die Erreichbarkeit des Tor-Servers als MiddleNode für andere Clients. Im Client-Modus kann man über die Option "EntryNodes" bestimmte Eingangsknoten bevorzugt nutzen. EntryNodes können nicht nur unter ihrem Namen, sondern auch über ihren Key-Fingerprint angegeben werden. Letzteres ist der empfehlenswertere Weg, da sich jeder Server den Namen selbst geben kann und deshalb eine "feindliche Übernahme" der Clients, die bestimmte EntryNodes nach Namensliste bevorzugen, möglich ist. Das Kopieren des Fingerprints ist ohne Kenntnis des SecretKeys nicht ohne weiteres möglich.

    Das "modsave" in rc.tor sollte im Idealfall nur ein einziges Mal ausgeführt werden, nämlich beim Beenden eines Tor-Servers nach dessen ersten Start (ohne dass vorher schon ein Key existierte). Beim ersten "jungfräulichen" Start wird ein zufälliger Key erzeugt, der -spätestens- beim Beenden dauerhaft gesichert werden sollte, damit der Server bei nächsten Start keine neue Identität erzeugt, sondern "ganz der Alte" bleibt ;-)

    Gruß, alpha1974
     
  12. olistudent

    olistudent IPPF-Urgestein

    Registriert seit:
    19 Okt. 2004
    Beiträge:
    14,756
    Zustimmungen:
    2
    Punkte für Erfolge:
    0
    Beruf:
    Softwareentwickler
    Ort:
    Kaiserslautern
    Hm, das kann man bestimmt irgendwie eleganter lösen. Ich weiß grad nur nicht wie.

    MfG Oliver
     
  13. knox

    knox Mitglied

    Registriert seit:
    20 Mai 2006
    Beiträge:
    577
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Kleiner ketzerischer Einwurf am Rande: ein TOR Server benötigt eine gewisse Menge Arbeitsspeicher und außerdem nicht wenig CPU-Leistung, da es sich schließlich um eine vielzahl verschlüsselter Verbindungen handelt.

    Als ich dieses Package damals begonnen habe, war es eine bewusste Design-Entscheidung, auf die Server-Funktionalität zu verzichten und einen reinen TOR-Client zu realisieren.

    Auch wenn ich wirklich niemanden in seinem Tatendrang bremsen möchte, muss ich trotzdem noch mal die Frage stellen, welchen Wert ein TOR-Server auf einer Fritz!Box haben soll? Wer gerne das TOR-Netzwerk unterstützen will, sollte lieber über eine Spende, z.B. an die German Privacy Foundation, oder das Anmieten eines root-Servers zum Betrieb eines TOR-Servers nachdenken.
     
  14. alpha1974

    alpha1974 Neuer User

    Registriert seit:
    5 Sep. 2006
    Beiträge:
    185
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Genauso ist es. Aber die Fritz!Box -zumindest die 7170- scheint durchaus in der Lage zu sein, die Anforderungen zu erfüllen. Dank rrdstats kann man ja die CPU-Auslastung gut nachvollziehen. Das ist offenbar überhaupt kein Problem (wenn die Statistik stimmt...). Das Thema Arbeitsspeicher lässt sich nur durch einen großzügigen Swap lösen. Der Betrieb eines Tor-Servers auf der Fritzbox setzt eine bewusste Entscheidung des Anwenders voraus, der die Box hierfür nutzen will und vielleicht keinen Bedarf für andere rechenintensive Anwendungen hat.
    Denselben Wert, den jeder TOR-Server hat? Maßgeblich ist doch in erster Linie, wieviel Bandbreite durchgehend zur Verfügung gestellt werden kann. Da die Fritz!Box bei vielen Nutzern ohnehin durchgehend online ist, kann man problemlos soviel Traffic routen, dass sich die Box nicht hinter anderen Tor-Relays zu verstecken braucht (sowohl was die Uptime angeht als auch den Durchsatz lt. rrdstats).

    Natürlich ist eine Geldspende auch hilfreich. Das Tor-Netzwerk lebt aber auch davon, dass Nutzer Bandbreite spenden (die ohnehin bei den meisten Flatrate-Tarifen im Überfluss vorhanden ist). Die Erweiterung des Tor-Pakets um die Server-Konfiguration ist aber sowieso nur Spielerei und wird abseits der technischen Machbarkeit spätestens ab dem 01.01.2009 zumindest aus rechtlicher Sicht nochmals hinterfragt werden müssen (§ 113a TKG i.V.m. § 150 TKG).

    Gruß, alpha1974
     
  15. knox

    knox Mitglied

    Registriert seit:
    20 Mai 2006
    Beiträge:
    577
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Genau hier setzt meine Kritik an: die Fritz!Box ist aufgrund ihrer technischen Beschaffenheit nicht geeignet, als angemessen leistungsfähiger TOR-Server zu funktionieren. Da nützt weder eine tolle Internetanbinung noch faule Kompromisse in Sachen swap.

    Dabei auf jeden Fall weiterhin viel Spaß und möglichst Erfolg.

    Ohne jetzt eine große Diskussion vom Zaun brechen zu wollen, muss ich doch darauf bestehen, dass Du hier unnötiger Weise vorrauseilende Gehorsam erkennen lässt. Ob und welche Auswirkungen die Vorratsdatenspeicherung auf den Betrieb eines (einzigen) TOR-Servers hat ist derzeit noch völlig unklar und wird auf diversen Mailinglisten und in Blogs diskutiert. Insbesondere "private Anbieter" sind wohlmöglich in der einen oder anderen Weise ausgenommen, was Speicherpflichten angeht.
     
  16. alpha1974

    alpha1974 Neuer User

    Registriert seit:
    5 Sep. 2006
    Beiträge:
    185
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Was ist denn "angemessen leistungsfähig"? Wenn ich mir die Liste der aktiven Tor-Server ansehe, sind die 30kb, die die Test-7170 bei mir bis vor einigen Tagen über mehrere Tage lieferte (bis die Putzfrau versehentlich den Stecker zog und seitdem anderes wichtiger war...), so schlecht nicht.
    Da die zur Verfügung gestellte Bandbreite anscheinend von anderen Tor-Usern genutzt wurde, sehe ich darin durchaus einen Nutzen für das Tor-Netzwerk. Alternativ könnte ich die Box natürlich auch einfach vor sich hindösen lassen und meinem Provider den Traffic ersparen... Ich habe nicht den Ehrgeiz, der Box beizubringen, einen Durchsatz wie "blutmagie" oder "SURFnetTor1" zu leisten. Aber in die Reihe der zahlreichen Relays, die zwischen 20kb und 40kb bringen, kann sich Box wohl gut einreihen. Dass hierfür ein Swap eingerichtet werden muss, ist für mich kein fauler Kompromiss.
    Dass in manchen Mailinglisten und Blogs eine gewisse Unklarheit herrscht, mag durchaus sein. Maßgeblich ist für mich eher die tatsächliche Rechtslage, deren halbwegs zuverlässige Beurteilung ich mir durchaus zutraue ;) Vorauseilenden Gehorsam löst das bei mir indes nicht aus, denn dann hätte ich bereits seit dem 01.01.2008 keinen Tor-Server mehr betrieben. Ich verfolge die Diskussion eher aus wissenschaftlichem Interesse (wobei das Thema innerhalb der "IT-Recht-Szene" ja fast schon wieder durch ist...). Rechtspraxis und -theorie werden im Anwendungsbereich des § 113a TKG bei privat betriebenen Tor-Servern sowieso auseinanderfallen, und zwar unabhängig davon, ob, wann und wie das BVerfG entscheiden wird.

    Gruß, alpha1974
     
  17. cuma

    cuma Aktives Mitglied

    Registriert seit:
    16 Dez. 2006
    Beiträge:
    2,743
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    secret_id_key?

    Mir fehlt die secret_id_key, wo bekomme ich die her?

    Code:
    # /etc/init.d/rc.tor start
    chown: /storage/tor/keys: No such file or directory
    Starting Tor Proxy...done.
    #
    # /etc/init.d/rc.tor stop
    Stopping tor...done.
    cp: cannot stat '/keys/secret_id_key': No such file or directory
    Writing /var/flash/freetz...done.
    95232 bytes written.
    #
    # /etc/init.d/rc.tor start
    chown: /storage/tor/keys: No such file or directory
    Starting Tor Proxy...done.
    #
    # /etc/init.d/rc.tor stop
    Stopping tor...done.
    cp: cannot stat '/keys/secret_id_key': No such file or directory
    Writing /var/flash/freetz...done.
    95232 bytes written.
    
     
  18. alpha1974

    alpha1974 Neuer User

    Registriert seit:
    5 Sep. 2006
    Beiträge:
    185
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Eigentlich müsste die bei ersten Starten von Tor automatisch angelegt werden. Wie ist DataDirectory in /var/mod/etc/tor/torrc gesetzt?
    Existiert /storage/tor/? Was steht drin?
     
  19. cuma

    cuma Aktives Mitglied

    Registriert seit:
    16 Dez. 2006
    Beiträge:
    2,743
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    Ja, das storage gibt es. In der Date steht

    Code:
    # cat /var/mod/etc/conf/tor.cfg
    export TOR_ADDRESS=''
    export TOR_BANDWIDTHBURST='40 KB'
    export TOR_BANDWIDTHRATE='20 KB'
    export TOR_CIRCUIT_IDLE_TIMEOUT='300'
    export TOR_CONTROL_PORT=''
    export TOR_DATADIRECTORY='/storage/tor'
    export TOR_DATADIRPERSISTENT='yes'
    export TOR_DIRPORT=''
    export TOR_ENABLED='yes'
    export TOR_ENTRY_NODES=''
    export TOR_EXITPOLICY='reject *:*'
    export TOR_EXIT_NODES=''
    export TOR_MAXONIONSPENDING='10'
    export TOR_NICKNAME=''
    export TOR_ORPORT='9001'
    export TOR_RELAY_ENABLED='no'
    export TOR_SOCKS_ADDRESS='127.0.0.1'
    export TOR_SOCKS_POLICY_ACCEPT=''
    export TOR_SOCKS_POLICY_REJECT='no'
    export TOR_SOCKS_PORT='9050'
    export TOR_STRICT_ENTRY_NODES='no'
    export TOR_STRICT_EXIT_NODES='no'
    
    Code:
    # l /storage/tor/
    drwx------    2 tor      tor          4096 Mar 15 14:53 .
    drwxr-xr-x    8 root     root         4096 Mar 14 14:05 ..
    -rwx------    1 tor      tor          9804 Mar 15 14:36 cached-certs
    -rw-------    1 tor      tor        299492 Mar 15 14:53 cached-consensus
    -rwx------    1 tor      tor       2073421 Mar 15 14:48 cached-descriptors
    -rwx------    1 tor      tor             0 Mar 15 14:48 cached-descriptors.new
    -rw-------    1 tor      tor          2155 Mar 15 13:53 state
    
     
  20. alpha1974

    alpha1974 Neuer User

    Registriert seit:
    5 Sep. 2006
    Beiträge:
    185
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    #20 alpha1974, 15 März 2009
    Zuletzt bearbeitet: 15 März 2009
    Hallo cuma,

    anbei ein Patch für rc.tor. Kannst Du das mal ausprobieren, ob es jetzt besser läuft?