In der zweiten Juli-Woche 2014 wurde mein Server Ziel von Angriffen, der sich primär auf die XML-RPC-Schnittstelle der auf dem Server eingerichteten WordPress Blogs konzentrierten. Zudem traten ebenfalls gehäuft Zugriffsversuche auf die Anmeldeadressen meiner Websites auf. Im Visier standen beispielsweise die Subdomains zum Excel-Translator oder zum Excel-Wiki.
Die XML-RPC-Schnittstelle in WordPress dient dazu, um den Blog mit externen Programmen verwalten bzw. mit ihm von außen kommunizieren zu können. Microsoft Word verwendet beispielsweise diese Schnittstelle, wenn mit Word ein Blog-Artikel erstellt wird. Auch Anwendungen für das Smartphone, wie z.B. WordPress for Windows Phone, verwenden die Schnittstelle. Die Schnittstelle dient zudem auch dazu, dem Blog Benachrichtigungen in Form von Pingbacks senden zu können. Die XML-PRC-Schnittstelle ist seit der Version 3.5 von WordPress standardmäßig aktiv und lässt sich anhand der Oberfläche nicht abschalten.
Folgende Abbildung zeigt eine beispielhafte Auswertung der Zugriffe innerhalb eines Tages und für drei ausgewählte Subdomains vom Excel-Translator. In WordPress wird die XML-RPC-Schnittstelle anhand der Datei xmlrpc.php zur Verfügung gestellt. Die Datei ist im Wurzelverzeichnis jeder WordPress-Installation zu finden. Die Zugriffe fanden nicht konstant verteilt über den Tag statt, sondern bewegten sich innerhalb eines Zeitfensters von ein paar Stunden pro Tag, was den Server dann ziemlich beschäftigte.
Eine Auswertung meiner Log-Dateien zeigte, dass bei den Angriffen zum überwiegenden Teil die Kennung „Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)“ als Browserkennung übermittelt wurde. Eine Internet-Recherche zu der Kennung ergab einige Treffer und die von mir konsultierten Websites sind sich einig, dass der Absender der Kennung nichts Gutes im Schilde führt.
Angriffserkennung
Zunächst war mir der Angriff nicht aufgefallen, denn ich bin nicht konstant auf den Websites aktiv. Erst als ich über den Tag verteilt im Excel-Wiki neue Funktionen testete, bemerkte ich, dass die Website recht langsam reagierte und manchmal komplett aussetzte. Ein Testaufruf weiterer Websites auf dem Server ergab, dass sich die meisten so verhielten. Das Problem bezog sich somit nicht nur auf das Wiki. Eine Rückfrage bei meinem Provider ließ zunächst auf ein Problem mit einem WordPress Plug-In schließen. Das Plug-In, welches über mehrere Domains verteilt installiert ist und WordPress Ereignisse wie beispielsweise Login-Versuche protokolliert, lief Amok und kam mit seinen internen mySQL-Abfragen nicht mehr nach.
Das Plug-In lief aber bis dato einwandfrei. Zwar wurde es vor kurz vor dem Angriffszeitpunkt aktualisiert, dennoch sprach nichts für eine Fehlfunktion. Ich habe mich dann mit dem Entwickler des Plug-Ins in Verbindung gesetzt, um nachzufragen, worin die Ursache des Problems liegen könnte. Fazit war, dass die Zahl der Anfragen ungewöhnlich hoch sein müsste und da diese mitprotokolliert würden, ein entsprechender Ressourcenverbrauch zustande käme. Die Anzahl der Anfragen überprüfte ich anschließend anhand des vom Provider angebotenen Web-Statistik-Tools und danach in den Rohdaten der Logfiles. Ein Auswertetool, wie beispielsweise Piwik oder Google Analytics hilft hier nicht weiter, denn dieses filtert solche Anfragen schon vorher heraus, so dass man diese nicht sieht.
Nachdem ich nun relativ sicher war, dass es sich um einen Angriff handeln musste, ging ich erstmal auf Recherche nach Gegenmaßnahmen, zumal ich kein Sicherheitsexperte bin. So berichteten bereits einige Blogger über ähnliche Angriffe; bei manchen fanden diese bereits März 2014 statt. Die meisten Gegenmaßnahmen, die ich im folgenden Abschnitt beschreibe, entstammen der Blog-Artikel in Deutsch und Englisch, die ich am Ende des Artikels verlinkt habe.
Gegenmaßnahmen
Die folgende Gegenmaßnahmen beziehen sich auf einen Server, wo ein Zugriff per FTP auf die Dateien des Servers möglich ist. Gegebenenfalls lässt sich nicht jede Maßnahme umsetzen, da es ja auch Unterschiede zwischen den Providern und Paketen gibt.
Die erste Frage, die ich mir stellte war, brauche ich überhaupt die XML-RPC-Schnittstelle in WordPress? Die Antwort ist recht einfach: Nein, denn ich benutze weder externe Programme zum Erstellen von Beiträgen, noch verwalte ich meine Blogs über das Mobiltelefon. Und, Pingbacks sind beispielsweise für den Excel-Translator nicht notwendig.
Um nur Pingbacks in WordPress abzuschalten, kann in die Datei functions.php des aktiven WordPress-Themes folgender Code-Abschnitt am Ende der Datei hinzugefügt werden. Die Datei befindet sich im Verzeichnis „wp-content/themes/name_des_themes“ des aktiven Themes.
Falls das WordPress Theme mal geändert wird, muss die Anweisung allerdings in das neue Theme übernommen werden. Auch ein Update des Themes kann dazu führen, dass die functions.php vom Update überschrieben wird. Da ich mir aber eine lokale Textdatei angelegt habe und dort jegliche Änderungen und Ergänzungen innerhalb meiner Theme-Dateien dokumentiere, ist es ein Leichtes Buch zu führen.
Wenn die XML-RPC-Schnittstelle komplett abgeschaltet werden soll, kann der Zugriff auf die Datei xmlrpc.php über eine .htaccess-Anweisung vollständig gesperrt werden. Es erübrigt sich dann das Ändern der Theme-Datei. Wird die gesperrte Datei z.B. im Browser aufgerufen, erhält der Aufrufer die Fehlerantwort 403 vom Server. Für meine Blogs habe ich diese Variante gewählt, da dies auch Server-Ressourcen spart und „nur“ die Fehlermeldung erscheint. Bevor jedoch die XML-RPC-Schnittstelle vollständig abgeschaltet wird, sollte geprüft werden, ob nicht ein oder mehrere Plug-Ins den Zugriff auf die Datei benötigen. Beispielsweise ist dies für das WordPress Plug-In JetPack der Fall.
Die htaccess-Datei befindet sich im Wurzelverzeichnis des Blog und kann mit einem Texteditor wie Notepad++ editiert werden. Folgenden Block habe ich an den Anfang der .htaccess-Datei gesetzt.
Es gibt auch WordPress Plug-Ins, die die zuvor beschriebenen Aufgaben übernehmen können. Dies finde ich allerdings etwas überdimensioniert, denn das Editieren der Dateien ist in drei Minuten erledigt.
Unabhängig von den Gegenmaßnahmen zum Zugriff auf die XML-RPC-Schnittstelle habe ich auch die Gelegenheit genutzt, die Standard-Anmeldeadresse der Blogs zu verlegen. Heißt, die Standardadresse wird ins Leere umgeleitet und die Anmeldeadresse an einen anderen Ort verlegt. Und, der Anmeldedialog beinhaltet ein zusätzliches Feld, welches bei der Anmeldung abgefragt wird. Hierzu verwende ich das Plug-In Stealth Login Page.
Fazit
Die Zugriffsversuche sind seit den Gegenmaßnahmen bislang relativ wenig zurückgegangen, was aber meines Erachtens auch zu erwarten war. Die Blogs reagieren aber nun wieder deutlich schneller, verbrauchen weniger Ressourcen und vor allem sind keine Ausfälle mehr zu verzeichnen.
Folgend einige Links zu Websites, die mir bei der Suche nach Gegenmaßnahmen behilflich waren. Die beiden letzten Links beinhalten Tipps & Tricks im Umgang mit htaccess sowie zur Sicherheit von WordPress.
Dies hat mir sehr zu Sicherheitsthemen bzgl. WordPress geholfen.