Oktober 31

WordPress xmlrpc.php DDoS

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.

Oktober 2

Blinkende Alarmbox für OpenNMS *Update Version 15*

Die Outage-Box im OpenNMS, wenn man sie noch im Urzustand hat, lechzt nicht unbedingt nach Aufmerksamkeit.
Wenn man das Ganze immer auf einem 2. (3./4./x.) Monitor neben sich hat, kann man imho schnell mal ein paar Minuten einen Alarm übersehen.
Um die kleine Box etwas präsenter zu machen, gibt es mittlerweile einige Ansätze im Netz.
Die Möglichkeiten reichen von einem blinkendem Hintergrund bis zum Alarmsound.
Letzteres kann schnell nervig werden (zumal Ausfälle ohnehin schon genug die Nerven strapazieren können),
mein Favorit ist daher Option 1: die blinkende Alarmbox.

Lesen Sie weiter

September 27

Traffic überwachen mit NRPE&vnstat

Zur Überwachung meiner Server benutze ich u.a. OpenNMS und wollte gerne,
dass ich einen Alarm bekomme, sobald ein Interface auf einem Server
eine gewisse Anzahl pps oder MBit/s überschreitet.
Per Konsole kann man sich das auf Linux-Systemen ganz nett mit vnstat ausgeben lassen (apt-get install vnstat):
vnstat -i eth0 -tr
Um das dann auch per OpenNMS zu überwachen, habe ich mir ein kleines Check-Script geschrieben (siehe Anhang). Ausser vnstat benötigt es zur Umrechnung der
Einheiten noch bc (apt-get install bc).

Lesen Sie weiter