MySQL Login-Fehlversuche durch WordPress verursacht
Das Problem
Ein wenig schockiert war ich als in der MySQL Errorlog Datei (/var/log/mysql/error.log
) diese Zeile auftauchte:
2016-07-21T09:37:56.808863Z 2655 [Note] Access denied for user ‚benutzername_hier_einfuegen’@’localhost‘ (using password: YES)
Da mein Datenbank-Server nicht über das Netzwerk erreichbar ist, musste der Login-Versuch von einem Skript auf dem Server ausgelöst worden sein. Kurz kam die Frage auf: Wurde ich gehackt?! Aber der Benutzername „benutzername_hier_einfuegen“ deutete irgendwie schon darauf hin, dass es eher ein Platzhalter als ein Angriff sein sollte.
Also habe ich unter allen Usern auf dem Server den Platzhalter gesucht:
find /home/ -type f -exec grep -H -n 'benutzername_hier_einfuegen' {} \;
Die Ursache
Und siehe da, dieser Platzhalter wird von WordPress in der Datei wp-config-sample.php genutzt.
Auch wenn ich WordPress als Blog-Software echt gut finde, so ist die Datei-Struktur grausam: Sämtliche Dateien werden innerhalb eines Ordners platziert, auf den der Webserver generell erstmal Zugriff hat – auch Konfigurationsdateien! Das macht natürlich auch das Ausnutzen eventuell vorhandener Sicherheitslücken einfacher.
Es hat sich also jemand den Spaß erlaubt (oder was auch immer) und einfach mal die Datei https://ansas-meyer.de/wp-config-sample.php direkt aufgerufen. Dadurch wurde schon der Login-Fehlversuch verursacht und protokolliert.
Zwar habe ich das WordPress Plugin iThemes Security installiert, welches auch brav über die .htaccess
die wp-config.php
aussperrt, aber eben nicht die wp-config-sample.php
Datei.
Die Lösung
Damit das in Zukunft nicht mehr passiert, habe ich die die wichtigsten Dateien einmal selbst in der .htaccess
von Hand ausgesperrt:
# BEGIN Custom <IfModule alias_module> RedirectMatch 403 ^(/)?(\.|wp-config|wp-settings|install) </IfModule> # END Custom
Zum Schluss
Natürlich kann ich den Datei-Aufbau von WordPress irgendwo verstehen… es ist das wahrscheinlich meistverwendete CMS (Content-Management-System) der Welt und soll auch auf kleinen Webspace Lösungen funktionieren, wo ein User nur Zugriff auf den Ordner hat, der gleichzeitig DocumentRoot des Webservers ist. Aber „sicher“ ist anders ;)