Qbi's Weblog

Update: Die Veranstaltung wurde leider abgesagt.

Die Frage Freiheit oder Sicherheit? wird in der politischen Debatte um Bürgerrechte immer wieder postuliert. Die Evangelische Akademie Thüringen nimmt sich im Rahmen eines Seminars diesem Thema an. Das Seminar Web 2.0 – Stasi 2.0 trägt den Untertitel Perspektiven freiheitlicher Demokratie in der digitalisierten Medienwelt und geht insgesamt über drei Tage.

Am 24.September 2010 finden Vortrag und Diskussion zu Freiheit oder Sicherheit? Nutzen und Gefahren der Vorratsspeicherung von Kommunikationsdaten. mit Dr. Christoph Bergner und Rena Tangens statt. Am folgenden Samstag startet der Tag mit einer Diskussion. Tankred Schipanski, Dr. Jan Schönfelder und Christopher Ramm bearbeiten dabei das eingangs genannte Thema. Am Nachmittag stehen dann Workshops auf dem Plan. Frank Reuschel von der Internetermittlung des LKA Thüringen wird einen Einblick in seine Arbeit geben. Friedrich Doehring erzählt, welche Spuren im Netz er auswertet, um gutes Personal zu finden und ich werde darlegen, wie man seine Spuren möglichst gut versteckt.Der Tag klingt dann mit einem Vortrag des ehemaligen Ministerpräsidenten des Landes Sachsen-Anhalt, Dr. Reinhard Höppner aus.Am Sonntag morgen wird die Frage gestellt, wie sich politische Ziele umsetzen lassen. Auf dem Podium treffen sich Vertreter von SPD, Grünen, Piratenpartei sowie der Aktion Zivilcourage Pirna e.V.

Ich glaube, dass das ein sehr interessante Veranstaltung wird und würde mich über rege Teilnahme freuen. Die Anmeldung erfolgt über die Seiten der EAT.

Vor nicht allzu langer Zeit sass ich entspannt bei einem Kaffee und wollte meinen Rechner starten. Einschaltknopf gedrückt und der Bildschirm lächelte mich mit einer Fehlermeldung an:

error: unexpectedly disconnected from boot status daemon
Begin: Waiting for root file system ...

grml, warum muss das ausgerechnet jetzt passieren? Sehr schnell war klar, dass ich an dieser Stelle nicht weiter komme. Also bootete ich einen alten, funktionierenden Kernel und änderte meine grub-Einstellungen entsprechend. Damit lebte ich einige Zeit gut, bis mir mal wieder der Workaround auffiel. Jetzt wollte ich das Problem mal genauer angehen.

Die Fehlermeldung, die irgendwas von dem Boot Status Daemon erzählte, schien auf plymouth hinzudeuten. Der Sinn der Software ist es, den Bootprozess zu verschönern. Das heißt, es macht schicke Bildchen anstatt der Kernelmeldungen.

Der Bugtracker von Debian hatte einen Eintrag zu meiner Meldung. Die in dem Bugreport genannten Einstellungen änderten bei mir nichts am Problem. In meinem nächstem Versuch wollte ich plymouth deinstallieren. Aber da gab es eine winzige Abhängigkeit zu mountall(8). Der Zufall führte mich zu einem angepasstem Paket, mit dem plymouth deinstalliert werden kann. In freudiger Erwartung startete ich den Rechner neu. Aber es wäre nur zu schön gewesen, wenn sich das Problem so leicht lösen ließe.

Zu diesem Zeitpunkt kam mir in den Sinn, die Bootoptionen quiet und splash zu entfernen. Siehe da, ein wenig mehr kam zum Vorschein:

Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Waiting for root file system ...

Warten, warten und nochmal warten. Oh, nun noch eine BusyBox-Shell:

(initramfs) Gave up waiting for root device. Common problems:
...
ALERT! /dev/disk/by-uuid/.... does not exist. Dropping to a shell!

Nebenbei stellte ich dann fest, dass die Meldung mit dem Boot Status Daemon nur bei einer speziellen Kernelversion auftrat. Die Meldung oben konnte ich mit jeder Standard-Ubuntu-Kernelversion größer als 2.6.32-20 erzeugen. Für mich wäre es viel wichtiger zu erfahren, woher denn diese Meldung stammt!

Ein Hinweis brachte mich dann zu den Mainline-Builds. Das sind spezielle Pakete des Ubuntu Kernelteams, die recht nahe am Original-Kernel sind. Ich versuchte wieder diverse Versionen. Alle brachten mir die Fehlermeldung. Na gut, dann baue ich eben einen eigenen Kernel.

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
cp /boot/config-2.6.32-24-generic /usr/src/linux-2.6/.config
make oldnoconfig
make deb-pkg
dpkg -i ../linux*.deb
reboot

Beim ersten Reboot startete der Kernel tatsächlich korrekt. Sollte Ubuntu wirklich einen Bug in den eigenen Kernel eingebaut haben? Plötzlich fiel mir ein, dass die Zeile im grub einen kleinen, aber feinen Unterschied zu den restlichen Einträgen aufwies. Ich hatte root=/dev/sda1 angegeben. Alle anderen Einträge trugen root=UUID=.... Also versuchte ich die Änderung bei den anderen Kerneln und es klappte. Jede Kernelversion bootete mit dieser Änderung.

Jetzt muss ich nur noch herausfinden, warum das nicht klappt und ich bin wieder ein glücklicher Mensch.

Das Bild stammt vom Blog Linux und ich

Das Wagnis startete heute nachmittag. Nach diversen Backup-Orgien war es an der Zeit, das Ubuntu auf die aktuelle Variante 10.04 zu upgraden. Ich wollte mal testen, ob das weitgehend klappt und hatte mich innerlich auf eine Neuinstallation eingerichtet. Doch, oh Wunder, bislang konnte ich kaum Probleme feststellen. Eines, was sofort auffiel, war die Schrift. Die ist bislang noch sehr ungenügend hier muss ich eine Lösung finden. Das zweite Problem war der Spamfilter CRM114. Das wurde aber schon während der Installation angekündigt, dass es Probleme geben kann. Bei der Suche nach der korrekten Schriftart stieß ich u.a. auch auf Comic Sans. Das wäre doch die beste Wahl:

Gerade bin ich wieder baff. Google DNS macht mich heute sprachlos.

Vor etwa einem Monat schrieb ich hier über die Aktion von Ingate, bei der es einen VServer zu gewinnen gab. Nach einiger Wartezeit kamen die Zugangsdaten an und derzeit richte ich den Rechner ein. Zur Einrichtung gehört mittlerweile für mich ein Test der Geschwindigkeit des (voreingestellten) DNS. Mittels einem Python-Programm namens namebench lässt sich das hervorragend machen. Im Blog findet sich dazu ein Beitrag. Nun spuckte namebench soeben das Ergebnis aus. Der Nameserver von Google ist fast viermal so schnell wie der beim Provider. Das ist so ziemlich die krasseste Abweichung, die ich bisher fand. Trotzdem bestätigt das, was ich bisher ermittelte. In allen meinen Versuchen seit Juni war immer der Nameserver von Google der schnellste. Außerdem zensiert der nicht. Insofern könnte man ihn jedem Nutzer empfehlen. Letztlich bleibt der hinlänglich diskutierte Datenschutzaspekt. Wer den nutzt, überlässt einmal mehr Daten einer Firma. Das will wohlüberlegt sein.

Untenstehend mal die Auswertung von namebench zum VServer von Ingate:

IP	Descr.	Hostname	Avg (ms)	Diff	Min	Max	TO	NX	Notes
8.8.4.4	Google Public DNS-2	google-public-dns-b.google.com74.125.42.87 74.125.42.82 74.125.42.81	57.88	259.0%	9.6	737.2	0	4
156.154.71.1Neustar Ultra Recursive	UltraDNS-2	rdns2.ultradns.netudns2tcam.ultradns.net udns3tcam.ultradns.net	86.60	139.9%	16.4	874.3	0	3	NXDOMAIN Hijacking
4.2.2.4If you have a legitimate reason for requesting this info, please contact hostmaster@Level3.net	Level 3/GTEI-4	vnsc-pri-dsl.genuity.netdns2.frf1	87.69	136.9%	7.1	1310.7	0	5
78.47.115.1989.4.3b2	Cesidio 6 DE	ns6.cesidio.netns6.cesidio.net	113.52	83.0%	4.0	1006.2	0	50	Replica of Cesidio B DE [78.47.115.197]
212.123.96.110	SYS-212.123.96.110	dns01.ip-exchange.de	150.74	37.8%	3.2	1625.3	0	4	A backup DNS server for this system.
208.67.220.220	OpenDNS	resolver2.opendns.com12.ams	166.42	24.8%	14.6	3500.0	1	1
194.8.57.129.6-ESV-R1	Nurnberger IX DE	ns.N-IX.netrNS2	167.84	23.8%	4.0	1589.1	0	4
212.114.153.1	Secondary-DNS DE	ns.secondary-dns.de	181.08	14.7%	1.2	1643.7	0	4
80.190.211.10	SYS-80.190.211.10	dns03.ip-exchange.de	207.77		0.6	1611.9	0	4	The current preferred DNS server.
216.146.35.35unbound 1.3.4	DynGuide	resolver1.dyndnsinternetguide.comig-02-fra.dyndns.com	228.13	-8.9%	23.5	3500.0	2	3	NXDOMAIN Hijacking
83.142.86.1	CS-Arena DE	ns1.core-backbone.com	242.89	-14.5%	3.5	3500.0	2	5	dns.query.BadResponse (2 requests)

Das Tor-Projekt ist vor allem bekannt für die gleichnamige Software. Daneben entwickeln die Macher eine Vielzahl weiterer Software, die ebenfalls die Anonymität und Privatsphäre seiner Nutzer stärkt. Bekannte Projekte sind Vidalia, die Erweiterung für den Mozilla Firefox Tor-Button oder die kürzlich vorgestellte Erweiterung HTTPS Everywhere. Jacob Appelbaum stellte kürzlich ein weiteres Projekt ttdnsd vor. Der Name steht für Tor TCP DNS Daemon und versucht alle DNS-Verbindungen über Tor zu leiten.

Derzeit muss die Software entweder aus den Quellen oder als Debian-Paket installiert werden. An RPMs wird noch gearbeitet. Eine Unterstützung für Windows ist noch nicht umgesetzt. Nach der Installation läuft die Software als Dienst im Hintergrund. In der Datei /etc/ttdnsd.conf befindet sich die Konfiguration. Standardmäßig enthält diese den Nameserver von Google mit der Adresse 8.8.8.8. Weitere Nameserver können eingetragen werden. Ich lasse immer mal wieder namebench laufen und wähle aus der Auswertung einige Server aus. Es empfiehlt sich, aus der Liste der zensurfreien Server einige zu wählen. Die Anzahl der Einträge in der Datei ist unbegrenzt. Die Software wählt bei jedem Lauf zufälligerweise einen Eintrag aus.

Nachdem die Software eingerichtet wurde, sollte auch das eigene System überredet werden, den ttdnsd für DNS-Anfragen zu nutzen. Im einfachsten Fall öffnet ihr die Datei /etc/resolv.conf und tragt dort die Zeile nameserver 127.0.0.1 ein. Wenn ihr dynamische IP-Adressen nutzt, hat das unter Umständen den Nachteil, dass der Eintrag bei jeder Aktualisierung überschrieben wird. Für Ubuntu würde ich daher empfehlen, in der Datei /etc/dhcp3/dhclient.conf den Eintrag prepend domain-name-servers 127.0.0.1; zu setzen. Dann wird der Nameserver bei jedem Update korrekt in die /etc/resolv.conf eingetragen. Wenn ihr nur einmalig testen wollt, könnt ihr natürlich dem jeweiligen Programm die Adresse übergeben: dig @127.0.0.1 torproject.org oder host torproject.org 127.0.0.1.

Die Beantwortung von Anfragen über Tor dauert natürlich etwas länger als über eine nicht anonymisierte Verbindung. Kai Raven hat in seinem Wiki eine Beschreibung zum DNS-Proxy pdnsd. Dieser hat einen Zwischenspeicher für DNS-Anfragen und antwortet schneller, wenn die Ergebnisse in seinem Speicher sind.

Der ttdnsd ist noch in Entwicklung, d.h. einige Stellen im Quellcode müssen überarbeitet werden und derzeit kann ein Angreifer den Anfragen an dem Server vorbei leiten. Diese Punkte sind bekannt und sollen in den folgenden Versionen behoben werden. Ich halte die Software schon benutzbar und kann euch einen Test nur ans Herz legen.

Durch einen Beitrag bei Hacker News ließ ich mich zu einem englischsprachigen Beitrag hinreißen. Im folgenden kommt das nochmal für meine deutschsprachigen Leser:

In dem Beitrag Improving your resolv.conf file verweist der Autor auf die Möglichkeit, drei nameserver-Einträge in der /etc/resolv.conf zu haben. Dabei schlägt er insbesondere vor, option rotate zu verwenden. Denn damit werden die Anfragen an DNS-Server besser unter den eingetragenen Servern verteilt. Nun besteht die Frage, woher soll man denn drei Nameserver nehmen. Wer von euch kennt drei aus dem Kopf? Durch die beiden Google-eigenen 8.8.8.8 und 8.8.4.4 ist das sicher ein wenig einfacher geworden. Aber sind das wirklich die schnellsten? Rausfinden lässt sich das mit einem kleinen Programm namens namebench.

In der Standardeinstellung durchsucht das Programm den Verlauf eures Browsers und extrahiert einige Domainnamen. Man kann dem Programm aber auch eine Liste von Domainnamen geben oder es anweisen, sich ein paar Zufallswerte bei Alexa zu besorgen. Mit den Werten testet das Programm diverse DNS-Server und misst deren Geschwindigkeit. Nach einer Wartezeit wird dann der Bestwert ausgegeben. Weiterhin gibt das Programm eine Empfehlung für die optimale /etc/resolv.conf und zeigt die Messwerte grafisch an (verwendet die Google API zum Zeichnen der Diagramme).

Ich finde das Programm äußerst nützlich. Bis auf meinen Rechner zu Hause fand die Software immer viel schnellere Varianten. Im Extremfall ging das bis zu 200% schneller.

Continue reading "Wie man den optimalen Nameserver findet"

While reading Hacker News I came across an entry titled Improving your resolv.conf file. The author describes how to use and rotate three nameservers in your /etc/resolv.conf. But how would anyone know which are the fastest nameservers around? The answer is: namebench.

The software will look up your browser history, collect some random hostnames and then run DNS queries. All those queries are benchmarked and in the end the software will tell you, which of the DNS servers was the fastest. In my case the answer was often Google’s own servers, but at some occassions namebench came to different conclusions. In my opinion it’s worth trying out.

Continue reading "Improving your resolv.conf file -- part 2"