Das Problem:

Akismet sammelt Daten jedes Kommentarauthors um diese zu überprüfen. Darunter sind: IP-Adresse, E-Mail, Homepage sowie Inhalt des Kommentars. Das wäre alleine noch kein Problem, doch damit diese Daten überprüft werden, werden die Daten zu US-Servern geschickt. Nach deutschem Recht verstößt das gegen das Datenschutzgesetz. Das gleiche gilt für Tracking-Tools wie Google-Analytics.

Die Lösung:

Es gibt alternative und bessere Plugins als Akismet. Am populärsten ist wohl das deutsche Plugin „AntiSpamBee“ von Sergej Müller. Dieses Plugin sammelt weder Date, noch nutzt es US-Server zur Auswertung. Die Konfiguration ist einfach und dank einer umfangreichen Dokumentation kann man eigentlich nichts falsch machen. Wer dennoch Akismet weiter nutzen will, der sollte einen Datenschutzhinweis in seinen Blog oder Impressum einbauen.

Bild von eriwst (Flickr)

Begonnen hatte es am 29.01 gegen 00:13 um diese Zeit habe ich geschlafen, sodass ich natürlich nicht mitbekam, dass ich die erste Mail vom Plugin „Limit Login Attempts“ erhielt. Dieses Plugin kann ich allen nur sehr ans Herz legen, es hat mir während des ganzen Angriffes gut geholfen. Hätte ich es nicht eingesetzt so würde es WP – Blogger wohl nicht so schnell in dieser Form wieder verügbar sein. Nun ich dachte mir bei dieser ersten Mail nicht viel, vielleicht hatte jemand am Adminbereich rumgespielt nur aus Spaß.

Dieser Eindruck änderte sich schlagartig gegen 14:37. Ich erhielt eine Mail von WordPress, dass jemand auf Passwort vergessen geklickt hätte. Im Klartext sah diese Mail so aus:

Jemand hat für den folgenden Blog und Benutzernamen das Passwort zurückgesetzt.

http://wp-blogger.de

Benutzername: deichy

Um dein Passwort zurückzusetzen, besuch die folgende Adresse. Wenn du das nicht möchtest, ignoriere diese E-Mail einfach und nichts wird passieren.

***Link zum Zurücksetzen***

Jetzt wurde ich stutzig, denn ich konnte mich sehr wohl an die Mail vom Morgen erinnern. Nur schade, dass dort keine IP steht sonst hätte ich das Ganze mit der Echtzeit Analyse Wassup zurückverfolgen können.

Nachdem das geschehen war, bekam ich weitere Mails vom Plugin „Limit Login Attempts„. Sowohl für De-Script, für WP-Blogger und für eine weitere Kunden-Homepage. Gleichzeitig wurde auf dieser Kundenhomepage auch das Passwort zurückgesetzt. Dank „Wassup“ konnte ich beobachten wie auf

Bild von dongga BS (Flickr)

De-Script und WP-Blogger verdächtigerweise von den gleichen IP’s die xmlrpc.php angesprochen wurde. Unter anderem mit diesen Befehlen, welche einzelne Dateien löschen oder ändern sollen. Das hat in Einzelfällen sogar geklappt.

Außerdem fand ich im Rootverzeichnis der Kunden-Homepage eine .exe Datei. Diese hat die index.php vermutlich geändert. Im Normalfall ist die index.php von WordPress wenige Zeilen lang. Nachdem der Angriff geschehen war, gabs zuerst eine Fehlermeldung beim Aufrufen der Seite welche auf Fehlerhaften PHP Syntax zurückführte. Also schaute ich nach und siehe da keine kurze index.php, nein, das waren 2000 Zeilen Code. Nachdem die .exe Datei gelöscht war und eine alte index.php eingespielt war funktionierte alles wieder problemlos.

Somit fuhr ich abends meinen PC runter in guter Gewissheit, dass alles funktioniert. Vorher waren jedoch noch etwa 6 Mails vom Plugin „Limit Login Attempts“ eingegangen. Jedesmal unterschiedliche IP’s aber der gleiche Hostname. Somit deutet das auf einen gekaperten Server hin. Wie ich später rausfand gehörten diese Server zu Amazon.

Am nächsten Morgen traute ich meinen Augen kaum. 32 Mails vom Plugin, alles unterschiedliche IP’s. Außerdem hatte wieder jemand gegen 1:00 Uhr versucht mein Kennwort auf De-Script zurückzusetzten. Auf Wp-Blogger war der Admin Bereich zerschossen und somit durfte ich ein Backup einspielen.

Nachdem ich dann eine Mail an meinen Server Support schrieb und dieser die betreffenden IP’s sperrte hörten die Angriffe auf. Es wurde eine Beschwerde bei Amazon eingelegt und es stellte sich heraus, dass es Postlink-Server waren von welchen aus der Angriff gestartet wurde.

Jetzt stellt sich die Frage wie ist der Angreifer reingekommen? Durch den Admin Bereich nicht und auch über FTP nicht. Dank Logfiles war es die xmlrpc.php welche oft aufgerufen wurde. Diese Datei dient dazu Trackbacks und Pingbacks zu empfangen sowie für das Fernpublizieren mit z.B. dem WordPress iPhone App. Wer die Datei nicht braucht sollte die Funktion deaktivieren und die Datei löschen. Für meinen Blog, jedoch wird Sie benötigt auch wenn die Datei ein Sicherheitsrisiko darstellt.

Außerdem habe ich das Verzeichnis WP-Admin mit .htaccess geschützt. Ich kann allen nur ans Herz legen das Plugin „Limit Login Attempts“ zu nutzen. Eine weitere Liste wichtiger Plugins findet ihr hier.

Wenn man einmal einen solchen Angriff als Opfer gegenüberstand so wir einem schnell bewusst, dass dort organisierte Kriminalität am Werke ist und der Kampf zwischen den Hackern und den Entwicklern sich immer weiter ausweitet.