WordPress-Security-Basics, die die meisten Angriffe stoppen

Wenn ich eine kompromittierte WordPress-Seite bereinige, ist die eigentliche Ursache fast nie ein hochkomplexer, zielgerichteter Angriff. Es ist ganz einfach ein veraltetes Plugin mit einer weithin bekannten Schwachstelle (Vulnerability), für die es schon seit Monaten einen öffentlichen Patch gibt. Es ist ein wp-admin-Login mit einem schwachen Passwort, das bei irgendeinem völlig unabhängigen Daten-Leak erbeutet wurde. Oder es ist ein uraltes Theme, das seit dem Launch der Seite absolut nicht mehr angerührt wurde und das eine Datei-Upload-Schwachstelle in sich trägt, die sich seitdem niemand mehr angesehen hat.

Die schiere Popularität von WordPress bedeutet, dass automatisierte Scanner pausenlos und unerbittlich das gesamte Internet nach exakt diesen Dingen abtasten (proben). Die völlig unglamourösen Basics hier unten sind es, die diese Tür tatsächlich zuschlagen.

Updates: Der mit Abstand größte Faktor

Die überwältigende Mehrheit aller WordPress-Kompromittierungen lässt sich direkt auf ein Plugin oder Theme mit einer öffentlich bekannten Schwachstelle zurückführen, das schlichtweg nicht geupdated wurde. Der WordPress-Core handhabt seine eigenen kleineren Sicherheitsupdates standardmäßig automatisch, aber Plugins und Themes tun dies absolut nicht – es sei denn, man konfiguriert es explizit:

// wp-config.php
add_filter('auto_update_plugin', '__return_true');
add_filter('auto_update_theme', '__return_true');

Für kritische Seiten, bei denen ein Plugin-Update, das etwas zerschießt, eine ernsthaft größere Sorge ist als das brutale Sicherheitsrisiko, nicht zu updaten, ist eine Staging-Umgebung der perfekte Mittelweg. Dort werden Updates zuerst eingespielt und die Produktion folgt ein paar Tage später.

Was absolut nicht vernünftig ist, ist die Einstellung: "Wir updaten das, wenn wir mal dazu kommen." Denn genau dieses "wenn wir mal dazu kommen" ist exakt das Zeitfenster, nach dem automatisierte Scanner verzweifelt suchen.

Entfernen Sie, was nicht aktiv genutzt wird

Jedes einzelne inaktive Plugin und Theme ist immer noch physischer Code, der auf dem Server herumliegt. Und "inaktiv" bedeutet absolut nicht "nicht ausnutzbar" (not exploitable). Eine Schwachstelle in den Dateien eines deaktivierten Plugins kann oft immer noch direkt angesprochen werden, wenn die Datei selbst öffentlich über das Web erreichbar ist.

Die Lösung ist nicht, sie zu deaktivieren. Die Lösung ist, sie aggressiv zu löschen:

wp plugin list --status=inactive
wp plugin delete <plugin-name>

Falls es später tatsächlich wieder gebraucht wird, kann es in dreißig Sekunden neu installiert werden. Wenn es komplett ungenutzt auf der Festplatte liegt, ist es pure, unverdünnte Angriffsfläche mit absolut null Nutzen.

Login-Sicherheit: Wo die meisten automatisierten Angriffe gewaltsam einschlagen

/wp-login.php und /xmlrpc.php werden konstant und aggressiv von automatisierten Login-Versuchen bombardiert, völlig unabhängig davon, wie unbekannt oder klein die Seite ist. Ein paar grundlegende Änderungen lösen fast das gesamte Problem:

Starke, absolut einzigartige Passwörter und 2FA für absolut jeden einzelnen Account mit Veröffentlichungs- oder Admin-Rechten. Das meint nicht nur den Haupt-Admin-Account. Ein vergessener Contributor-Account mit einem schwachen Passwort ist immer noch ein hervorragender Fuß in der Tür zum System.

Login-Versuche limitieren, entweder über ein solides Plugin oder – noch sehr viel besser – auf Serverebene mit einem Fail2ban-Jail, das aktiv nach wiederholten fehlgeschlagenen Logins gegen wp-login.php Ausschau hält:

# /etc/fail2ban/jail.local
[wordpress]
enabled = true
filter = wordpress
logpath = /var/log/nginx/access.log
maxretry = 5
bantime = 3600

XML-RPC komplett deaktivieren, wenn absolut nichts (keine Custom-App, keine Jetpack-artigen Integrationen) es tatsächlich nutzt. Es ist ein massives, extrem häufiges Ziel – sowohl für direkte Brute-Force-Versuche als auch für die aggressive Verstärkung (Amplification) von Pingback-basierten Angriffen. Die überwältigende Mehrheit der Seiten hat heutzutage absolut null legitimen Nutzen mehr dafür.

Den Admin-Bereich rigoros abriegeln

DISALLOW_FILE_EDIT entfernt den eingebauten Theme- und Plugin-Datei-Editor gnadenlos aus dem WordPress-Admin-Dashboard. Das ist dieser erschreckende Editor, der es jedem mit Admin-Zugang erlaubt, rohe PHP-Dateien direkt über den Webbrowser zu bearbeiten. Sollte ein Admin-Account jemals kompromittiert werden, schneidet dies einen der einfachsten Wege ab, über den diese Kompromittierung sofort in eine beliebige Code-Ausführung (Arbitrary Code Execution) umschlagen kann:

// wp-config.php
define('DISALLOW_FILE_EDIT', true);

Auch Dateiberechtigungen (File Permissions) sind extrem wichtig. Die strenge WordPress-eigene Empfehlung von 644 für Dateien und 755 für Verzeichnisse (wobei die wp-config.php aggressiv auf 600 abgeriegelt sein sollte) bedeutet: Selbst wenn eine schwere Schwachstelle das Schreiben in das Dateisystem erlaubt, ist dies stark darauf beschränkt, was der Linux-Benutzer des Webservers tatsächlich überhaupt anfassen darf.

Eine Web Application Firewall fängt ab, was noch nicht gepatcht ist

Updates regeln bekannte Schwachstellen perfekt, sobald ein Patch existiert. Aber die Lücke zwischen der Entdeckung einer Schwachstelle und dem Release eines Patches – und die noch viel größere Lücke zwischen dem Release eines Patches und dem Zeitpunkt, an dem ihn wirklich jede einzelne Seite anwendet – ist genau der Moment, in dem eine Web Application Firewall sich massiv bezahlt macht.

ModSecurity zusammen mit dem OWASP Core Rule Set oder eine hochgradig solide Plugin-basierte WAF blockiert aggressiv eine gewaltige Menge an generischen Exploit-Mustern (SQL-Injection-Versuche, Path Traversal, gängige Payload-Signaturen) – völlig unabhängig davon, welches spezifische Plugin sie gerade verzweifelt ins Visier nehmen. Das bedeutet, dass sie selbst gegen Zero-Day-Schwachstellen, für die noch niemand eine spezifische Regel geschrieben hat, unglaublich nützlich ist.

Warum diese langweiligen Basics immer noch die Antwort sind

Absolut nichts davon ist Advanced-Level, und genau das ist der Punkt. Die gigantische, erdrückende Mehrheit von WordPress-Kompromittierungen sind keine exotischen Zero-Days. Es sind extrem bekannte Probleme mit sofort verfügbaren Lösungen, die auf Seiten, wo grundlegende Login-Sicherheit höchstens ein Nebengedanke war, schlichtweg nicht angewendet wurden.

Aggressive Updates, das rücksichtslose Entfernen von ungenutztem Code, das Abriegeln von Logins und das Betreiben einer WAF adressieren perfekt die exakten Kategorien, auf die automatisierte Angriffe tatsächlich abzielen – und zwar ziemlich genau in der Reihenfolge, wie oft sie die eigentliche Ursache sind. Dies komplett richtig zu machen, macht eine Seite nicht auf magische Weise unangreifbar. Aber es holt sie aggressiv aus jenem riesigen Pool tiefhängender Früchte heraus, die automatisierte Scanner völlig trivial und ohne jede echte Anstrengung kompromittieren.