November 28

MRTG & die Routingtabelle

Nachdem ich ein Peering mit ein paar Kollegen per
BGP eingerichtet habe, wollte ich abseits der NRPE Checks
ganz gerne noch die Anzahl der Einträge in der Routingtabelle
überwachen, sodass man auch ohne stundenlanges Logs
durchstöbern mal sehen kann, ob zwischendurch was geflogen ist.

Dafür hat sich MRTG ganz gut angeboten, da es sich ja letzten Endes
nur um die Darstellung einer Zahl im Graphen über einen gewissen
Zeitraum handeln sollte.

Lesen Sie weiter

November 28

Apt Hash Sum mismatch

Mir lief kürzlich folgende Meldung über den Weg,
wenn ich apt-get update laufen lassen wollte:

W: GPG error: http://de.archive.ubuntu.com utopic-backports Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>
W: Failed to fetch http://de.archive.ubuntu.com/ubuntu/dists/utopic-updates/main/binary-amd64/Packages  Hash Sum mismatch
W: Failed to fetch http://de.archive.ubuntu.com/ubuntu/dists/utopic-updates/main/binary-i386/Packages  Hash Sum mismatch
W: Failed to fetch http://de.archive.ubuntu.com/ubuntu/dists/utopic-updates/main/i18n/Translation-en  Hash Sum mismatch
W: Failed to fetch http://de.archive.ubuntu.com/ubuntu/dists/utopic-backports/universe/source/Sources  Hash Sum mismatch
W: Failed to fetch http://de.archive.ubuntu.com/ubuntu/dists/utopic-backports/universe/binary-amd64/Packages  Hash Sum mismatch
W: Failed to fetch http://de.archive.ubuntu.com/ubuntu/dists/utopic-backports/universe/binary-i386/Packages  Hash Sum mismatch
W: Failed to fetch http://de.archive.ubuntu.com/ubuntu/dists/utopic-backports/universe/i18n/Translation-en  Hash Sum mismatch
E: Some index files failed to download. They have been ignored, or old ones used instead.
Lesen Sie weiter

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.