www.fabiankeil.de/blog-surrogat/2006/07/09/neues-vom-tor-server.html

Neues vom Tor-Server

Der Tor-Server hat in den letzten sechs Juni-Tagen laut Strato trotz der Ausfälle 530,03 Giga Byte umsetzen können, das Ausschöpfen des Traffic-Limits sollte diesen Monat kein Problem werden. Dafür wird auch Zwiebelkuchen sorgen, ein zweiter Tor-Server, den ich Ende Juni als Nachbrenner installiert habe.

Ich hoffe Strato fühlt sich an den Vertrag gebunden, vom Betreiber des Tor-Servers TheBigBrother habe ich erfahren, dass der Server von Strato vorübergehend wegen angeblicher DoS-Attacken gesperrt wurde – bei einem 10-Giga-Byte-Tages-Limit.

Wie aus dem ebenfalls in der Mail erwähnten Blog-Eintrag Strato + tor = DoS? hervorgeht, scheint Strato lediglich die ausgehenden Pakete innerhalb einer unbekannten Zeiteinheit zu zählen:

Der Host von Auftrag: xxxxxx wurde auf Sperrzustand: Halbsperre (Sperrgrund: DoS, Out Packets= 26141) gesetzt um 16:09:26. Die Angriffe wurden messtechnisch erfasst.

Messtechnisch erdichtet trifft es wohl eher.

Ausfall-Ursache weiterhin unbekannt

Die Fern-Diagnose der Server-Ausfälle wird dadurch sabotiert, dass die serielle Schnittstelle ebenfalls in den Abgrund gerissen wird und den Zugang zum Kernel-Debugger versperrt. Bleibt wohl nichts anderes übrig als zu versuchen, das Problem lokal zu reproduzieren.

Letzte Woche habe ich dazu auf Africanqueen mein eigenes kleines Tor-Netzwerk eingerichtet. Für ein Tor-Netzwerk sind mindestens drei Server nötig, ich habe sieben Stück eingerichtet und dazu eine ezjails Geschmacksrichtung genutzt.

Obwohl ich zu faul war die Adress-Vergabe mit zu automatisieren, dauert die Einrichtung eines fertig-konfigurierten Tor-Jails damit weniger als eine Minute. Was mir noch fehlt ist ein Programm um möglichst viele Verbindungen gleichzeitig aufzubauen, ohne dass das Programm selbst den Rechner auslastet.

Mein erster Versuch war httperf und ein voller Schlag ins Wasser. Die Optionen sind recht verworren und das Programm brach unreproduzierbar mit unknown errors ab.

Als Test-Server habe ich Gatling gewählt und die Zugriffe über trans-proxy-tor durch das Tor-Netzwerk gezwungen. Für zehn gleichzeitige Verbindungen genehmigte sich httperf 35 Prozent des Prozessors – gesehen, gelacht, gelöscht.

Hundert parallele curl-Instanzen erwiesen sich als effizienter, ich habe allerdings nicht überprüft wie viele davon auch erfolgreich waren. Um nicht zu kleckern habe ich für die Übertragung ein rumliegendes Festplatten-Image gewählt, in zwei Endlos-Schleifen forderten curl-Instanz 101 und 102 eine kleinere Log-Datei an.

Die Nacht über hatte der Rechner seinen Spass, lief aber am morgen immer noch stabil. Ich nehme an es waren zu wenig Verbindungen, habe aber noch nicht weiter drüber nach gedacht.

Geschmacksfrei

Die Jails auf tor.fabiankeil.de wurden ohne Flavours eingerichtet, mittlerweile sind es derer sechs:

[fk@tor ~]$ ezjail-admin list
STA JID   IP              Hostname                     Root Directory
--- ----- --------------- ---------------------------- -------------------------
DR  1     10.0.0.6        privoxy                      /usr/jails/privoxy
DSN N/A   10.0.0.3        gatling                      /usr/jails/gatling
DR  2     10.0.0.5        apache                       /usr/jails/apache
DR  3     10.0.0.2        buildjail                    /usr/jails/buildjail
DR  4     10.0.0.4        tor-server-2                 /usr/jails/tor-server-2
DR  5     10.0.0.1        tor-server                   /usr/jails/tor-server

von denen fünf regelmäßig genutzt werden. Anfangs hatte ich noch überlegt, Gatling als Webserver zu nutzen, die invaliden Fehlermeldungen:

fk@TP51 ~ $lynx -head -dump http://localhost:8000/gibsnicht
HTTP/1.0 404 Not Found
Content-Type: text/html
Connection: close
Server: Gatling/0.8
Content-Length: 51

<title>Not Found</title>
No such file or directory.

sowie der seltsam strukturierten Log-Informationen:

fk@TP51 /tmp/privoxy-filter-test $gatling
starting_up 0 :: 8000
start_ftp 0 :: 2121
accept 7 127.0.0.1 64282 1
HEAD/404 7 /gibsnicht 0 Lynx/2.8.5rel.4_libwww-FM/2.14 [no_referrer] localhost:8000
request_done 7
close/reqdone 7

die man noch manuell in eine Log-Datei umleiten darf, wurde ich vorerst doch wieder zum Performance-Wunder Apache getrieben worden. Der Apache soll zwar nur ein paar Paket-Filter-Graphen ausliefern – der Informations-Text zum Tor-Server existiert noch nicht – die Konfiguration hat dennoch eine halbe Ewigkeit gedauert

BSD: anständige Dokumentation serienmäßig

Die Graphen werden mit pfstat erzeugt, das ich zuerst aus den Ports installiert habe. Die dort vorhandene Version 1.7 besitzt jedoch nur einen Bruchteil der Funktionen von Version 2.2; außerdem eine komplett andere Konfigurations-Syntax. Daniel Hartmeiers pfstat.conf für pfstat 2.2 wurde nicht akzeptiert, daher bin ich ebenfalls auf 2.2 umgestiegen.

Sie ließ sich auch ohne Probleme kompilieren, scheiterte aber am Auslesen der Queue-Statistiken, da der ioctl(2)-Befehl DIOCIGETIFACES angeblich nicht unterstützt wurde. Im Gegensatz zu anderen freien Betriebssystemen verfügen BSDs über anständige Dokumentation, der auszugsweise Vergleich von OpenBSDs pf(4) und dem FreeBSD-Gegenstück ersparte die Rätselei.

Unter OpenBSD liefert DIOCIGETIFACES:

struct pfi_kif {
   RB_ENTRY(pfi_kif)                pfik_tree;
   char                             pfik_name[IFNAMSIZ];
   u_int64_t                        pfik_packets[2][2][2];
   u_int64_t                        pfik_bytes[2][2][2];
   u_int32_t                        pfik_tzero;
   int                              pfik_flags;
   struct pf_state_tree_lan_ext     pfik_lan_ext;
   struct pf_state_tree_ext_gwy     pfik_ext_gwy;
   TAILQ_ENTRY(pfi_kif)             pfik_w_states;
   void                            *pfik_ah_cookie;
   struct ifnet                    *pfik_ifp;
   struct ifg_group                *pfik_group;
   int                              pfik_states;
   int                              pfik_rules;
   TAILQ_HEAD(, pfi_dynaddr)        pfik_dynaddrs;
};

unter FreeBSD:

struct pfi_if {
   char			      pfif_name[IFNAMSIZ];
   u_int64_t		      pfif_packets[2][2][2];
   u_int64_t		      pfif_bytes[2][2][2];
   u_int64_t		      pfif_addcnt;
   u_int64_t		      pfif_delcnt;
   long			      pfif_tzero;
   int			      pfif_states;
   int			      pfif_rules;
   int			      pfif_flags;
};

Mit pfstat-2.2.diff konnten dann auch die gewünschten Daten ohne Fehlermeldungen ausgelesen werden.

Queues habe ich bis vorgestern auf dem Server gar nicht eingesetzt und konnte den Patch daher nicht überprüfen. Priorisierung von leeren ACKs war die Lösung, die Umsetzung dauerte weniger als eine Minute.

Wie pfctl zeigt, bringt das auf dem Server keinen Vorteil:

[fk@tor ~]$ sudo pfctl -vvsq
Password:
queue q_pri priority 7 
  [ pkts:    1699097  bytes:   95274334  dropped pkts:      0 bytes:      0 ]
  [ qlength:   0/ 50 ]
queue q_def priq( default ) 
  [ pkts:   11654971  bytes: 10607025228  dropped pkts:  15061 bytes: 9148639 ]
  [ qlength:   0/ 50 ]

queue q_pri priority 7 
  [ pkts:    1699584  bytes:   95303544  dropped pkts:      0 bytes:      0 ]
  [ qlength:   0/ 50 ]
  [ measured:    97.4 packets/s, 46.74Kb/s ]
queue q_def priq( default ) 
  [ pkts:   11657928  bytes: 10609842605  dropped pkts:  15061 bytes: 9148639 ]
  [ qlength:   0/ 50 ]
  [ measured:   591.4 packets/s, 4.51Mb/s ]

^C

Die Anbindung hat genug Luft, die Queues bleiben leer und eventuell vorhandene Flaschenhälse stünden sowieso stromaufwärts – die Daten stimmen aber mit den Graphen überein, der Patch wird wohl korrekt sein.

Demo des Privoxy-Filter-Tests verfügbar

[Screenshot: Privoxy-Filter-Test in Firefox aufgerufen als 'Tor Hidden Service'] Im Privoxy-Jail läuft der Privoxy-Filter-Test als Tor Hidden Service. Die Adresse ist mqim5lnbvsgomwmg.onion.

Die Reaktions-Zeiten sind akzeptabel. Fasterfox ermittelte etwas unter 9 Sekunden für den anonymisierte Weg hin und zurück sowie die vernachlässigbare Filterung von ein paar Privoxy-Log-Zeilen.

Eigentlicher Grund für den Screenshot ist natürlich die vor ein paar Wochen aktivierte Xorg-Transparenz. Der praktische Nutzen geht stark gegen Null, wenn mir das nächste mal ein geifernder Mac-Hansel über den Weg lauft, ist der Rechner jedoch präpariert.

Durch die Zeilen:

#Transparenter
"transset-df --min 0.1 -p --dec 0.05"
   Control + b:6

#Opaker
"transset-df -p --inc 0.05"
   Control + b:7

in ~/.xbindkeysrc lässt sich die Transparenz des unter dem Cursor liegenden Fensters bei gedrückter Steuerungs-Taste über Mousepad-Streicheln regeln. Kopiert habe ich dazu aus der Gentoo-Wiki-Seite Xorg X11 and Transparency. Die dortige Lösung nutzt allerdings das Maus-Rad und damit recht grobe Sprünge.