WordPress-Sicherheit ist ein weites Feld. Fragt man drei Experten, bekommt man vier Meinungen. Jeder hat seine eigenen Erfahrungen gemacht und schwört auf seine eigenen Lösungen. Dabei gibt es Bereiche, auf die bei der Absicherung besonders viel Wert gelegt wird und für die viele Plugin-Lösungen existieren. Die Absicherung des Logins zum Beispiel. Andererseits bestätigen Untersuchungen, dass diese Bereiche gar nicht das Haupteinfallstor von Angriffen sind. Ähnlich verhält es sich mit dem Versuch, alle Anzeichen der Verwendung von WordPress zu verschleiern. Im heutigen Beitrag möchte ich beispielhaft zeigen, an welchen einfachen Dingen die Verschleierung scheitert.
WordPress-Verwendung verschleiern
Es gibt viele Wege, an einer Website zu erkennen, dass diese mit WordPress erstellt wurde. Unter Umständen kann man auch die genutzte Version herausfinden. Einige Sicherheitsplugins verwenden große Energie darauf, diese Hinweise auf WordPress zu entfernen oder zu verschleiern. Hintergrund ist wohl die Hoffnung, dass wordpress-typische Angriffsvektoren von Angreifern nicht durchgeführt würden, wenn nicht klar ist, ob es sich um eine WordPress-Website handelt.
Beobachtungen von Log-Dateien zeigen aber, dass es den allermeisten Angreifern komplett egal ist, was für eine Website sie da gerade vor sich haben. Da die Angriffe automatisiert ablaufen, werden einfach alle möglichen Sicherheitslücken durchprobiert. Es passiert also auch, dass auf einer klar erkennbaren WordPress-Website bekannte Joomla-Lücken durchprobiert werden. Alleine aus diesem Grund macht das Verstecken der WordPress-Nutzung schon keinen Sinn.
Thorsten Frommen hat eine beeindruckende Liste zusammengestellt, die zeigt, woran man alles erkennen kann, dass eine Website WordPress nutzt:
https://tfrommen.de/how-to-detect-wordpress-websites/
Die Quintessenz ist: es ist unmöglich, alle Anzeichen von WordPress zu verschleiern. Auf ein besonderes Element möchte ich exemplarisch eingehen: den Aufruf von /wp-admin/admin-ajax.php. Vorab aber noch ein paar andere Gedanken.
WordPress-Login absichern oder nicht
Mit dem Absichern des WordPress-Logins wird, insbesondere von Anfängern, extrem viel Zeit verbracht. Gerade in diesem Bereich gibt es besonders viele Sicherheits-Plugins. Das Hauptaugenmerk liegt dabei darauf, Brute-Force-Attacken auf den Login (also das andauernde Ausprobieren diverser Passwörter) zu verhindern. Untersuchungen zeigen jedoch, dass der Login-Bereich nicht das sensible Element einer WordPress-Installation ist und die allermeisten erfolgreichen Angriffe ganz anders erfolgen als über eine Brute-Force-Attacke. Ernesto Ruge hat dazu auch mal einen Artikel verfasst:
WordPress Login-Security: Eine Stahltür in der Wellblechhütte
Der beste (und ausreichende) Schutz des Logins ist die Verwendung eines starken Passworts mit mindestens 12 Zeichen Länge.
Wem nun die andauernden Login-Versuche der Bots auf den Keks gehen oder wer feststellt, dass durch massive Angriffe die Server-Performance leidet, kann weitere einfache Maßnahmen ergreifen.
Obwohl Verschleierung keine klassische Sicherheitsmaßnahme ist („Security by Obscurity“), kann es helfen, den WordPress-Login auf eine andere Adresse als http://www.meineseite.tld/wp-login.php bzw. http://www.meineseite.tld/wp-admin zu legen. Der Login ist dann zum Beispiel nur noch über die Adresse http://www.meineseite.tld/mein-login zu erreichen. Damit laufen alle Bot-Login-Versuche ins Leere.
Ein einfaches Plugin für die Umbenennung des WordPress-Logins ist „Rename WP-Login“:
Nachteil dieser Lösung ist, dass bei jedem Bot-Aufruf der eigentlichen Login-URL weiterhin eine PHP-Ausführung stattfindet und damit die Serverauslastung nicht geschont wird.
Wer also aufgrund massiver Performanceprobleme noch einen weiteren Schritt gehen möchte, kann eine BasicAuth-Passwortabfrage vor den eigentlichen Login schalten. Diese Maßnahme, gerne auch htaccess-Schutz genannt, erfordert vor dem eigentlichen WP-Login eine weitere Passwort-Eingabe, die serverseitig realisiert wird, keine PHP-Ausführung benötigt und damit die Serverpower schont.
Was hat das alles mit WordPress-Verschleierung zu tun?
Kommen wir zurück zum eigentlichen Thema, dem Verstecken aller WordPress-Hinweise.
Die Datei wp-admin/admin-ajax.php ist ein wichtiges Element in jeder WordPress-Installation, ist sie doch die Basis jeder AJAX-Kommunikation. Sie wird insbesondere im WordPress-Backend für AJAX-Aufrufe genutzt, zum Beispiel wenn in der Admin-Oberfläche eines Plugins Daten nachgeladen werden sollen. Der Aufruf der admin-ajax.php wird aber auch im Frontend, also auf der eigentlichen Seite genutzt. Die Standard-Wordpress-Methode zur AJAX-Kommunikation oder allgemein zum Laden von Daten ist eben auch im Rahmen der normalen Website die Datei wp-admin/admin-ajax.php.
Schließender Kreis 1: Admin-Ajax und umbenannte Login-URLs
Und nun schließt sich der Kreis der beiden eigentlich nicht zusammen passenden Themen dieses Beitrags. Egal was man verschleiert, egal ob man die Login-URL umbenennt: der Aufruf von wp-admin/admin-ajax.php ist und bleibt unverändert. Ein Angreifer kann also zum einen den Seitenquelltext durchprüfen, ob ein solcher Aufruf darin auffindbar ist oder einfach selbst die passende URL aufrufen und den Rückgabewert prüfen. Ohne weitere Parameter und Einstellungen liefert wp-admin/admin-ajax.php den Wert „0“ zurück. handelt es sich nicht um ein WordPress-System würde der HTTP-Fehler 404 zurückgeliefert werden, da die Datei nicht existiert.
Schließender Kreis 2: Falscher BasicAuth-Schutz macht WP-Funktionen kaputt
Und nun zum zweiten sich schließenden Kreis. Immer wieder sehe ich die Empfehlung, mittels htaccess-Schutz (BasicAuth) den Login abzusichern (siehe oben). Dabei wird häufig vorgeschlagen, dass Verzeichnis wp-admin entsprechend zu schützen. Das ist aber falsch! Wer wp-admin mit einem Passwortschutz versieht, hindert WordPress an der Kommunikation mittels admin-ajax.php und verhindert damit unter Umständen das korrekte Funktionieren diverser Plugins, die diese Funktion im Frontend nutzen.
Beim Aufruf von wp-admin wird man sowieso immer auf die Datei wp-login.php weitergeleitet, wenn man nicht eingeloggt ist. Somit reicht es, die wp-login.php mittels htaccess zu schützen, so man denn diese Lösung überhaupt präferiert:
<Files wp-login.php> AuthName "Du kommst hier nicht rein" AuthType Basic AuthUserFile /pfad/zur/.htpasswd Require valid-user </Files>
Dieser Schnipsel gehört in die .htaccess-Datei im WordPress-Hauptverzeichnis.
Eine Beispiel-Lösung inklusive weiteren Vorschlägen habe ich in einem Gist zusammengestellt:
https://gist.github.com/zottto/6b44eb58baf44fc6bd62
Ich persönlich bin übrigens kein Freund dieser BasicAuth-Absicherung, denn für mich ist der Verlust an Usability durch eine zweimalige Passwortabfrage deutlich größer als der Nutzen. Diese Technik sollte wirklich nur dann eingesetzt werden, wenn der Server aufgrund der Bot-Angriffe massiv in die Knie geht.
Fazit
Das Fazit dieses Artikels kurz zusammengefasst:
- Hinweise auf WordPress und seine Version verschleiern bringt nichts
- Die beste Absicherung des Logins sind starke Passwörter, alle anderen Maßnahmen sind übertrieben
- Wer mag, kann noch die Login-URL umbenennen
- Trotz geänderter Login-URL und allen anderen Verschleierungsmaßnahmen erkennt man WordPress immer noch an der Nutzung der wp-admin/admin-ajax.php
- Setzt man die htaccess/BasicAuth-Passwortabfrage für den Login falsch, macht man unter Umständen die Funktion von WordPress bzw. von diversen Plugins im Frontend kaputt
Vielen Dank für den Beitrag. Klingt alles sinnvoll und nachvollziehbar. Den Kauf und die Installation eines weiteren Plugins kann ich mir so schenken.
Hallo,
… wenn Du die wp-login.php mittels htaccess zu schützt, bekommst Du aber, wenn Woocommerce auch im Einsatz ist, Probleme. Spaetestens, wenn sich die User in/an ihrem Kundenkonto anmelden moechten.
Die bekommen dann auch die htaccess-Abfrage und kommen nicht weiter.
Gruß, Mike
Klar, wann immer du WordPress so verwendest, dass auch Besucher einen Benutzerlogin haben, kann man die htaccess-Methode nicht nutzen. Auch bei Mitgliederbereichen und Ähnlichem.