WordPress-Sicherheitsgrundlagen, die die meisten Angriffe stoppen
Wenn ich eine kompromittierte WordPress-Seite aufräume, ist die Ursache fast nie ein ausgeklügelter, gezielter Angriff. Es ist ein veraltetes Plugin mit einer bekannten Schwachstelle, die schon vor Monaten gepatcht wurde, ein wp-admin-Login mit einem Passwort, das in irgendeinem unabhängigen Leak aufgetaucht ist, oder ein altes Theme, das seit dem Launch der Seite nie wieder angefasst wurde und eine File-Upload-Schwachstelle hat, die seither niemand mehr angeschaut hat. WordPress' Popularität bedeutet, dass automatisierte Scanner ständig genau danach suchen, und die folgenden Grundlagen schließen diese Tür.
Updates: der mit Abstand größte Faktor
Die meisten WordPress-Kompromittierungen lassen sich auf ein Plugin oder Theme mit einer öffentlich bekannten Schwachstelle zurückführen, das einfach nicht aktualisiert wurde. WordPress selbst übernimmt Sicherheitsupdates standardmäßig automatisch, Plugins und Themes aber nicht, sofern sie nicht entsprechend konfiguriert sind:
// wp-config.php
add_filter('auto_update_plugin', '__return_true');
add_filter('auto_update_theme', '__return_true');
Für Seiten, bei denen die Sorge, dass ein Plugin-Update etwas kaputt macht, größer ist als das Sicherheitsrisiko, nicht zu aktualisieren, ist eine Staging-Umgebung, die Updates zuerst bekommt, mit Produktion ein paar Tage später, ein vernünftiger Mittelweg. Was nicht vernünftig ist, ist "wir aktualisieren, wenn wir dazu kommen", denn genau dieses Zeitfenster suchen automatisierte Scanner.
Entfernen, was nicht genutzt wird
Jedes inaktive Plugin und Theme ist immer noch Code, der auf dem Server liegt, und "inaktiv" heißt nicht "nicht ausnutzbar", eine Schwachstelle in den Dateien eines deaktivierten Plugins lässt sich oft trotzdem direkt erreichen, wenn die Datei selbst zugänglich ist. Die Lösung ist nicht Deaktivieren, sondern Löschen:
wp plugin list --status=inactive
wp plugin delete <plugin-name>
Wird es später wieder gebraucht, lässt es sich in dreißig Sekunden neu installieren. Ungenutzt auf der Platte ist es reine Angriffsfläche ohne jeden Nutzen.
Login-Sicherheit: wo die meisten automatisierten Angriffe landen
/wp-login.php und /xmlrpc.php werden ständig von automatisierten Login-Versuchen getroffen, egal wie unbekannt die Seite ist. Ein paar Änderungen adressieren das Meiste davon:
Starke, einzigartige Passwörter und 2FA für jedes Konto mit Veröffentlichungs- oder Admin-Rechten, nicht nur das Haupt-Admin-Konto, ein Mitwirkenden-Konto mit schwachem Passwort ist immer noch ein Einstiegspunkt.
Login-Versuche begrenzen, entweder über ein Plugin oder, auf Serverebene, mit einer Fail2ban-Jail, die wiederholte fehlgeschlagene Logins gegen wp-login.php beobachtet:
# /etc/fail2ban/jail.local
[wordpress]
enabled = true
filter = wordpress
logpath = /var/log/nginx/access.log
maxretry = 5
bantime = 3600
XML-RPC deaktivieren, wenn nichts (keine App, keine Jetpack-artige Integration) es tatsächlich nutzt, denn es ist ein beliebtes Ziel sowohl für Brute-Force-Versuche als auch für Amplification bei Pingback-basierten Angriffen, und die meisten Seiten haben keinen legitimen Nutzen dafür.
Den Admin-Bereich absichern
DISALLOW_FILE_EDIT entfernt den eingebauten Theme- und Plugin-Datei-Editor aus dem WordPress-Admin, den Editor, mit dem jeder mit Admin-Zugriff PHP-Dateien direkt über den Browser bearbeiten kann. Wird jemals ein Admin-Konto kompromittiert, ist das ein Weg weniger, wie aus dieser Kompromittierung beliebige Codeausführung wird:
// wp-config.php
define('DISALLOW_FILE_EDIT', true);
Auch Dateiberechtigungen sind wichtig, WordPress' eigene Empfehlung von 644 für Dateien und 755 für Verzeichnisse, mit wp-config.php auf 600, bedeutet, dass selbst wenn eine Schwachstelle Schreibzugriff aufs Dateisystem erlaubt, dieser durch das begrenzt ist, was der Benutzer des Webservers überhaupt anfassen darf.
Eine Web Application Firewall fängt ab, was noch nicht gepatcht ist
Updates kümmern sich um bekannte Schwachstellen, sobald ein Patch existiert. Die Lücke zwischen der Entdeckung einer Schwachstelle und der Veröffentlichung eines Patches, und die Lücke zwischen der Veröffentlichung eines Patches und dessen tatsächlicher Anwendung auf jeder Seite, ist der Bereich, in dem eine Web Application Firewall ihren Platz verdient. ModSecurity mit dem OWASP Core Rule Set, oder eine plugin-basierte WAF, blockiert eine ganze Reihe generischer Exploit-Muster (SQL-Injection-Versuche, Path Traversal, gängige Payload-Signaturen), egal welches spezifische Plugin sie eigentlich ins Visier nehmen, was bedeutet, dass sie selbst gegen Schwachstellen nützlich ist, für die noch niemand eine spezifische Regel geschrieben hat.
Warum diese Grundlagen immer noch die Antwort sind
Nichts davon ist fortgeschritten, und genau das ist der Punkt. Die überwiegende Mehrheit der WordPress-Kompromittierungen sind keine Zero-Days, sondern bekannte Probleme mit verfügbaren Fixes, die einfach nicht angewendet wurden, auf Seiten, bei denen Login-Sicherheit ein nachträglicher Gedanke war. Updates, das Entfernen ungenutzten Codes, Login-Hardening und eine WAF adressieren genau die Kategorien, auf die automatisierte Angriffe tatsächlich zielen, ungefähr in der Reihenfolge, wie oft jede davon die tatsächliche Ursache ist. Das richtig zu machen macht eine Seite nicht unverwundbar, aber es holt sie aus dem riesigen Pool von Seiten heraus, die automatisierte Scanner ohne nennenswerten Aufwand kompromittieren.