Snitch: Die “Firewall” für deinen Blog …

Heute gibt's mal einen Beitrag abseits der üblichen Windows-, Android-oder Mobilgeräte-Themen: Mein Blog läuft ja mit WordPress auf einem Host Europe-Server. Kürzlich hatte ich beim Test des neuen Plugins Snitch von Sergej Müller den merkwürdigen Effekt – dass offenbar aus meinem Blog ominöse Webseiten – angefangen von Verweisen auf Louis Vuitton-Taschen über Brink Jewellery-Seiten bis hin zu Pen***enhancern – "verlinkt" wurden. Bekam einen riesen Schreck, weil sofort die Frage "bin ich gehackt" auftauchte. Artete in ein Abenteuer aus, welches mich einige Stunden beschäftigt hat. Leider war da auch nix im Internet zu dokumentiert – so dass ich beschlossen habe, meine "Findings" hier zusammen zu klopfen – möglicherweise erspare ich anderen Bloggern viel Arbeit und Nerven.


Anzeige

Als Blogger kämpft man nicht nur mit der Technik, sondern mit Kommentar-Spam und ähnlichem Unrat. So weit so gut, habe ich mit Plugins ganz gut im Griff. Aber nicht nur auf einem PC können sich Malware, Trojaner oder Viren einnisten – auch ein Blog könnte befallen sein. Ganz konkret stellt sich die Frage: Wie kann ich als Blogger feststellen, welche URLs aus der Blogsoftware wohl aufgerufen werden? Gut, man könnte mal in die Log-Dateien des Servers schauen – aber welcher Blogger macht das täglich?

Vor 2 Wochen gab Sergej Müller sein neues Plugin Snitch frei, welches ausgehende URL-Verbindungen protokolliert und so dem Administrator eine Übersicht verschafft, welche URLs aus dem Blog aufgerufen werden. Sergej schreibt dazu:

Nach der Installation von WordPress und Drittanwendungen fehlt Blog-Administratoren die Möglichkeit einzusehen, ob und wohin Themes und Plugins im Hintergrund kommunizieren. Aus Datenschutz- (Stichwort Tracking) und Sicherheitsgründen (Stichwort Malware) würde ein Logbuch über ausgehende Blog-Verbindungen Sinn machen. Snitch als Datenwächter für WordPress eilt zu Hilfe.

Klasse! Ich habe den Launch mitbekommen, weil Sergej in meinen Google+-Kreisen ist und auch andere Blogger wie Caschy von Stadt-Bremerhaven.de es bei Google+ erwähnten. Also geben wir uns mal einen Test – Plugin ist in wenigen Sekunden installiert und laut Sergej sollten pro Tag nur einige wenige Einträge aufgezeichnet werden.

Boah, alles so schön rot hier …

Als ich nach einer Stunde im WordPress Dashboard den Snitch-Eintrag anwählte, waren schon über 100 Einträge vorhanden. Sergejs Plugin hatte wohl gut funktioniert und so einiges aufgezeichnet.

Da fiel mir sofort das Herz in die Hose – wie konnte das sein? Bin ich gehackt? Was steckt dahinter? Wie komme ich aus der Nummer wieder raus? Doof war, dass ich gerade in einem zeitkritischen Buchprojekt steckte. Also habe ich das betreffende Modul und die Domains der ausgehenden URLs in Snitch blocken lassen – das sind die Teile in obigem Screenshot, die rot hervorgehoben werden.

Verbesserungsbedarf für's Plugin

Als nächste Maßnahme habe ich Sergej angemailt und den Sachverhalt beschrieben – er konnte damit aber überhaupt nichts anfangen. Zudem hatte ich das rein technische Problem, in der ersten Version des Plugins bis zu 1.000 Einträge in 24 Stunden löschen zu müssen.

Artete in eine Klickorgie aus – so dass ich Sergej einige Verbesserungsvorschläge bezüglich der Plugin-Bedienung gemacht habe. Spitze: Am Abend habe ich konkrete Vorschläge gemacht – am nächsten Morgen hatte Sergej reagiert und die verbesserte Plugin-Version bereitgestellt. Jetzt konnte ich die Datenbank mit einem Klick löschen.


Anzeige

Bin ich gehackt?

Aber die drängendere Frage war: Bin ich gehackt, oder was tobt da in meinem Blog? Ich hatte also nicht wirklich viel Zeit, um alles auf Herz und Nieren zu prüfen. Da meine Templates durch ein Antiviren-Plugin überprüft werden, habe ich das auf die Schnelle nochmals durchlaufen lassen – nichts gefunden, die Templates waren sauber. Also noch eine externe Prüfung nachgeschoben. Dieser Artikel listet z.B. Dienste wie Sucuri, SURBL, Unmask Parasites etc., wobei mit sururi zu penetrant eine Registrierung anbietet, um Details zu erfahren.

Jedenfalls ergab die Prüfung, dass der Blog keine bekannte Malware enthielt. Eine schnelle Suche im Blog ergab, dass dort keine der verdächtigen URLs abgelegt war. Nur bei Recherchen im Web konnte ich feststellen, dass genau die URLs bei anderen Webseiten und Blogs auftauchten. Also habe ich die folgenden Schritte über mehrere Stunden und dann Tage verteilt.

Wie fange ich den Problembär?

Als nächstes habe ich, nachdem ich mal einen Stunde Zeit hatte, weitere Antivirus-Plugins installiert und über den Blog laufen lassen. Alles wurde sauber gemeldet.

Konnte ein Plugin da rumtoben? Oder habe ich mir die Laus über den Code zum Einblenden der Google- und Amazon-Anzeigen in den Pelz gesetzt? Um ein mistiges Plugin – oder über Werbeanzeigen eingeschleppte Problembären – auszuschließen, habe ich alle Plugins deaktiviert – nur um binnen 10 Minuten jede Menge Kommentarspam zu erhalten. Aber Snitch zeichnete weiter ausgehende URLs auf. Einige Links waren erklärbar, weil ich Bilder oder andere Blog-Beiträge von extern verlinke.

Also alle Plugins wieder aktiviert und mal den Code des Template angeschaut. Da konnte ich nichts feststellen. Anschließend im FTP-Client die WordPress-Module – insbesondere XMLRPC überflogen – sah auch gut aus.

Dann habe ich WordPress zwei mal komplett neu installieren lassen (ist ja in einer Minute erledigt). Kurze Ruhe – und dann liefen wieder die blockierten URLs in Snitch ein. Scheibenkleister.

SQL-Injection oder was?

Dachte dann an SQL-Injection und habe den Export meiner Datenbank in einem Editor auf die URL-Einträge untersucht, ohne fündig zu werden. Da ich einige JScript-Codesnippets in älteren Beiträgen integriert hatte, habe ich diese im WordPress-Frontend rausgeworfen. War aber nur Google Adsense und Amazon Affiliate-Anzeigencode dabei. Hatte den Vorteil, dass ich den Blog um diese Komponenten ausmisten konnte.

Hat aber alles nichts geholfen. Aber verdammt – wer telefoniert im Blog über wp-includes-class-wp-xmlrpc-server-php in Zeile 5383 nach Hause? Schaute ich mit die Cross-Referenz-Auszüge diverser WordPress-Webseiten an, gab es dort keine solche Zeile. Nach einigen Vergleichen habe ich festgestellt, dass die Cross-Referenzen veraltet waren. Auch der am Artikelende verlinkte Beitrag konnte mir nicht weiterhelfen, da solche Codemuster bei mir nicht zu finden waren.

Was sagen die Profis?

Dann habe ich bei meinem Sponsor, HostEurope, und in diesem und diesem WordPress-Forum nachgefragt. Wenn es einer wissen kann, dann doch an der fachlichen Quelle. Gab binnen 24 Stunden keine Reaktion in den Foren – nur Host Europe meldete sich mit folgender Mail:

Sie sind aber anscheinend nicht der Einzige dem dieses bisher aufgefallen ist:

http://wordpress.org/support/topic/mysterious-outgoing-links-from-wp-includesclass-wp-xmlrpc-serverphp5383
http://forum.wpde.org/allgemeines/111926-merkwuerdige-ziel-urls-ueber-wp-includes-class-wp-xmlrpc-server-php-5383-a.html

Wir können das serverseitig somit keinen Grund feststellen. Vielleicht können Sie diese beiden Forum Threads verfolgen bzw. sich dort aktiv dran beteiligen.

LOL – waren meine eigenen Foreneinträge – aber beruhigend, dass der Support meines Hosters da nix böses feststellen konnte (obwohl ich vom Bauchgefühl sehr sicher war, dass mein Blog sauber sei).

Nachdem ich ziemlich viel durchforstet und mein Projekt abgeschlossen hatte, begann ich etwas zu denken. Den Sinn und Zweck der XMLRPC-Aufrufe mit den ominösen URLs hatte ich (noch) nicht verstanden – aber das Ganze roch nach Spam-Adressen für Kommentare oder Trackbacks.



Kerl: Schau in die Log-Files

Und dann kam ich auf die Idee, mir die Log-Files des Servers anzusehen (ist halt aufwändig, weil ich in das Front-End des Hosters rein muss) und nach einigen der blockierten Einträge zu suchen. Bingo! Hätte ich viel früher machen sollen. Ich hatte in Snitch viele Links zu Werbeseiten wie:

blockieren lassen. Im Log kamen der Eintrag und weitere URLs bei einer Suche sehr häufig vor.

184.154.121.198 – – [21/Feb/2013:08:22:22 +0100] "GET /blog/2012/11/09/november-updates-fr-windows-78/ HTTP/1.0" 200 33864 "http://www.driverdetectiveregistrationkey.com" "PHP/5.2.10" "www.borncity.com"
184.154.121.198 – – [21/Feb/2013:08:22:23 +0100] "POST /blog/2012/11/09/november-updates-fr-windows-78/trackback/ HTTP/1.0" 200 312 "http://www.driverdetectiveregistrationkey.com" "PHP/5.2.10" www.borncity.com

Problembär gefangen: Die XMLRPC-Aufruf erfolgen von außen, da über diese Schnittstelle die Veröffentlichung im Blog oder Trackbacks und Pings eingepflegt werden. Die von Snitch aufgezeichneten URLs waren also Versuche von Spammern, Spam-Trackbacks oder Kommentar-Spam im Blog einzupflegen.

So könnte man die Zugriffe blocken

Habe dann Sergej Müller die Info zukommen lassen und von ihm prompt noch diesen Tipp bekommen:

Das würde ich auch so interpretieren. Als Reaktion würde ich dann beigehen und die IP 184.154.121.198 in der htaccess sperren: http://blamcast.net/articles/block-bots-hotlinking-ban-ip-htaccess

Genau dafür ist Snitch auch da, um genau solche Probleme zu erkennen. Denn ohne, würdest du auch die nächsten 10 Jahre nichts davon mitkriegen ;)

Der Support von HostEurope gab dann noch den hilfreichen Tipp:

Für das Blockieren von IP-Adressen können wir Ihnen folgende Dokumentation empfehlen. Es ist relativ einfach umzusetzen, jedoch sollten Sie darauf achten, keine Hostnamen zu verwenden. Denn dies kann u.U. zu einer merkbaren Verschlechterung der Webserver Performance führen, da der Webserver dann für sämtliche Aktionen eine Auflösung der IP-Adresse macht um zu schauen, ob der Hostname dahinter wie in Ihrem Fall blockiert werden soll. Falls Sie für diese merkwürdigen Zugriffe eine Erklärung gefunden haben können Sie es im Forum anderen mitteilen. Ich habe mir die beiden Forumseinträge mal gespeichert.

Ja, und den letzten Absatz habe ich nun beherzigt und diesen Blog-Beitrag verfasst. Den werde ich dann auch im deutschsprachigen WordPress-Forum verlinken. Vielleicht erspart es einem zweiten Betroffenen die mühselige Suche, die ich absolvieren musste, um schlussendlich eine Erklärung zu erhalten.

Links:
1: Common WordPress Malware Infections


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Allgemein, Internet abgelegt und mit , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

5 Antworten zu Snitch: Die “Firewall” für deinen Blog …

  1. Günter Born sagt:

    Nachtrag: Das Blocken in der .htaccess werde ich wohl demnächst angehen. Wird aber auf ein "Katz- und Mausspiel" hinauslaufen, da die Spammer wohl wechselnde IP-Adressen verwenden und möglicherweise auch Blogs gehackt haben.

    Es gibt zwar Plugins, die so was an Hand der IP-Adresse mit einer externen Datenbank abgleichen können. Da IP-Adressen in der EU als "persönliche Daten" gelten, kann ich diese aus rechtlichen Gründen nicht einsetzen (Sergej Müller hat das im Umfeld seines AntiSpamBee-Plugins mal thematisiert). Datenschutz ist wichtig – aber hier ist wieder ein Beispiel, wo solche Vorschriften ad-adsurdum geführt werden und Spammern Vorschub leisten.

  2. Heiko Mamerow sagt:

    Hallo Günter,
    Danke für den Artikel! Wieder was dazu gelernt.

    Auf meinen (Kunden-)Websites "langweilt" sich Snitch zwar. Aber gut zu wissen, wie man herangehen kann, wenn dem mal nicht so ist. :-)

    • Günter Born sagt:

      @Heiko: Danke für die Rückmeldung. Deine Aussage deckt sich mit dem, was Sergej so meinte. Schätze, wenn die Kunden-Websites mal etwas populärer werden, kommen die Einträge auch …

  3. Stefan Jean Hildebrandt sagt:

    Danke für den ausführlichen und interessanten Beitrag.

    Auch wenn ich Phasenweise leider massiv mit Kommentarspam zu kämpfen habe, scheint mein Blog wenigstens lt. Snitch Analyse sauber zu sein :) ("noch zu klein" für mehr).

    Aber Anleitung ist schon mal vorgemerkt, falls ich dann doch irgendwann mal blockieren müsste.

  4. Dominik Horn sagt:

    Genau das Problem habe ich auch gehabt. Habe darüber geblockt: http://www.media-affin.de/snitch-crontrol-trackbackspam-oder-wie-ich-meinen-blog-unter-kontrolle-behalte

    Ich glaube auch gar nicht, dass wir die zwei einzigen mit diesem Problem sind, ich glaube eher, dass Snitch nicht so weit verbreitet ist.

    PS: Werde nachher noch einen Link auf den Artikel setzen, du beschreibst das ganze echt gut, danke!

Schreibe einen Kommentar zu Heiko Mamerow Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.