In den letzten Tagen kamen mir immer wieder Server mit einer
abnormalen Menge an Aufrufen der xmlrpc.php unter (betroffen waren meist
etliche Webspaces gleichzeitig). Ich habe im ersten Moment an Bruteforce
oder ähnlichen alltägliche Müll gedacht – denkste!
Für die üblichen „Kleinkram“ waren viel zu viele Source-IPs beteiligt,
also habe ich mal ein bisschen recherchiert.

Der Aufruf hat sich in den Apache-Logs in etwa so gezeigt:

[31/Oct/2014:11:06:19 +0100] "POST /xmlrpc.php HTTP/1.1" 200 402 "-" "-"

In diesem Fall wurde interessanterweise nie ein User-Agent mitgeliefert, das kann
aber von Angriffswelle zu Angriffswelle unterschiedlich sein.

Es handelt sich hierbei um einen DDoS der Pingback Funktion von WordPress.
Das problematische dabei: es handelt sich hierbei nicht nur um eine Funktion, die
auf der lokalen Maschine eine Menge Last verursacht, sondern es ist eine reflective Attack.

Heisst also: im schlimmsten Fall schadet man durch das Aussitzen des Angriffs nicht nur
der Performance des Webservers, sondern zieht dadurch eventuell auch Server eines Dritten mit runter.

Da der Aufruf der xmlrpc.php eine nicht unwesentliche Load (vorallem auf shared Systemen mit
vielen Webspaces) verursacht, musste also ohnehin eine Lösung her.

Dazu gibt es verschiedene Ansätze:

1. Man löscht die xmlrpc.php (oder benennt sie temporär um). Das ist die einfachste
   Methode, aber sicherlich nicht die schönste…
2. Den Angreifer mit einem deny abspeisen. Dafür kann man einen recht simplen
   Eintrag in die .htacces packen:
   <Files xmlrpc.php>
Order allow,deny
Deny from all
</Files>
3. Alternativ kann man den Angreifer mit einem Redirect in’s Nirvana schicken
   (oder wohin auch immer, zum Beispiel auch auf seine eigene Kiste,
   in diesem Fall einfach auf die 0.0.0.0):
   RewriteRule ^xmlrpc\.php$ "http\:\/\/0\.0\.0\.0\/" [R=301,L]
   Ein Schelm würde vielleicht auch so weit gehen und
   statt der 0.0.0.0 mit einem Eintrag im Stile von http://%{REMOTE_ADDR}/ [R,L]
   den Bösewicht direkt wieder auf seine eigene Adresse verweisen 🙂

Option 3 sagt mir persönlich am meisten zu. Vorallem deshalb, weil sie am wenigsten Traffic
verursacht und weil Botnets auch auf eine 404 Seite (die bei Option 1 und 2 generiert wird)
verzichten kann – auch eine Error 404 macht ab einer gewissen Dimension des Angriffs
Last auf dem Server.

Ob hier eine Fail2ban-Regel in Zukunft mal interessant werden könnte, muss man noch sehen.
Aufgrund der etlichen Source-IPs (die vermutlich zu einem großen Anteil gespoofed sind)
sieht es momentan noch nicht danach aus, dass das mal Sinn machen wird.