Qbi's Weblog

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:

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.

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.

Trotz guter Netzanbindung habe ich es während der PETS nicht mehr geschafft, meine Erlebnisse zu bloggen. Daher hole ich das hier nach.

Der zweite Tag begann mit einem Vortrag über einen automatischen Beweis: Formalized Information-Theoretic Proofs of Privacy Using the HOL4 Theorem-Prover. Der Vortragende benutzte das Problem der zusammen Mittag essenden Kryptografen¹ (Dining cryptographers problem) für seine Software und versuchte zu beweisen, wie sicher das ist und wieviele Informationen unerkannt fließen.

Es folgte eine recht interessante Abhandlung zu Minx. Minx ist ein Format für anonyme Nachrichten und wurde 2004 von George Danezis und Ben Laurie entworfen. Bisher gab es über die Sicherheit nur Annahmen. Die Vortragenden fanden aufgrund einer neueren Veröffentlichung eine Möglichkeit, ein so genanntes Bitorakel zu konstruieren. Dieses ist dann in der Lage, Minx zu brechen. Die Forscher machten gleichzeitig Vorschläge, wie das Format von Minx geändert werden kann und bewiesen auch, dass dies dann sicher ist. Die Arbeit war aus meiner Sicht sehr anspruchsvoll und hier muss man wirklich erst die Originalarbeit verstanden haben, um sich dann deren Arbeit genauer anzusehen.

Den Abschluss des Vormittags bildete ein Vortrag von Steven Murdoch zu Metrics for security and performance in low-latency anonymity systems. Er forschte, wie sicher die Auswahl der Pfade bei Tor ist und kam zu dem Ergebnis, dass sowohl die existierende wie auch vorgeschlagene Auswahlmethoden sehr unterschiedliche Sicherheitsniveaus bieten. Eine allgemein gültige Aussage kann nicht getroffen werden.

Beim Mittagessen landete ich zufälligerweise am Tisch von Steven Bellovin. Wir hatten eine sehr angeregte Diskussion zu der DNS-Lücke und DNSSEC. Er philosophierte auch ein wenig darüber, wie lange es wohl dauern würde, bis .com auf DNSSEC umgestellt ist (Die Antwort liegt in der Nähe von unendlich. ). Die weiteren Vorträge nach dem Mittagessen habe ich im wesentlichen verpasst. Erst zur Rump Session hielt ich mein Ohr wieder in die Runde. Die Rump Session ist eine Reihe von fünfminütigen Vorträgen. Es sollen jeweils Ideen präsentiert werden. Es kam dort ein sehr breites Spektrum an das Rednerpult. Professoren machten Werbung für ihre Lehrstühle (Kanada scheint gerade auf viel Geld zu sitzen und es freimütig an Unis zu verteilen.), einige der Tor Google Summer of Coders präsentierten ihre Projekte und einige andere Sachen wurden präsentiert.

Abends begaben wir uns auf einen Stadtrundgang. In zwei Stunden erzählte uns ein Stadtführer sehr interessante Details zu Leuven. Irgendwann standen wir im großer Beginenhof und der Führer erwähnte eine Zwiebel auf dem Dach eines Gebäudes. Wir schauten auf Roger Dingledine, der sein Tor-T-Shirt und mussten alle lachen. Einzig der Stadtführer schaute etwas komisch und wusste nicht so recht, worum es ging. Aber auch er wurde aufgeklärt.

Der dritte und letzte Tag begann mit Vorträgen zu Reputation und Bezahlung in anonymen Netzen. Später gab es einige Kurzvorträge. Der erste, für mich interessante hieß Unlinkability without Infrastructure: Protecting Privacy with Protocol Stack Virtualization. Die Idee hier ist, eine Virtualisierung zu nutzen, um für Außenstehende die Identifizierung des eigenen Rechners zu erschweren. Jede Anwendung (oder Protokoll) gaukelt eine eigene Mac-Adresse vor, bekommt eine eigene IP-Adresse und macht Anfragen. Für einen Beobachter stehen dann vielleicht zehn Rechner im Netzwerk und er tut sich schwer, die Datenströme einer Person zuzuordnen. Bei dem Ansatz tauchen diverse, noch ungelöste Probleme auf. Es wird da noch einiges an Arbeit zu investieren sein, bis das wirklich funktioniert.

Die letzten beiden Vorträge des Tages drehten sich wieder um Tor. Einmal wird versucht, UDP für Tor zu nutzen. Der Forscher erklärte seinen Ansatz und den aktuellen Entwicklungsstand. Im Grunde genommen wird dabei, das aktuelle Design über den Haufen geworfen. Dort sah ich auch das Hauptproblem. Denn wenn man umstellen wöllte, heißt das, dass alle Nutzer auf einmal umstellen müssen bzw. es wird in der Umstellungszeit massive Probleme geben. Ian Goldberg merkte in der Diskussion an, dass seine Uni an einem ähnlichen Ansatz arbeitet. Sie könnten es hinbekommen, dass ihre Software mit dem bestehenden Protokoll funktioniert. Ganz zuletzt erzählte Karsten Loesing noch von seinen Verbesserungen zu Hidden Services. Es kam dabei zu einer lebhaften Diskussion. Am Ende standen sechs oder sieben Leute vor und kritzelten ihre Ideen fleißig an die Tafel. Ein lustiger Anblick.

Damit war die Konferenz zu Ende. In der Abschlussveranstaltung gaben die Organisatoren bekannt, dass die nächste PETS in Seattle stattfinden wird. Der Gastgeber dort ist Microsoft. Des Weiteren gab es eine lebhafte Diskussion über den zukünftigen Weg der Konferenz.

Mir hat die Veranstaltung sehr gut gefallen. Es gab sehr viele hochklassige Beiträge und Diskussionen. Natürlich war es auch eine gute Möglichkeit, mit einigen Leuten direkt ins Gespräch zu kommen. Ich habe ein paar Ideen ausgetauscht und neue mitgenommen und hoffe, dass ich die demnächst auch umsetzen kann.

Das hat nicht mit dem ähnlich klingenden Philosophenproblem zu tun. Hier geht es darum, dass drei Kryptografen zusammen essen und der Kellner alle informiert, dass das Essen bereits bezahlt wurde. Sie wollen herausfinden, ob das einer von ihnen oder ein Geheimdienst war, ohne alle zu fragen. Eine genaue Beschreibung hat der Originalartikel von Chaum.

Die Nachrichten zur Lücke in DNS wurde sehr breit diskutiert. Doch wie kann man feststellen, ob sein eigener oder der DNS-Server des Providers betroffen ist? Niels Provos hat eine Testseite aufgesetzt. Diese arbeitet mit JavaScript und zeigt an, ob der DNS-Server betroffen ist.

Wer es lieber auf der Kommandozeile hat, kann folgendes probieren:

dig +short porttest.dns-oarc.net TXT
dig @ANDERERNAMESERVER +short porttest.dns-oarc.net TXT

Kürzlich mietete ich einen Rootserver und wollte den natürlich auch in Betrieb nehmen. Nach der Installation des MTA war ich doch ziemlich verwundert, dass es gleich massenhaft Verbindungsversuche gab. Auf den ersten Blick betrafen die allesamt die Domain whiskey-soda.de und wurden mit Relay access denied abgewiesen. Warum bekomme ich deren E-Mails? Ich warf einen Blick auf den MX-Eintrag und staunte nicht schlecht:

jens@nysaino: dig -t MX whiskey-soda.de
;; ANSWER SECTION:
whiskey-soda.de.        46300   IN      MX      10  aeon.zeitguys.de.

Der A-Record von aeon.zeitguys.de zeigt auf meinen Rechenr. Alles klar!

Dadurch kamen täglich um die 4 000 E-Mails an. Also schreibe ich die Firma an und fordere sie auf, den Eintrag zu ändern. Keine Reaktion! Der whois-Eintrag hat noch eine Telefonnummer. Dort erfahre ich, dass die Firma früher unter der Nummer erreichbar war. Seit 2007 existiert Zeitguys angeblich nicht mehr. Ansprechpartner sind keine bekannt und weitere Kontaktmöglichkeiten scheint es nicht zu geben. Aber E-Mails kamen nach wie vor unentwegt. Was tun? Mögliche, sinnvolle LARTs wollten mir nicht einfallen.

Schließlich brachte eine Kontaktaufnahme mit deren Provider DD24 den erhofften Erfolg. Die Ansprechpartner der betreffenden Firma bekamen eine Frist gesetzt und der DNS-Eintrag wurde zu Fristende geändert. Jetzt lässt die Mailflut auch wieder nach und ich muss den Speicherplatz der Festplatte nicht mehr für sinnlose Logeinträge verschwenden.