Seit WordPress 3.5 ist die XML-RPC Schnittstelle Standardmäßig aktiviert. Früher ließ sich selbige noch ganz einfach deaktivieren, heute ist dies nur noch über Umwege möglich. Doch nur wenige Nutzer brauchen sie wirklich, weshalb die aktivierte Schnittstelle am Ende nicht mehr als ein Risiko darstellt.
Bitte unterstützt meine Arbeit
Das deaktivieren von ungenutzten Funktionen bringt außerdem wieder Performance, doch hier dreht es sich eher um die allgemeine Sicherheit, die mit aktiviertem XML-RPC nicht unbedingt erhöht wird. Genutzt wird XML-RPC für das Remote Posting via Microsoft Word, für Pingbacks, für die iOS und Android Apps, eben für Dinge, die nicht unbedingt jeder Nutzer auch verwendet oder gar benötigt. Und wie ich immer predige, sollte all das, was nicht verwendet wird, auch so schnell wie nur möglich deaktiviert, abgeschaltet, komplett entfernt werden. So verhält es sich auch mit XML-RPC. Weg damit. Leider ist das nicht ganz so einfach wie gedacht, weshalb ich hier mal eine umfangreiche Anleitung zum deaktivieren von XML-RPC in WordPress geschrieben habe.
XML-RPC in WordPress deaktivieren
Allgemein gibt es ein einfaches Snippet, um XML-RPC in WordPress zu deaktivieren. Das klingt einfach, ist aber nur der erste Schritt, denn tatsächlich sind insgesamt drei verschiedene Snippets notwendig, um XML-RPC in WordPress auch wirklich komplett loszuwerden.
Folgendes in die Functions.php eure Themes kopieren:
add_filter( 'xmlrpc_enabled', '__return_false' );Mit dem oberen Snippet wird XML-RPC in WordPress nun deaktiviert, doch das Problem ist immer noch, dass selbiges im HTTP-Header erscheint. Das prüft ihr ganz einfach mit einem Tool wie RedBot, welches euch alle Einträge im HTTP-Header eurer Website präsentiert. Im Idealfall müsste euer Header dann so aussehen:
Habt ihr unnötige Einträge im HTTP-Header, solltet ihr mal überprüfen woher diese eigentlich stammen und ob ihr selbige nicht einfach entfernen könnt.
XML-RPC aus dem HTTP-Header entfernen
Wenn euer HTTP-Header nun, und das wird er vermutlich, einen Eintrag mit X-Pingback und xmlrpc.php enthält, dann habt ihr immer noch das Gleiche Problem. Für Hacker, Spammer, Angreifer ist das ein deutliches Zeichen, also weg mit dem Eintrag aus dem Header.
Folgendes in die Functions.php eures Themes eintragen:
add_filter( 'wp_headers', 'painkiller-tech_remove_x_pingback' );
function painkiller-tech_remove_x_pingback( $headers )
{
unset( $headers['X-Pingback'] );
return $headers;
}Mit diesem Snippet ist nun auch die direkte URL zur xmlrpc.php aus dem Header entfernt. Bots, Hacker, Angreifer, Spammer – Sie alle bekommen nun nicht mehr automatisch Informationen, die sie eigentlich gar nicht bekommen sollten. Schaffen sie es dennoch, die xmlrpc.php zu finden, blockt WordPress sofort den Zugriff.
Performance durch Blocken verbessern
Am Ende lässt sich nun noch an der Performance schrauben. Solange WordPress nämlich auf die xmlrpc.php zugreifen kann, entstehen auch weiterhin versteckte Aufrufe, die nicht gerade die Leistung verbessern. Um mit einem letzten Schritt nun also noch einmal die allgemeine Performance ein klein wenig zu erhöhen, solltet ihr die xmlrpc.php noch via .htaccess blocken. Das geht folgendermaßen. Weitere Tipps für die .htaccess gibt es übrigens hier.
Folgendes in die .htaccess euer WordPress-Installation einfügen:
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>
Sicherheit und Performance
Am Ende ist all das für die Sicherheit und Performance gut. Wenn ihr etwas in WordPress nicht benötigt, dann sollte selbiges nach Möglichkeit auch immer deaktiviert werden, alleine schon, um ein winziges Stück mehr Leistung herauszukitzeln. Sicherheit spielt bei der XML-RPC Schnittstelle natürlich ebenfalls eine große Rolle, weil Bots und Hacker schon automatisiert darauf zugreifen bzw. es immer wieder versuchen. Mit den Snippets bzw. der Anleitung oben, schafft ihr hier nun Abhilfe.
So wird XML-RPC in WordPress komplett deaktiviert, was am Ende mehr Sicherheit und ein wenig gesteigerte Performance bringt. Spüren werdet ihr letztere sicherlich nicht, doch es lohnt sich auch, um den eigenen Server ein wenig zu entlasten und die Angreifer schon vorab abzuwehren bzw. abzuschrecken.