WordPress: Angriff auf xmlrpc.php abwehren

Über die Feiertage ist einer meiner Server, auf dem auch dieser Blog hier gehostet ist, für kurze Zeit durch einen Angriff auf eine bekannte Schwachstelle in dem beliebten und auch von mir häufig verwendeten WordPress lahmgelegt worden. Im Folgenden möchte ich erklären wie der gerade ausgeführte Angriff abgewehrt und zukünftige Versuche durch Vorkehrungen in der Serverkonfiguration unterbunden werden können.

Voraussetzungen für diese Anleitung

• Ihr benutzt WordPress als Installation auf einer eigenen Serverinfrastruktur, dedicated oder virtual private server (VPS)
• Root-Rechte und SSH-Zugang zum Server sind vorhanden
• Zum Unterbinden eines akuten Angriffs wird iptables verwendet
• Zur Abwehr zukünftiger Versuche verwenden wir fail2ban

Beschreibung des Angriffszenarios

WordPress ist nicht zu Unrecht eines der am weitesten verbreiteten Content Management und Blogsysteme weltweit. Die viel gerühmte Erstinstallation binnen 5 Minuten und Erweiterbarkeit durch Plugins macht es zu einem günstigen und vielseitigen Werkzeug für Webprojekte aller Art.

Das enthaltene Skript xmlrpc.php ermöglicht zum einem Pingbacks und Artikelerstellung per E-mail, zum anderen dient es auch als Schnittstelle für zahlreiche Plugins. So wird etwa durch SEO-Experten vor allen Dingen für gewerblich genutzte Seiten oft empfohlen Plugins wie „Jetpack“ zu installieren. Jetpack ist bis dato eines der am meisten genutzten Plugins, doch die Bequemlichkeit hat leider nicht zu unterschätzende Schattenseiten:
derart universell eingesetzt ist das Skript xmlrpc.php leider eine lange bekannte Schwachstelle in WordPress, weit geöffnet für eine Vielzahl von Angriffen.

Angriffe erkennen und unterbinden

Sofern euer Server nicht laufend auf Performanzeinbußen geprüft wird bemerkt ihr es leider erst, wenn einer eurer Dienste sehr verlangsamt ist oder vollständig den Dienst aufgibt. Bei einem Angriff werden pro Sekunde etwa 20 Anfragen an die Schnittstelle gesendet. Diese antwortet pflichtgemäß mit einer Ablehnung der Anfrage (denial of service) startet für jeden Vorgang aber eine Datenbankabfrage, welche mehrere Sekunden andauern kann und euren Datenbankserver daher so sehr überlastet, daß keine anderen Anfragen, wie legitime Webseitenaufrufe, mehr durchgeführt werden können.

Ein Anzeichen für einen Angriff ist also, wenn eure SQL-gespeisten Webseiten (ergo CMS wie WordPress) kein Lebenszeichen mehr von sich geben während euer Server auf andere Anfragen auf Dienste wie ping, SSH völlig normal antwortet.

Deswegen melden wir uns per SSH am Server an und werfen dann einen Blick in das Zugriffslog des Webservers.

sudo less /var/log/nginx/access.log

Als Administrator solltet ihr den Ort für eure access.log kennen. In diesem Beispiel wird als Webserver nginx verwendet. Bei anderen Server kann der Pfad abweichen.

Wird euer Server gerade akut beschossen, so muß im Log nicht lange gesucht werden. Springt ganz ans Ende des Logs, dort werden die gerade stattfindenden Zugriffe auf die xmlrpc.php festgehalten. Die Anfragen können von einer oder auch von mehreren IP-Adressen ausgehen. Notiert euch diese IP-Adressen.

Angreifer blockieren

Um unsere Webseiten schnell wieder online zu bekommen verschaffen wir unserer Datenbank Luft zum Atmen und verhindern erst einmal Zugriffe der oben notierten Adressen.

sudo iptables -A INPUT -s 123.456.78.90 -j DROP

Die IP-Adresse ist nur ein Beispiel und muß natürlich ersetzt werden durch eure notierten Adressen.

Vorsichtshalber führen wir einen Neustart des Webservers (nginx) durch.

sudo service nginx restart

Danach sollten eure Webseiten wieder online sein. Falls nicht alle Angreifer getroffen wurden denselben Schritt wiederholen und im Log nach weiteren IP-Adressen Ausschau halten.

Angriffe automatisch blockieren mit fail2ban

In Zukunft wollen wir natürlich nicht erst durch einen Ausfall unserer Dienste auf einen Angriff aufmerksam gemacht werden. Deswegen definieren wir eine neue Filterregel, damit fail2ban bei mißglückten Zugriffsversuchen auf xmlrpc.php erkennen kann und per Firewall unterbindet.

Es gibt alternative Methoden mit diesem Angriff umzugehen aber auch mehrere Gründe, warum ich persönlich auf fail2ban setze. Eine Abwehr auf Betriebssystemebene ist meiner Meinung nach immer zu bevorzugen, da wir uns zum einen mit dessen Funktion auseinandersetzen müssen und sukzessive Einblicke in dessen Funktion erhalten und dazulernen können. Dieses Wissen ist für die Administration unerlässlich da etwaige Sicherheitsplugins für WordPress oft nur sehr begrenzte Angriffsvektoren  abdecken und man auf Gedeih und Verderb dem Wohlwollen und Updateverhalten der Entwickler ausgesetzt ist.
Der andere Grund sind Performanzvorteile beim Einsatz von fail2ban. Dieses schlanke Tool wertet Logdateien aus, die durch das System ohnehin angelegt werden und operiert schneller und effizienter als jedes aufgesetzte Plugin es je könnte.

Fail2ban kann natürlich Loginversuche auf euer WordPress-Backend überwachen und ist hervorragend dazu geeignet Brute-Force Angriffe zu unterbinden. Die erstmalige Einrichtung ist nicht Thema dieses Artikels, diese wird zum Beispiel hier aufschlußreich beschrieben.

Dennoch: für die folgenden Schritte muß fail2ban auf dem Server installiert sein, was ihr ganz einfach nachholen könnt.

sudo apt-get update
sudo apt-get install fail2ban

Filterregel für fail2ban einfügen

Wir erstellen auf unserem Server eine neue Datei als Filterregel zur Benutzung durch fail2ban.

sudo nano /etc/fail2ban/filter.d/nginx-xmlrpc.conf

Inhalt der Datei ist wie folgt:

[Definition]
failregex = ^<HOST> .*POST .*xmlrpc\.php.*
ignoreregex =

Danach öffnen wir die Konfiguration für die verwendeten Jails

sudo nano /etc/fail2ban/jail.local

und fügen folgende Zeilen hinzu:

[nginx-xmlrpc]

enabled  = true
port     = http,https
filter   = nginx-xmlrpc
logpath  = /var/log/nginx/access.log
maxretry = 5
bantime = 43200

Die oben genannten Einstellungen könnt ihr natürlich euren eigenen Anforderungen entsprechend abändern. Der Wert „filter“ entspricht der Datei die wir eben als Filter erstellt haben. Der „logpath“ muß natürlich auf eine existierende Datei verweisen, wo euer Webserver sein access.log ablegt. „Maxretry“ bezeichnet die Schwelle fehlgeschlagener Verbindungsversuche, bei der fail2ban anschlägt und weitere Versuche blockiert. Ein üblicher Wert ist 3. Hier sollte er meiner Meinung nach etwas höher eingestellt werden, da auch legitime Pingbacks dieselbe Verbindung verwenden und gehäuft auftauchen können. Bei einer Schwelle geringer als 20 sollte es fail2ban möglich sein innerhalb weniger Sekunden Angriffe erkennen und verhindern zu können. Schlussendlich ist die „bantime“ in Sekunden angegeben, wobei 43200 Sekunden 12 Stunden entsprechen. Bei höheren Zeiten wird euer Server wirksam vor mißbräuchlichen Zugriffen geschützt. Die Zeit sollte allerdings nicht so hoch sein, daß ein einfaches Versehen zu einer permanenten Sperre führen kann.

Zum Abschluß starten wir fail2ban, damit unsere Neukonfiguration aktiv wird.

sudo service fail2ban restart

Einsatz überprüfen und Mißbräuche melden

Den Einsatz unserer Regel können wir in der Logdatei überprüfen mit

sudo less /var/log/fail2ban.log

Der größte Vorteil dieser Lösung sind die vielseitigen Verwendungsmöglichkeiten. So kann fail2ban beispielsweise dazu gebracht werden, angreifende IP-Adressen automatisch an den jeweiligen Internetzugangsanbieter zu übermitteln. Solange die Angriffe nicht überhand nehmen kann dies auch ausnahmsweise manuell durchführen indem man eine whois-Abfrage nach der IP durchführt und eine E-mail an die Beschwerdestelle des Internetzugangsanbieters schreibt.
Das Wichtigste jedoch: damit reagiert euer Server automatisch nach einer Schwelle fehlgeschlagener Versuche und fügt angreifende IP-Adressen der Firewall hinzu.