Pünktlich zur Veröffentlichung von Windows Vista gibt es auch einen neuen Weg, Debian zu installieren. Bei GoodBye Microsoft gibt es eine ausführbare Datei zum Herunterladen. Diese bereitet das System auf die Debianinstallation vor. Danach wird neu gebootet und der Installer startet. Nach den Screenshots zu urteilen, scheint die Methode gut zu funktionieren. Ob es hingegen eine gute Idee ist, das in nacktefrau.jpg.exe umzubenennen und an alle E-mails anzuhängen, wage ich zu bezweifeln. 
Mika hat heute eine Umfrage zu grml herausgegeben. In einer Textdatei findet ihr Fragen, die den Entwicklern sollen, euch besser zu verstehen.Am Ende kommt euch als grml-Nutzer in Form vieler Verbesserungen wieder zugute. Also seit alle recht fleißig und füllt das Formular aus.
Eine weitere wichtige Klasse ist die Kontrolle, zu welchen Torknoten der eigene Rechner Verbindungen aufnimmt/nicht aufnimmt. Mit Tor kann man das auf verschiedene Weise kontrollieren:
- ExcludeNodes
- Je nach Level an Paranoidität wird es vorkommen, dass man bestimmten Knoten nicht vertraut und über diese keine Verbindungen aufnehmen will. Mittels dieser Option lässt sich bestimmen, über welche Knoten nie eine Verbindung zustande kommen wird. Beispiel: ExcludeNodes stasi, nsa, fsb—als Argument werden dabei die Namen der Knoten übergeben.
- EntryNodes und ExitNodes
- Ganz im Gegensatz zu obiger Einstellung kann es natürlich auch Knoten geben, den man besonderes Vertrauen engegenbringt. Diese lassen sich hiermit entweder als Eingangsserver oder als Ausgangsserver konfigurieren. Solange die untenstehenden Strict*-Optionen nicht gesetzt sind, stellt das für Tor jedoch nur eine Empfehlung dar. Beispiel: ExitNodes freund—wie oben werden die Namen der Server hier hinterlegt.
- StrictEntryNodes und StrictExitNodes
- Mittels dieser Einstellung wird festgelegt, dass genau die unter EntryNodes bzw. ExitNodes festgelegten Knoten benutzt werden. Sollten diese nicht verfügbar sein, wird Tor den Dienst verweigern. Beide Optionen können mit 1 aktiviert bzw. mit 0 deaktiviert werden. Beispiel: StrictExitNodes 1
- MadAddress
- Stell dir vor, du möchtest eine Verbindung zu meiner Homepage aufnehmen. Dabei willst du, dass immer der Exitknoten banana genutzt wird. Dann wird dir diese Einstellung sehr behilflich sein. Beispiel: MadAddress www.kubieziel.de www.kubieziel.de.banana.exit—d.h. an den Namen des Servers wird der Name des Exitknotens und das Wort “exit” angehangen.
- NodeFamily
- Durch Zufall hast du erfahren, dass die Knoten banana, grapefruit und pineapple von demselben Administrator betrieben werden. Wenn nun einmal eine Verbindungsstrecke über alle diese Server gleichzeitig aufgebaut wird, könnte der Betreuer des Rechners deinen Traffic zurückverfolgen und damit deine Anonymität aufheben. Mittels der Option kannst du festlegen, dass diese drei Rechner zusammengehören. Deine Torsoftware wird somit niemals über alle drei gemeinsam eine Verbindungsstrecke aufbauen. Diese Einstellung ist ähnlich zu MyFamily bei einem Server. Beispiel: NodeFamily banana, grapefruit, pineapple
- RendNodes
- Dies legt eine Liste zu bevorzugender Rendezous-Punkte fest. Beispiel: RendNodes blinddate.
- RendExcludeNodes
- Im Gegensatz zu obiger Einstellung wird keiner der hier genannten Rendezous-Punkte genutzt: RendExcludeNodes exfriend
- TrackHostExits
- Stell dir vor, du benutzt eine Seite, die dich anhand deiner IP-Adresse “erkennt”. Dann hast du in der Standardeinstellung von Tor natürlich ein Dilemma. Denn alle paar Minuten ändert sich der Exitknoten und du trittst unter einer anderen IP-Adresse auf. Die Option TrackHostExits hilft dir, dieses Dilemma zu umgehen. Du kannst eine Liste von Host- bzw. Domainnamen angeben und Tor verfolgt, welcher Exitserver benutzt wurde. Wenn du dann erneut auf die Seite zugreifst, wird versucht, denselben Server wieder als Ausgang aus dem Tornetzwerk zu nehmen. Grundsätzlich solltest du mit dieser Option sehr sparsam umge
hen. Denn langfristig kann der Betreiber der anderen Seite deine Anonymität entschleiern. Beispiel: TrackHostExits www.kubieziel.de,.eff.org—die erste Einstellung zielt nur auf www.kubieziel.de, während die zweite die komplette Domain eff.org erfasst, d.h. hiermit würde auch die Subdomain tor.eff.org immer vom selben (temporären) Exitknoten besucht werden.
- TrackHostExitsExpire
- Hier kannst du einstellen, wann die Festlegung von Rechner und Exitknoten gelöscht wird. D.h. nach Ablauf von x Sekunden kann dann auch ein anderer Exitserver benutzt werden. Standardeinstellung sind hier 1800 Sekunden. Beispiel: TrackHostExitsExpire 2000
- AllowInvalidNodes
- Es kann nun den Fall geben, dass es Knoten im Tornetzwerk gibt, von denen die Betreiber der Directoryserver glauben, dass diese nicht korrekt sind. Das kann daran liegen, dass diese nicht vertrauenswürdig sind oder auf irgendeine Weise nicht korrekt funktionieren. Wenn du diese Knoten trotzdem mit benutzen möchtest, kannst du wählen, in welcher Funktion (Entry, Exit, Middle, Introduction oder Rendezvous) diese eingesetzt werden. Standardmäßig würden die als Mittelserver (middle) oder auch als Rendezvous-Knoten genommen. Andere Funktionen sind ausdrücklich nicht empfehlenswert. Beispiel: AllowInvalidNodes middle,rendezvous.
Ein Punkt, der sowohl Client wie auch Server betrifft, ist das Logging. Tor kann viele seiner Aktionen in eine Datei schreiben. Mit den untenstehenden Einstellungen kann man dies an die eigenen Wünsche anpassen.
- Log
- Mit der Option Log lässt sich das Logging sehr fein steuern. Die Struktur der Option ist folgendermaßen: Log min[-max] stderr|stdout|syslog oder Log min[-max] file DATEINAME. Im ersten Fall werden alle Meldungen je nach Einstellungen auf die Standard-, Fehlerausgabe oder ins Syslog geschrieben. Der letzte Wert ist nur unter unixoiden Systemen unterstützt. Im zweiten Fall werden die Meldungen in die Datei DATEINAME geschrieben. Die Werte von min und max können zwischen debug, info, notice, warn und err gewählt werden und max muss nicht unbedingt angegeben werden. Wird debug gewählt, erhält man eine Unmenge an Informationen. In der Regel eignet sich dieser Parameter nur, wenn ein Fehler vorliegt und man diesen sucht. Sinnvoll erscheint die Wahl des Levels notice. Falls keine Log-Option gesetzt ist, schreibt Tor auch keinerlei Logmeldungen. Beispiel: Log notice file /var/log/tor/tor.notice—alle Meldungen vom Level notice oder höher werden nach /var/log/tor/tor.notice geschrieben, Log info-debug stderr—Meldungen vom Grad info und debug werden auf die Fehlerausgabe geschrieben
- SafeLogging
- Eventuell will man nicht, dass sämtliche IP-Adressen, zu denen der Server Kontakt aufnimmt, im Log auftauchen. Dazu kann man SafeLogging auf 1 setzen. Dann erscheint im Log statt der Adresse nur der String [scrubbed]. Diese Option kann 0 oder 1 als Argument bekommen. In der Standardeinstellung steht der Wert auf 1, d.h die IP-Adressen werden verschleiert..
Hin und wieder befindet man sich in einer speziellen Umgebung und Tor läuft nicht sofort. Gerade in Firmen gibt es oft restriktive Einstellungen der Firewall oder es müssen Proxies genutzt werden. Dem steht der Tornutzer nicht hilflos gegenüber. Unterstehende Optionen helfen:
- HttpProxy und HttpsProxy
- Zum Anfang benötigt Tor aktuelle Informationen über laufende Server. Diese werden bei den Directoryservern heruntergeladen. Falls der Download fehlschlägt und man einen Proxy nutzt, hilft die Option HttpProxy Mit HttpsProxy macht Tor auch alle Verbindungen zu den Torroutern über den Proxy. Beispiel: HttpProxy 12.34.56.78.
- HttpProxyAuthenticator und HttpsProxyAuthenticator
- Falls du dich mit einem Nutzernamen und Passwort am Proxy anmelden musst, kannst du diese Option setzen. Du solltest allerdings aufpassen, dass deine torrc nur für dich lesbar ist, da das Passwort bei der Option im Klartext aufgeschrieben wird. Beispiel: HttpProxyAuthenticator johndoe:geheim.
- ReachableAddresses, ReachableDirAddresses und ReachableORAddresses
- Wenn du nun hinter einer restriktiveren Firewall sitzt, können dir diese Optionen helfen. Mit ReachableAddresses stellst du ein, zu welchen IP-Adressen und Ports sich deine Software durch die Firewall verbinden kann. Stell dir vor, die Firewall erlaubt, HTTP- und SSH-Verbindungen zu beliebigen Hosts und verbietet Verbindungen zu 12.34.56.78 auf Port 8080. Dann könntest du folgende Einstellungen treffen: ReachableAddresses accept *:80, accept *:22, reject 12.34.56.78:8080. Die Optionen ReachableDirAddressses und ReachableORAddresses kannst du setzen, um die Verzeichnisinformationen zu beziehen bzw. mit anderen Torroutern zu verbinden. Falls diese nicht explizit gesetzt sind, nutzt Tor die Einstellung von ReachableAddresses. Interessant wird diese Option vor allem, wenn du dich über Proxies verbindest. Denn viele Proxies erlauben z.B. SSL-/TLS-Verbindungen nur über Port 443.
- KeepAlivePeriod
- Manchmal möchte man nicht, dass die Firewalls Verbindungen zu zeitig beenden. Mit der Option KeepAlivePeriod kann man bestimmen, dass Tor mit der in der Einstellung bestimmten Anzahl an Sekunden ein Paket verschickt. Somit bleibt die Verbindung bestehen. Standardmäßig steht der Wert auf 5 Minuten. Beispiel: KeepAlivePeriod 123—alle 123 Sekunden ein Paket.
Gestern hatte ich in Marcs Blog einen Kommentar zu Blogspam hinterlassen. Er wunderte sich über zu wenig Trackback- bzw. Kommentarspam und warum er denn keinen bekommt. Bei mir war auch eine ganze Weile Ruhe. Nur in den letzten Tagen kam immer mal wieder eine kleine Menge an Spam rein. Wie ich im Kommentar schon schrieb, verlaufen solche Spamattacken meist in Wellen. Heute schwappte diese nun rein. Der Load des Rechner, auf dem die Webseiten gehostet sind, stand heute morgen bei 200. Schuld war eine Unmenge von Trackbackspam. Ich hoffe, dass die Spammer nun weiterziehen und ich erstmal wieder ein paar Monate Ruhe habe.
Wie angekündigt, kommt hier der erste von verschiedenen Beiträgen zur Erklärung der torrc. Alle meine Beiträge beziehen sich auf die Version 0.1.1.26 von Tor.
Im folgenden findet ihr einige allgemeine Optionen für Tor. Nach meiner Meinung passen die nicht in die anderen Kategorien:
- DataDirectory
- In dem Verzeichnis werden alle Daten abgelegt, die Tor zum Funktionieren benötigt. Insbesondere betrifft das eine Liste verfügbarer Torserver, welche in der Datei cached-routers in obigem Verzeichnis abgelegt wird. Wenn ihr diese Einstellung ändert, achtet bitte darauf, dass das Verzeichnis nur für den Nutzer unter dem die Software läuft, les- und schreibbar ist. Beispiel: DataDirectory /var/lib/tor
- Group und User
- Diese beiden Einstellungen bestimmen, unter welcher Gruppe und mit welchem Nutzer Tor läuft. Es ist empfehlenswert, sich hier einen eigenen Nutzer anzulegen. Auf keinen Fall sollte das Programm als Nutzer root gestartet werden. Beispiel: Group tor und User tor.
- PidFile
- Beim Start wird die Prozess-ID in diese Datei geschrieben und bei erfolgreicher Beendigung dort auch wieder gelöscht. Beispiel: PidFile /var/run/tor.pid.
- RunsAsDaemon
- Hier ist nur 0 oder 1 als Wert zulässig. Wenn die Option auf 1 gesetzt wird, forkt der Prozess und läuft im Hintergrund. Unter Windows funktioniert die Einstellung nicht. Dort muss stattdessen die Option --service per Kommandozeile übergeben werden. Beispiel: RunsAsDaemon 1.
- ClientOnly
- Auch hier ist nur 0 oder 1 zulässig. Dies ist nützlich, wenn man Tor auch als Server konfiguriert hat und es im speziellen Fall nur als Client betreiben will. Sollte ClientOnly auf 1 stehen, wird Tor unter keinen Umständen als Server laufen. Ich nutze diese Option gern, wenn der Rechner an einem DSL-Anschluss läuft. Dort könnte Tor normalerweise auch als Server laufen. Aber evtl. braucht man die Bandbreite anderweitig. Beispiel: ClientOnly 1.
- SocksPort und SocksListenAddress
- Standardmäßig lauscht Tor auf dem Port 9050 am lokalen Host. Eventuell will man dies ändern. Dann sind obigen Optionen nützlich. Beispiel: SocksListenAddress 127.0.0.1 oder auch SocksListenAddress 127.0.0.1:9050 und SocksPort 9050.
-