WordPress XMLRPC for Brute-Force-Angriffe schützen

Blogger und System Administratoren ist es bekannt, Brute-Force-Angriffe auf den Admin-Bereich sind sich die meisten schon gewohnt und behelfen sich mit Security-Plugins oder durch Restriktionen in der .htaccess Datei. Dabei sollte man die XMLRPC-Schnittstelle nicht ausser acht lassen, die zwei Hauptfunktionen ermöglicht: Pingback-API ermöglicht eine Vernetzung zwischen den Blogs und dient gleichzeitig als Schnittstelle, um WordPress über externe Programme verwalten zu können.

Aufgrund ihres Funktionsumfangs ist xmlrpc.php nicht nur beliebt bei den Blogger, sondern stellt auch für Angreifer ein attraktives Ziel dar, Angreifer fokussieren ihre Attacken daher zunehmend auf xmlrpc.php. Dabei kann ein DDOS-Angriff durch eine Vielzahl an Anfragen pro Sekunde den Server zur Überlastung bringen, oder durch hohe Datentraffic die dabei entsteht, das Netzwerk zum erliegen bringen.

xmlrpc.php mit Apache 2.4+ schützen

Die vollständige Deaktivierung der WordPress XMLRPC-Schnittstelle bei einem Apache 2.4+ Webserver unter /etc/httpd/conf/httpd.conf:

# Apache 2.4+
<Files xmlrpc.php>
    <RequireAll>
        Require all denied
    </RequireAll>
</Files>

xmlrpc.php mit Apache 2.2 schützen

Wer die Deaktivierung bei einem Apache 2.2 Webserver vornehmen will, kann dies in der /etc/httpd/conf/httpd.conf (Red Hat), bei debian /etc/apache2/apache2.conf vornehmen:

# Apache 2.2
<Files "xmlrpc.php">
    Order Deny,Allow
    Deny from all
</Files>

Danach den Webserver neu starten mit service httpd restart, oder systemctl restart httpd.service.

Die Apache Direktive kann auch in die .htaccess-Datei in der Docroot eingefügt werden.

Die Überprüfung geschieht in dem die Blog-URL mit anstehender xmlrpc.php aufgerufen wird, Beispiel:

https://<dein_blog>/xmlrpc.php

Es wird nun 403 Forbidden ausgegeben.

XMLRPC schützen mit fail2ban

Wer die XMLRPC-Schnittstelle nutzen möchte, ohne auf eine Schutzmassnahme verzichten zu müssen, für den eignet sich fail2ban, das Tool untersucht und filtert Attacken aus dem Apache Protokoll und blockiert die IP-Adresse des angreifenden Host für einige Zeit, die dauer der Blockierung kann bestimmt werden, fail2ban steuert die Kernel-Firewall, in dem iptables angewiesen wird die Angreifer IP zu blockieren (DROP) und verhindert so das keine schädliche Traffic und Systemauslastung entsteht. fail2ban verhindert nicht nur das der Angreifer kein Zugriff auf die xmlrpc.php hat, vielmehr wird der Host ganz blockiert und der POST durch DROP ins leere läuft, dadurch werden auch andere mögliche Attacken verhindert, was bei den zuvor geschilderten Schutzmassnahmen nicht zutrifft.

Die Installation von fail2ban auf CentOS 5.x (Red Hat) läuft wie folgt. Die Installation für CentOS 7 hier.

wget https://dl.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm
rpm -ivh epel-release-5-4.noarch.rpm
yum repolist
yum install fail2ban
chkconfig --add fail2ban
chkconfig fail2ban on
service fail2ban start

Nun die fail2ban Konfiguration für das logging vornehmen mit vi /etc/fail2ban/fail2ban.conf

[Definition]
loglevel = 3
logtarget = /var/log/fail2ban.log

Die Filter Definition geschieht mit dem erstellen einer neuen Datei unter /etc/fail2ban//filter.d/apache-xmlrpc.conf und fügt dabei folgende Zeilen ein:

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

In der Konfigurationsdatei jail.conf den Filter unten am Dateiende einfügen, vi /etc/fail2ban/jail.conf

[apache-xmlrpc]

enabled = true
port = http,https
filter = apache-xmlrpc
action = iptables[name=xmlrpc, port=http, protocol=tcp]
logpath = /home/www/*/web/logs/access_log
maxretry = 6

Nun die Änderungen aktivieren mit service fail2ban restart

Überprüfen wie fail2ban arbeitet, lässt sich anhand der Logdatei ermitteln mit tail -f /var/log/fail2ban.log, falls bereits DDOS-Angriffe stattgefunden haben, wird die Eingabe iptables -vnL | grep fail2ban die Source-IP der geblockten Hosts ausgeben.

Brute-Force Attacken blockieren mit Fail2ban

Fail2ban scannt Log-Dateien (zB. /var/log/apache/error_log) und verbietet IPs, die verwundbare anfragen enthalten und verhindert die suche nach Exploits, um die Systeme zu infizieren und zu kompromittieren versuchen. Im Allgemeinen wird das „Fehlschlag zu Bann“ Framework verwendet, um Firewall-Regeln zu aktualisieren, als Intrusion Prevention System (Framework zur Vorbeugung gegen Einbrüche). Um die Herkunft der IP-Adressen für eine bestimmte Zeit abzulehnen, wobei andere Dienste ihre Funktion wie zB. der Mail Transport Agent weiterhin Emails verarbeiten werden.

Fail2Ban ist freie Software unter GNU General Public License Version 2 und kommt Out-of-the-Box, der Filter ist für verschiedene Dienste wie Apache, Bind, Postfix, SSH etc. einsetzbar. Fail2ban ist in der Lage, die Rate der falsch-Authentifizierungen, die Brute-Force Attacken zu reduzieren, versucht aber nicht das Risiko schwacher Authentifizierung zu beseitigen.

Installation

Als erstes wird das Packet aus dem Fedora repo installiert und gleich gestartet, hier auf einem Fedora Linux.

$ wget https://dl.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm
$ rpm -ivh epel-release-5-4.noarch.rpm
$ yum repolist
$ yum install fail2ban
$ systemctl start fail2ban

Falls nicht schon vorhanden die Log-Datei erstellen:

$ mkdir /var/named/chroot/var/log/named
$ touch /var/named/chroot/var/log/named/security.log
$ chown named /var/named/chroot/var/log/named

Fail2ban Konfiguration

Nun editieren wir die Konfiguration:

$ vi /etc/fail2ban/jail.conf

Hier in diesem Beispiel der Bind Daemon:

bantime = 1440

enabled = true logpath = /var/named/chroot/var/log/named/security.log

$ vi /etc/named.conf

Den folgenden Inhalt einfügen.

logging {
 channel security_file { 
 file "/var/log/named/security.log" versions 3 size 30m;
  severity dynamic;
  print-time yes;
  };
  category security {
   security_file;
 };
};

Bind named erneut starten.

$ systemctl restart named

Im security-Log von named werden abgelehnte anfragen protokolliert.

$ tail -f /var/named/chroot/var/log/named/security.log
23-Jan-2010 07:19:56.534 client 10.1.162.1#28320: query (cache) './NS/IN' denied

Die letzten fail2ban Einträge anzeigen.

$ tail /var/log/messages
Sep  6 14:21:35 ns2 fail2ban.actions: WARNING [named-refused-tcp] Ban 10.1.162

Die durch fail2ban eingefügten iptables ketten ausgeben.

$ iptables -L -n |grep fail2ban

UNBLOG Tutorials

Schlagwort-Archive: fail2ban Intrusion Prevention System

Denial of Service Angriff auf xmlrpc.php