Skip to content

Spamschutz bei S9Y

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.

Behördenwillkür bei Jacob Appelbaum

In Deutschland dreht sich derzeit die Diskussion um den Bundestrojaner, der vom CCC gefunden wurde. Derweil spielt sich in den USA ein anderes Drama ab.

Jacob Appelbaum kann man nur als vielseitigen Zeitgenossen bezeichnen. Er arbeitet beim Tor-Projekt als Entwickler, hat in der Vergangenheit einige spektakuläre Ergebnisse im Bereich der IT-Sicherheit gefunden, engagiert sich bei WikiLeaks, half Hurrikanopfern usw. Die Liste lässt sich beliebig erweitern. Doch eines seiner Hobbys brachte ihm Probleme ein. Auf der Konferenz The Next HOPE hielt er im Juli 2010 einen Vortrag zu WikiLeaks (siehe unten). Seitdem wird Jacob bei jedem Grenzübertritt aus den USA oder in die USA kontrolliert. Das heißt, er wird zum Teil stundenlang festgehalten und befragt. Ihm wurden Geräte weggenommen und anderes mehr. Jetzt werdet ihr euch fragen, auf welcher Basis dies passierte. Dies ist bis heute unklar! Es gibt keine Anklage. 

Nachdem das Justizministerium Informationen von Twitter über Jacob Appelbaum und andere Aktivisten wollte, geht die US Regierung noch einen Schritt weiter. Sie forderte von Google und von dem Provider Sonic alle E-Mail-Adressen mit denen Appelbaum in den letzten zwei Jahren kommunizierte. Ein Artikel im Wall Street Journal hat weitere Details zu der Sache.

Welchen Erkenntnisgewinn soll eine solche Sache bringen? Wenn man die diversen Schritte der Behörden verfolgt, drängt sich der Verdacht auf, dass es nur um Schikane geht. Jacob kann man wohl nichts Böses nachweisen und so scheinen die Behörden einfach ein Exempel zur Abschreckung aufzubauen. Ich kann nur hoffen, dass die Vorgang ein Ende hat und Jacob sich wieder seinen Interessen widmen kann.  

Continue reading "Behördenwillkür bei Jacob Appelbaum"

Fingerprints von SSL-Seiten prüfen

Das Desaster um die niederländische Zertifizierungsstelle DigiNotar zieht derzeit immer noch seine Kreise. Mir scheint es noch zu früh, um hier etwas dazu zu schreiben. Vielmehr will ich ein paar Worte verlieren, wie ich „meine eigene CA betreibe“. Denn schon seit längerem vertraue ich nicht, den von den Browsern mitgelieferten Zertifizierungsstellen (CA). Zumeist lösche ich alle und gebe dann einzeln Vertrauen.

Der beste Weg, um einem SSL-Zertifikat zu vertrauen, wäre, sich bei dem Betreiber zu melden und über einen sicheren Kanal den Fingerprint des Zertifikats zu klären. Mein Browser zeigt mit für die Seite Wikipedia-SSL-Seite den Fingerprint (SHA-1) BA:8A:BE:34:B1:34:3B:AF:06:05:4B:48:A9:27:AA:D9:B4:75:45:6E an. Wenn ich bei der Wikipedia anrufe und diese mir denselben nennen, so habe ich das korrekte Zertifikat. Dabei nehme ich natürlich an, dass das Telefon ein sicherer Weg zum Austausch der Informationen ist. Aber beispielsweise druckt die lokale Sparkasse eben diesen Fingerprint auf ihre Dokumente. Damit kann ich das als Kunde leicht verifizieren.

Wie das Beispiel Wikipedia aber schon zeigt, ergibt sich da ein Problem.Woher bekomme ich den Fingerprint? Muss ich bei Jimmy Wales direkt anrufen oder gar nach FloridaKalifornien¹ reisen? Hier kam nun meine Idee ins Spiel.

Ich habe auf diversen Servern einen Zugang, d.h. ich kann mich von der Ferne einloggen und dann dort arbeiten. Die Rechner stehen in verschiedenen Netzen und zum Teil auf verschiedenen Kontinenten. Nun logge ich mich auf den Servern ein, lade das Zertifikat herunter und lasse mir den Fingerprint anzeigen. Wenn dieser auf allen Rechner gleich ist, dann gehe ich davon aus, dass ich das korrekte Zertifikat angezeigt bekomme. In dem Fall akzeptiere ich das und vertraue dem. Sollten die Fingerprints abweichen, dann akzeptiere ich das nicht und recherchiere dem in der Regel ein wenig hinterher.

Jörg Sommer hat das nun ein wenig automatisiert und ein zsh-Skript (Quelltext weiter unten) geschrieben. Das wird folgendermaßen aufgerufen:

ssl-fp-check [-l] sslsi.te[:port] ssh1 [ssh2] [ssh3] ...

Dabei ist sslsi.te die Webseite, die geprüft werden soll. Ohne die Angabe eines Ports verwendet das Skript standardmäßig 443. Danach wird eine oder mehrere SSH-Verbindungen angegeben. Das Skript wird nun versuchen, sich überall einzuloggen und gibt dann den Fingerprint aus. Für den Fall, dass es auf dem Zielsystem kein OpenSSL gibt, existiert die Option -l. Dabei wird dann ein Tunnel gebaut und das lokale installierte OpenSSL verwendet.

Also für Wikimedia habe ich folgendes eingeben:

ssl-fp-check secure.wikimedia.org a b c d
a: SHA1 Fingerprint=BA:8A:BE:34:B1:34:3B:AF:06:05:4B:48:A9:27:AA:D9:B4:75:45:6E
b: SHA1 Fingerprint=BA:8A:BE:34:B1:34:3B:AF:06:05:4B:48:A9:27:AA:D9:B4:75:45:6E
c: SHA1 Fingerprint=BA:8A:BE:34:B1:34:3B:AF:06:05:4B:48:A9:27:AA:D9:B4:75:45:6E
d: SHA1 Fingerprint=BA:8A:BE:34:B1:34:3B:AF:06:05:4B:48:A9:27:AA:D9:B4:75:45:6E

Die SSH-Server a, b, c und d gaben also denselben Fingerprint aus. Also würde ich dem ganzen doch vertrauen. :-)

Ich werde das Skript jetzt wahrscheinlich immer verwenden. Es macht das Leben doch deutlich einfacher.

Continue reading "Fingerprints von SSL-Seiten prüfen"

Firefox Add-On Ant Video Downloader spioniert Nutzer aus

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

Schweigen ist Gold

Eine alte Redewendung besagt: „Reden ist Silber, Schweigen ist Gold.“ Gerade im Hinblick auf polizeiliche Ermittlungen ist dieser Hinweis wirklich Gold wert.

Auf dem 23C3 begeisterte der Rechtsanwalt Udo Vetter viele Zuhörer mit seinem Vortrag Sie haben das Recht zu schweigen. Er gab damals einige Hinweise, wie man sich bei einer Hausdurchsuchung verhalten soll. Der mit Abstand wichtigste Hinweis fand sich schon im Titel.

Einige Zeit später stieß ich auf ein Video eines amerikanischen Professors (siehe unten). Auch er erklärte seinen Zuhörern, warum es beim Kontakt mit den Polizeibehörden wichtig ist, nichts zu sagen. Dabei ging er recht methodisch vor und machten an verschiedenen Profilen (Schuldige, Unschuldige, Lügner, Ehrliche etc.) klar, dass niemand einen Vorteil hat, ohne Anwalt mit den Behörden zu reden. Der Vortrag wurde von einem Ermittler ergänzt, der seine Rede mit einer vollumfänglichen Bestätigung des Vorredners begann.

Dennoch hat sich diese Erkentnis noch nicht herumgesprochen und sogar hochrangige Personen tappen in die Falle. Der aktuelle The New Yorker beschreibt die Geschichte von Thomas Drake, einem Ex-NSA-Mitarbeiter und Whistleblower. Drake misfiel die enorme Geldverschwendung der Behörde sowie die Unrechtmäßigkeit der Abhörmaßnahmen. Nachdem er intern keinen Erfolg mit seinen Beschwerden hatte, wandte er sich an die Medien. Durch die Berichte in der Baltimore Sun kam es zu Ermittlungen und er wie einige andere stand im Fokus von Ermittlungen. Bei einer Hausdurchsuchung machte er dann wohl einen entscheidenden Fehler:

…, he viewed the raid as a fresh opportunity to blow the whistle. He spent the day at his kitchen table, without a lawyer, talking. […] He also disclosed his computer password.

Insgesamt kooperierte Drake lange Zeit mit den Behörden und versuchte sich dadurch einen Vorteil zu verschaffen. Mittlerweile ist das Ausmaß seiner „Verbrechen“ klar. Laut Anklageschrift soll er fünf geheime Dokumente entwendet und die Behörden belogen haben. Interessanterweise hatte eines der Dokumente keinerlei Sicherheitseinstufung. Nach der Anklage war das falsch eingestuft und hätte geheim sein müssen. Die Schrift behauptet, das hätte er  wissen müssen. Ein zweites Dokument wurde drei Monate nach der Anklage deklassifiziert, also als nicht geheim erklärt. Dafür erwartet ihn unter Umständen eine Strafe von 35 Jahren im Gefängnis. Bei der Anklage ist der Punkt mit der Lüge interessant. Denn wie der oben erwähnte Professor schon ausführte, kann eben genau das passieren, wenn man sich mitteilt. Das heißt, erzählt man etwas, dass sich später als unwahr herausstellt bzw. die Ermittler der Meinung sind, dass es unwahr ist, so führt das zu einem Extra-Anklagepunkt.

Aber selbst wenn sich jemand vornimmt, nichts zu sagen, so dürfte das in der realen Situation schwierig sein. Zum einen ist eine Hausdurchsuchung für die meisten eine sehr ungewohnte, belastende Lage. Hier wird es schwer, sich an seine „Vorsätze“ zu erinnern. Zum anderen beschreibt der oben genannte Ermittler die Verhältnisse ganz gut. Er sagt: „Stellen Sie sich vor, ein Normalbürger steigt mit einem Profiboxer in den Ring. Wer wird den Kampf gewinnen?“ Der Profiboxer ist in dem Fall der Ermittler, der eine umfassende Ausbildung darin bekommen hat, wie er Menschen zum Reden bekommt. Aber wer von euch hatte schon eine Ausbildung im Schweigen? :-) Der Ermittler beschreibt auch sehr schön die diversen Tricks, mit denen er sein Ziel erreicht.

Solltet ihr mal in eine solche Situation kommen, dann antwortet einfach auf jede Anfrage eures Gegenübers mit dem Satz: „Bitte nehmen Sie zur Kenntnis, dass ich keine Aussage machen möchte“ (frei nach den Worten von Udo Vetter). Hoffentlich wird dann alles gut. ;-)

Continue reading "Schweigen ist Gold"

Warum sollte GMX fremde Mailserver zum Versand nehmen?

Eine E-Mail von GMX Internet Services GmbH befand sich heute in meiner Inbox. Darin wurde ich aufgefordert, mein Konto zu aktualisieren:

Ansicht der Phishing-Mail

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.

Zeitreisen

Gerade eben erhielt ich eine E-Mail, die eine Zeitreise hinter sich hatte. Laut der Received-Zeilen kam sie 16 Sekunden vor dem Absenden an. :-)

Received: from mailgate.example.com (mailgate.example.com [137.81.163.19])
	by speedo.dreamhostps.com (Postfix) with ESMTP id DB3643E580B9
	for <**HIDDEN**@spam.la>; Tue,  6 Jul 2010 09:09:59 -0700 (PDT)
Received: from sclamo (p2A5B7AB9.dip.t-dialin.net [42.91.122.185])
	(authenticated bits=0)
	by mailgate.example.com (8.14.3/8.14.1) with ESMTP id o66G9xbZ006662
	for <**HIDDEN**@spam.la>; Tue, 6 Jul 2010 18:10:04 +0200
Received: by sclamo (Postfix, from userid 1271)
	id 1A5DBC185; Tue,  6 Jul 2010 18:10:15 +0200 (CEST)
cronjob