In meiner Inbox fand ich heute dieses nette Stück Spam:
<html>
<head><title>401 Authorization Required</title></head>
<body bgcolor=“white”>
<center><h1>401 Authorization Required</h1></center>
<hr><center>nginx/1.2.1</center>
</body>
</html>
Wenn man das HTML interpretiert, kommt dann sowas raus:
401 Authorization Required
nginx/1.2.1
Ich verstehe nicht, warum man sowas als Spam in die Welt hinaus schickt. Die Nachricht wurde von einer IP-Adresse aus Südafrika eingeliefert. Neben der From:-Adresse hat der Spammer keine weiteren Header-Zeilen übermittelt. Vielleicht wollte derjenige einfach, dass ich das blogge. 
Im Hintergrund tut Serendipity oder kurz S9Y seinen Dienst. Vor mehr als sieben Jahren stieg ich von Wordpress auf die Software um. Die Software tut im wesentlichen ihren Dienst. Außer, wenn wie heute, ein Plugin merkwürdige Sachen macht.
Ich hatte bis heute abend das Autosave-Plugin installiert. Das speichert die Einträge zwischen und soll eigentlich vor Datenverlust schützen. Bei mir sorgte es dafür, dass die Rezension mehrfach verschwand. Der Grund war, dass ich auf Speichern im Artikelfenster drückte und das Fenster offen liess. Das Plugin wollte einfach alte Werte speichern und löschte so den Beitrag.
Seit dem Jahreswechsel bereitet mir nicht die Blogsoftware Kopfschmerzen, sondern der Spam der eintrudelt. Anfangs hatte ich den Spamschutz aktiviert, den S9Y von Haus aus mitbringt. Dazu setzte ich ein paar Worte auf die Blacklist. Das reichte aus. Nebenan im Datenkanal habe ich noch das Bayes-Plugin im Einsatz. Das wurde von Beginn an angelernt und verrichtet gute Dienste.
Das S9Y Infocamp hat sich nun dem Thema Spamschutz bei S9Y angenommen. In dem Podcast besprechen sie verschiedene Mechanismen. Dabei kommt die Rede auf die SpamBee. Die arbeitet unter anderem mit versteckten CAPTCHAs. Die vier Podcaster sind voll das Lobes. Ich habe den Podcast glücklicherweise zur rechten Zeit gehört. Denn direkt nachdem ich die Biene hier installierte, traf das Blog eine Spamwelle. Von den Lesern hat das vermutlich niemand bemerkt. Die Spambiene hat den Spam wirklich sehr gut abgefangen. Wer also da draußen mit Spam bei S9Y zu kämpfen hat, sollte unbedingt SpamBee probieren. Vermutlich bringt das Plugin Linderung.
Ein Add-On für den Firefox, welches 4 von 5 Sternen hat und von mehr als sieben Millionen Nutzer installiert wurde, sollte doch halbwegs vertrauenswürdig sein. Zumindest legt Linus’ Law diese Erkenntnis nahe. Das Add-On Ant Video Downloader straft diese Annahme nun Lügen.
Der Ant Video Downloader soll Videos von Youtube, Facebook und vielen anderen Seiten auf einfache Weise herunterladen. Daneben hat die Software noch einen anderen Zweck. Sie sammelt Daten über jede Seite, die der Benutzer besucht. Dazu wird eine eindeutige Nummer, die so genannte Ant-UID, angelegt. Wenn eine Webseite aufgerufen wird, sendet Ant eine zweite Anfrage mit eben dieser Nummer, der URL der aufgerufenen Seite sowie der Browserkennung an die Adresse rpc.ant.com. Somit kommt dort jeder Seitenaufruf (also auch interne URLs im privaten Netzwerk) an, den ihr jemals gemacht habt. Damit aber noch nicht genug. Bei der Deinstallation der Software wird die Informationen mit der eindeutigen Nummer, der Ant-UID, behalten. Wenn ihr die Software später neu installiert, wird genau dieselbe Nummer wieder verwendet. Das ist also eine massive Verletzung der Privatsphäre der Nutzer.
Wie ein Witz klingt da die Privacy Policy von Ant.com:
As a responsible member of the community of website owners, Ant.com solutions (Here in after Ant.com) takes the privacy and security of its users with the highest regard.
Insgesamt finde ich in der Policy keinen Hinweis auf diese Spionagemaßnahme. Glücklicherweise haben die Betreiber der Add-On-Seite die Notbremse gezogen. Zunächst wurde der Download der Software komplett deaktiviert und jetzt ist diese als experimentell gekennzeichnet. Damit sollten nur erfahrenere Nutzer diese installieren können.
Das Beispiel zeigt mal wieder, das man sich offensichtlich auf keine Software verlassen kann und insbesondere das die Warnungen bezüglich der Add-Ons sehr ernst zu nehmen sind.
via InterWeb Task Force und The Register
Eine E-Mail von GMX Internet Services GmbH
befand sich heute in meiner Inbox. Darin wurde ich aufgefordert, mein Konto zu aktualisieren:
Der Verweis zeigt auf eine korrekte Seite bei GMX. Wenn man sich die Header der E-Mail anschaut, stellt man fest, dass zwischen diversen Servern mit der Domain kundenserver.de unterwegs war. Da kommt die Frage auf, warum sollte GMX denn die Infrastruktur von 1&1 nutzen? Wenn ich nicht falsch liegen, sind die kundenserver.de-Adressen eher Root- bzw. V-Server. Auch wenn GMX und 1&1 Tochterunternehmen sind, so klingt das doch recht unwahrscheinlich. Ein paar Zeilen weiter unten fand sich dann der Eintrag:
Received: from 198.54.202.246 (IP may be forged by CGI script)
by icpu540.kundenserver.de with HTTP
id 4Ag4pp-1OmMzv2YAm-0006An; Fri, 20 Aug 2010 10:30:47 +0200
Den letzten Hinweis, dass diese E-Mail Phishing ist, lieferte ein Blick in den Quellcode der HTML-Mail. Der Link, der in meiner Mailansicht noch so unschuldig auf GMX zeigte, zeigte in Wirklichkeit auf eine Seite, die vom Firefox als Phishing klassifiziert ist.
Suchst du eine Möglichkeit, kostenlos an mein Buch Anonym im Netz
zu kommen? Neben den üblichen Quellen kannst du an einem Quiz teilnehmen. Fünf Fragen müssen richtig beantwortet werden und du nimmst an der Verlosung teil. Viel Erfolg.
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. 
