debug.log verstecken | ProjectDMC.org Deutsch

Die Log-Dateien geben nicht nur dir einen Hinweis auf mögliche Probleme, sondern können auch für Angreifer eine interessante Information liefern, auf was sie sich beim Angriff konzentrieren sollen.

Beispiel: im Debug-Log steht, dass im Plugin „VeryBadCode“ einen Syntaxfehler in der Datei options.php aufgetreten ist. Da Fehler in WordPress Plugins meistens schnell gefixt werden, könnte das ein Hinweis auf eine ältere Version sein, die vielleicht auch noch andere Probleme (und vor allem eine Sicherheitslücke) hat. Ein Angriff könnte darauf abzielen, über die Abfrage von Debug-Logs diverser Websites solche Sicherheitslücken auszunutzen.

Üblicherweise wirst du deshalb über eine Regel in der .htaccess den direkten Zugriff per Browser verweigern.

<FilesMatch ".(htaccess|htpasswd|ini|psd|log|sh)$">
Order Allow,Deny
Deny from all
</FilesMatch>

Sinnvoll ist auch z.B., den Zugriff auf readme.txt bzw. readme.md zu blockieren, damit Angreifer nicht so schnell auf die Versionsnummer eines Plugins kommen.
Bei einem Hackathon haben sich ein paar Programmierer dazu Gedanken gemacht, welche Dateien problematisch sein könnten und wie sich der Zugriff mit dem Kommandozeilen-Tool WP-CLI mit einem einzigen Befehl sperren lässt. Für Programmierer ist die Beschreibung auf der GitHub-Seite interessant: https://github.com/igorhrcek/wp-cli-secure-command

Viele Webhoster nutzen übrigens nginx als Reverse Proxy für Apache2, weil dann weiterhin die „.htaccess Tricks funktionieren“ und Kunden z.B. Redirects weiterhin nutzen können.

Ideal wäre, den Debug-Modus nur zur Fehlerbehebung zu aktivieren und nach erfolgreicher Arbeit die Log-Datei zu löschen und den Eintrag in der wp-config.php zu entfernen. Auch Dateien wie phpinfo.php mit Ausgabe aller Informationen zur genutzten (und vielleicht schon veralteten) PHP-Version gehen eigentlich niemanden etwas an.

Ich hatte schon ein paar Mal angesetzt, um zu antworten, aber dann wieder verworfen.
Ist die wp-debug.log gemeint oder die serverseitig optional mögliche debug-/debugging.log-Datei?

@la-geek
also ich meine die „debug.log“, welche sich automatisch innerhalb von wp-content zeigt, wenn in der wp-config aktiviert

@pixolin
Danke für die Erklärung!

ein Hinweis auf eine ältere Version sein, die vielleicht auch noch andere Probleme

Ok, also doch nicht so harmlos.

Der htaccess Code ist mir so einigermaßen klar und geläufig, bei Nginx bin ich mir oft unsicher. Da frage ich den Hoster und gut ist’s.

nginx als Reverse Proxy für Apache2

Achso ja. Tja, wieder: Hoster fragen, bevor man selber (ev. unnötigerweise umständlich) an der Konfig schraubt.

Klar, dass man nachher Debug wieder abdreht, aber bekäme ich für jedes Mal darauf vergessen 1 €, hätte ich keine Sorgen mehr …

Die mir bekannten Hoster haben inzwischen auch ca. dasselbe gemeint. Abschalten, löschen, sperren

Weitere „Problem“dateien: Das (in dem Github Link) sind ja eine Menge Kandidaten!

Danke!

@kurapika
Ist deine Frage damit beantwortet?

Wie der direkte Browser-Zugriff auf die log-Datei per .htaccess unterbunden werden kann, hat @pixolin erklärt.

Man kann auch die Logs in eine Datei in ein separates Verzeichnis schreiben und die Datei (sowie auch das Verzeichnis) nennen wie man will – wichtig ist, dass die Datei-Endung .log unverändert bleibt. Zusätzlich dazu eine eigene .htaccess-Datei in dieses Verzeichnis, die den Zugriff auf das Log blockiert.

Erklärung zu Verzeichnis/Datei findest du unter meinem obigen Link.
Direktlink zum Absatz:

Man könnte also zum Beispiel in die wp-config.php einfügen:

define( 'WP_DEBUG_LOG', '/qzwvxc/geheime.log' );

Danke, ja v.a. jetzt ist alles klar!

Leider funkt das auch nach 99 Versuchen auf div. Webs nicht.
Die debug.log wird weiterhin als solche in wp-content geschrieben und die selbst definierte Datei erscheint nirgends …

Nach einiger Tüftelei, habe ich folgenden funktionierenden Code gebastelt:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', 'blub/blub.log' );

Wie unter dem Link

zu lesen war, muss WP_DEBUG auf true gesetzt werden.
Das WP_DEBUG_DISPLAY auf false ist eine zusätzliche Absicherung.
Beim Verzeichnis darf am Anfang nicht ein Slash gesetzt werden, das ist im Original-Artikel bzw. im Original-Code dort verkehrt. Also nicht
define( 'WP_DEBUG_LOG', '/blub/blub.log' );
sondern
define( 'WP_DEBUG_LOG', 'blub/blub.log' );

Den Ordner „blub“ habe ich im Stammverzeichnis angelegt. Ich habe dort also wp-content, wp-admin, wp-includes und blub.

WP-DEBUG false darf nicht mehr in der wp-config.php stehen. Nachdem ich die geänderte wp-config.php hochgeladen habe, klick ich auf der Website auf einen Seitenlink und öffne dann (im FTP-Client) das Verzeichnis blub (ich lade ggf. das Verzeichnis neu im Filezilla), dort wird automatisch die Datei blub.log angelegt.

Ich habe überlegt, ob ich meine Lösung schreibe, aber vielleicht ist sie von Interesse. Ich habe mehrere WP-Installationen. Um nur eine Logdatei zu haben, steht in jeder wp-config.php:

define('WP_DEBUG', true);
$debug_log=preg_replace('/(.*)htdocs(.*)/i', '${1}htdocs/logs/mydebug.log', ABSPATH);
define( 'WP_DEBUG_LOG', $debug_log);
define( 'WP_DEBUG_DISPLAY', false );

Mein Homeverzeichnis beim Hoster ist /pfad/zu/htdocs. Dort habe ich ein Verzeichnis logs angelegt. mydebug.log kann ich passwortgeschützt abrufen und ein Cronjob rotiert die Datei.