Warum allgemeine Ratschläge das eigentliche Problem verfehlen können
Viele Empfehlungen klingen gut, verbessern aber die Sicherheitslage einer typischen WordPress-Site nicht wesentlich.
Mein Name ist Cory Marsh und ich beschäftige mich seit mehr als 25 Jahren mit Websicherheit in Idaho und Kalifornien. In dieser Zeit habe ich viele Sicherheitsempfehlungen gehört, die zwar gut klingen, Ihre Sicherheitslage aber nicht wirklich verbessern.
Viele dieser Empfehlungen beruhen auf einem Missverständnis darüber, wie PHP und das Web funktionieren. Da die meisten WordPress-Sites unter Linux gehostet werden, konzentriert sich dieser Artikel auf allgemeine Ratschläge für WordPress-Sites, die auf typischem Linux-Webhosting ausgeführt werden.
Dateiberechtigungen funktionieren nicht so, wie es viele Anleitungen andeuten
„Öffentliche Schreibberechtigung“ wird oft so beschrieben, dass jeder im Internet Ihre PHP-Dateien bearbeiten kann. So funktioniert ein normaler WordPress-Host nicht.
Jede Datei in einem Unix-Dateisystem verfügt über Lese-, Schreib- und Ausführungsberechtigungen. Diese Berechtigungen können für den Dateieigentümer, die Dateigruppe und alle anderen festgelegt werden und werden oft als „öffentlich“ oder „andere“ bezeichnet. Das Missverständnis beginnt, wenn Leute davon ausgehen, dass öffentlicher Schreibzugriff bedeutet, dass jeder Remote-Internetbenutzer die Datei bearbeiten kann.
Die meisten WordPress-Sites verwenden einen Webserver wie Nginx, Apache oder LiteSpeed und einen PHP-Server wie PHP-FPM. Diese laufen in der Regel lokal unter demselben Webbenutzer. Sie verwenden lokale Benutzerberechtigungen und keine direkten öffentlichen Berechtigungen für den Zugriff auf das Internet.
Damit ein Remote-System Dateien über öffentliche Dateiberechtigungen ändern kann, ist ein Remote-Dateisystemzugriff erforderlich, beispielsweise eine öffentlich bereitgestellte NFS-Freigabe. Auf diese Weise stellen typische Hosting-Anbieter WordPress nicht zur Schau. Sie sollten die Berechtigungen trotzdem konsistent halten und unnötige Schreibzugriffe reduzieren, aber öffentliche Unix-Berechtigungen stellen nicht das direkte Risiko für die Fernbearbeitung dar, das viele Checklisten implizieren.
Die Sicherheit von Hosting-Unternehmen ist nicht die Grundlage für die Exploit-Prävention von WordPress
Betriebssystemaktualisierungen sind wichtig, aber die meisten WordPress-Kompromisse beginnen nicht mit einem veralteten Systempaket.
Ich möchte das Marketingspiel eines Hosting-Anbieters nicht auf den Kopf stellen, aber ich habe selten erlebt, dass eine WordPress-Site aufgrund eines veralteten Betriebssystempakets kompromittiert wurde. Mit ungewöhnlichen Ausnahmen wie ImageMagick gibt es nicht viele Betriebssystempakete, die normaler PHP-Code direkt auf eine Weise erreichen kann, die die häufige WordPress-Kompromittierung vorantreibt.
PHP ist das System, das den dynamischen Anwendungscode ausführt, mit dem Angreifer interagieren. Auf einem typischen Linux-WordPress-Host ist die Wahrscheinlichkeit, dass der Angreifer ein anfälliges Plugin, Theme oder einen nicht authentifizierten Endpunkt ausnutzt, weitaus größer als eine Schwachstelle im Kernel oder Systempaket.
Das Ändern des WordPress-Datenbankpräfixes stellt keinen sinnvollen Schutz dar
Das Standardpräfix ist für Angreifer sichtbar und für Malware leicht zu erkennen.
WordPress hat ein Datenbanktabellenpräfix. Die Standardeinstellung ist wp_. Dieses Verhalten stammt aus der WordPress-Geschichte, einschließlich Multi-Site- und Multi-User-Mustern, bei denen separate Tabellen separate Präfixe benötigten.
Heutzutage bietet die Änderung des Präfixes nur noch einen geringen Sicherheitswert. Moderne Malware und automatisierte Exploit-Tools können das Präfix erkennen oder daraus ableiten. Die Existenz vieler Exploit-Pfade von WP zu Shell zeigt, dass dieser Wert im modernen Zeitalter der KI-gestützten Malware keine ernsthafte Grenze darstellt.
Das Entfernen der WordPress-Versionsnummer hält Angreifer nicht davon ab
Bei den meisten Angriffen wird Ihr Generator-Tag nicht sorgfältig überprüft, bevor ein Exploit ausgeführt wird.
Das Verbergen der WordPress-Versionsnummer vor Generator-Tags macht es für Sicherheitsscanner meist schwieriger, Ihre Version genau zu melden. Die meisten automatisierten Angriffe machen sich nicht die Mühe, zunächst den Webserver oder die WordPress-Version zu überprüfen. Sie senden den Exploit an jedes Ziel, das sie finden können.
Wenn die Website angreifbar ist, wird sie kompromittiert. Wenn es nicht angreifbar ist, zieht der Angreifer weiter. In einigen Fällen kann die vorherige Überprüfung der Versionen sogar dazu führen, dass Sicherheitssoftware einen Hinweis erhält und die IP eines Angreifers gesperrt wird, bevor der eigentliche Exploit gestartet wird.
Eine gute WAF blockiert nicht jeden Webangriff
Herkömmliche WAFs können einige Angriffe blockieren, aber viele moderne WordPress-Exploits stellen fehlerhafte Zugriffskontrollprobleme dar.
Firewall-Regelsätze wie 6G, 7G oder eine bevorzugte WAF können einige Webangriffe blockieren. Sie sind häufig gegen Teile von Cross-Site-Scripting und SQL-Injection nützlich, obwohl die Bilanz selbst dort gemischt ist. Wenn sie zu aggressiv blockieren, blockieren sie guten Verkehr. Blockieren sie nicht ausreichend, ist der Wert begrenzt.
Inline-WAF-Produkte von Anbietern wie AWS, Cloudflare und Sucuri können mit den von ihnen verstandenen Angriffsklassen hervorragende Arbeit leisten. Das Problem ist, dass viele moderne WordPress-Kompromisse keine klassische XSS- oder SQL-Injection sind. Sie sind kaputte Zugangskontrolle.
Eine fehlerhafte Zugriffskontrolle bedeutet, dass ein Entwickler vergessen hat, einen gültigen Administrator oder autorisierten Benutzer zu benötigen, bevor er einen gefährlichen Vorgang wie das Hochladen einer Datei auf einen API-Endpunkt zulässt. Eine signaturbasierte WAF hat möglicherweise keine Vorstellung davon, was die Anfrage in PHP bewirken soll. Es sieht eine Anfrage, sucht nach bekannten Mustern und kann den Exploit durchwinken.
Verwenden Sie Laufzeitschutz für gefährliches Anwendungsverhalten
Das größte Anwendungssicherheitsrisiko erfordert Kontrollen, die beobachten können, was die Anfrage tut.
Um einen echten Schutz vor einer fehlerhaften Zugriffskontrolle zu erhalten, benötigen Sie einen Laufzeitschutz, der die Anforderung während der Ausführung überwacht und verhindert, dass nicht authentifizierte Anforderungen gefährliche Aktionen ausführen. Ein Tool wie BitFire für WordPress verfügt über RASP-Funktionen, die die Ausnutzung anfälliger Plugins und Themes verhindern können, indem gefährliche Vorgänge im Kontext blockiert werden.
Legen Sie konsistente Dateisystemberechtigungen fest und reduzieren Sie unnötige Zugriffe nach Möglichkeit.
Halten Sie das Betriebssystem, PHP, den WordPress-Kern, Plugins und Themes auf dem neuesten Stand.
Eine gute WAF kann echte Angriffe blockieren, insbesondere bekannte bösartige Muster und häufige Einschleusungsversuche.
Verhindern Sie, dass nicht authentifizierte Anfragen Dateien schreiben, vertrauliche Daten ändern oder Verwaltungsaktionen durchführen.
Nicht alle gängigen Empfehlungen sind schlecht. Sie sollten sinnvolle Dateiberechtigungen implementieren. Sie sollten Ihr Betriebssystem im Hinblick auf Kompatibilität, Korrekturen und Leistungsverbesserungen auf dem neuesten Stand halten. Sie sollten eine gute WAF betreiben, da diese einige echte Angriffe blockieren kann.
Erwarten Sie jedoch nicht, dass diese Empfehlungen allein Ihre Website retten, wenn die nächste Plugin-Schwachstelle Ihre Website betrifft.
