![[Screenshot: Privoxy-Filter-Test in Firefox aufgerufen als 'Tor Hidden Service']](screenshot-privoxy-filter-test-demo-600x450.png "Die Diff-Zeitangaben täuschen, das Filtern dauert deutlich weniger als eine Sekunden")
Im Privoxy-Jail läuft der Privoxy-Filter-Test als Tor Hidden Service. Die Adresse ist mqim5lnbvsgomwmg.onion.
www.fabiankeil.de/blog-surrogat/2006/07/09/neues-vom-tor-server.html
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.
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.
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
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.
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.