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 ;)
Hallo und vielen Dank für diesen Artikel, der mir sehr geholfen hat.
Die RewriteRule schließt aber viel m.E. zu viel aus, z.B. auch /.well-known/, was u.a. von letsencrypt benutzt wird.
Kannst du mir erläutern, warum du \. in dem RegExp Ausdruck drin hast?
Ich hab’s jetzt mal auf die Schnelle so umgeschrieben, aber bin mir nicht sicher, ob das optimal ist:
RedirectMatch 403 ^(/)?(wp-config|wp-settings)
Danke,
Andy
In der Tat schließt der
RedirectMatch
alle versteckten Dateien und Verzeichnisse aus. Das war in meinem Fall so gewollt. Wenn man jedoch bspw. das Let’s Encrypt SSL Zertifikat via HTTP Challenge holen will, dann muss das angepasst werden. LG