Die Website härten: Berechtigungen, Header und Sicherheits-Plugins

Modul 7: Sicherheit · Lesezeit: 10 Minuten

Lernziel: Nach dieser Lektion können Sie eine WordPress-Website mit Berechtigungen, Einstellungen und Sicherheits-Headern härten und Sicherheits-Plugins richtig einschätzen.

Kernbegriffe: Härten (Hardening), Dateirechte (644, 755), DISALLOW_FILE_EDIT, kein PHP in Uploads, Verzeichnisauflistung, Version verbergen, X-Powered-By, Sicherheits-Header, Backup-Dateien und .git im Webverzeichnis, WAF auf dem Server, WAF in einem Plugin, Malware-Scanner

Was Härten bedeutet

Härten bedeutet: die Website so einstellen, dass ein Fehler oder eine Sicherheitslücke weniger Schaden anrichten kann. Es ersetzt nicht Updates und starke Passwörter (Lektion 7.2 und 7.3), verringert aber die Folgen. Denken Sie an ein Haus: Updates sind die Schlösser, Härten sorgt dafür, dass ein Einbrecher, der trotzdem drin ist, nicht an den Tresor kommt.

Dateirechte

Jede Datei und jedes Verzeichnis auf dem Server hat Rechte: wer darf lesen, schreiben und ausführen. Sie werden als drei Ziffern geschrieben, für den Eigentümer, die Gruppe und den Rest der Welt. Die Richtlinie aus der Dokumentation von WordPress:

Welcher Wert für wp-config.php funktioniert, hängt davon ab, wie Ihr Hoster PHP ausführt: Bei den meisten Shared-Hosting-Umgebungen läuft PHP als Ihr eigener Benutzer, und dann reicht 600. Probieren Sie es aus und prüfen Sie, ob die Website noch funktioniert.

Niemals 777. Das bedeutet: Jeder auf dem Server darf schreiben. Eine Anleitung, die sagt „Setzen Sie das Verzeichnis auf 777, wenn das Hochladen nicht funktioniert", löst das Problem falsch. Bei gutem Hosting ist das auch nie nötig.

Einstellungen in wp-config.php

Ein paar Zeilen, die viel ausmachen (oberhalb von „Stop editing"):

// Keine Dateien aus dem Dashboard heraus bearbeiten (Design > Theme-Editor und Plugins > Plugin-Editor).
define( 'DISALLOW_FILE_EDIT', true );

// Fehlermeldungen niemals auf dem Bildschirm von Besuchern (Lektion 5.4).
define( 'WP_DEBUG', false );

Mit DISALLOW_FILE_EDIT verschwindet der Editor, mit dem Sie im Dashboard PHP-Dateien von Themes und Plugins anpassen können. Ein Einbrecher, der ein Administratorkonto übernimmt, kann dann nicht mit zwei Klicks schädlichen Code in Ihr Theme setzen. Sie können weiterhin Plugins installieren; wollen Sie das auch verbieten (zum Beispiel bei einer Website, die Sie für einen Kunden verwalten), gibt es DISALLOW_FILE_MODS, aber dann funktionieren auch Updates über das Dashboard nicht mehr.

Kein PHP in Uploads, keine Verzeichnisauflistung

In wp-content/uploads gehören Bilder und Dokumente, niemals PHP-Dateien. Einbrecher, die über eine Sicherheitslücke eine Datei hochladen können, versuchen genau dort eine PHP-Datei zu platzieren und sie dann aufzurufen. Blockieren Sie das mit einer .htaccess im Verzeichnis uploads (bei LiteSpeed und Apache):

<Files *.php>
Require all denied
</Files>

Schalten Sie auch die Verzeichnisauflistung aus. Ohne index.php oder index.html in einem Verzeichnis zeigen manche Webserver eine Liste aller Dateien an („Index of /wp-content/uploads/2026/11"). Das ist ein Schaufenster für alle, die nach Backups oder sensiblen Dokumenten suchen. In der .htaccess Ihres Webverzeichnisses:

Options -Indexes

Viele Hoster haben dies bereits standardmässig deaktiviert. Die Aufgabe dieser Lektion prüft es.

Keine Reste im Webverzeichnis

Alles im Webverzeichnis ist über das Web abrufbar, ausser was der Server als PHP ausführt oder blockiert. Gefährlich sind:

• Kopien von wp-config.php (wp-config.php.bak, wp-config.old, wp-config.php~ von einem Texteditor): Die enthalten Ihr Datenbankpasswort und werden als Text ausgeliefert (Lektion 1.3);
• Backups wie backup.zip, site.tar.gz oder database.sql im Webverzeichnis;
• ein .git-Verzeichnis von einem Entwickler, womit jemand Ihren gesamten Code (und manchmal Passwörter) herunterladen kann;
• debug.log in wp-content (Lektion 5.4);
• alte Installations- oder Testdateien wie info.php mit phpinfo().

Bewahren Sie Backups ausserhalb des Webverzeichnisses oder ausserhalb des Servers auf, und räumen Sie Reste weg.

Version verbergen: kleiner Gewinn

WordPress setzt standardmässig in das HTML:

<meta name="generator" content="WordPress 7.1.4" />

und dasselbe im RSS-Feed. Auch PHP meldet sich manchmal in einem Header: X-Powered-By: PHP/8.3.14. Das zu verbergen ist sinnvoll, aber erwarten Sie nicht zu viel davon: Die Programme von Einbrechern probieren eine Sicherheitslücke einfach aus, unabhängig von der Version, die Sie zeigen, und Versionen lassen sich oft auch aus ?ver= hinter Skripten ableiten. Verbergen ist Aufräumen, keine Sicherheit. Eine Website, die ihre Version verbirgt, aber nicht aktualisiert wird, ist genauso verwundbar.

So machen Sie es, in einem eigenen kleinen Plugin oder in functions.php Ihres Child-Themes:

remove_action( 'wp_head', 'wp_generator' );
add_filter( 'the_generator', '__return_empty_string' );

Und den PHP-Header mit expose_php = Off in den PHP-Einstellungen Ihres Hosters (bei DirectAdmin in Select PHP version, Options), oder mit Header unset X-Powered-By in .htaccess.

Sicherheits-Header

Mit ein paar Headern teilen Sie dem Browser mit, wie er mit Ihrer Website umgehen soll. Die wichtigsten:

In .htaccess (bei LiteSpeed und Apache):

<IfModule mod_headers.c>
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
</IfModule>

Testen Sie danach, ob alles funktioniert: eingebettete Inhalte, Zahlungs-Buttons, ein Chat-Widget. Externe Werkzeuge wie securityheaders.com und internet.nl zeigen, was Ihre Website sendet.

Sicherheits-Plugins, ehrlich betrachtet

Es gibt viele Sicherheits-Plugins (zum Beispiel Wordfence, Solid Security, All-In-One Security, Sucuri). Sie bündeln häufig: eine Firewall, einen Malware-Scanner, Login-Schutz, Zwei-Faktor-Authentifizierung, Benachrichtigungen und eine Härtungsliste. Nützlich, aber mit Grenzen:

• Eine Firewall in einem Plugin (WAF) startet erst, wenn PHP läuft. Eine böswillige Anfrage muss zuerst durch den Webserver und PHP, bevor das Plugin sie sieht. Eine Sicherheitslücke in einer PHP-Datei, die direkt aufgerufen wird, oder ein Angriff, der PHP selbst stark belastet, hält es nicht immer auf. Eine Firewall auf dem Server (zum Beispiel ModSecurity, Imunify360 oder eine Firewall Ihres Hosters) sitzt früher in der Kette und stoppt mehr, ohne dass Ihr Paket die Rechenarbeit übernimmt. Fragen Sie Ihren Hoster, was auf dem Server läuft.
• Ein Scanner findet im Nachhinein. Ein Malware-Scanner teilt Ihnen mit, dass etwas nicht stimmt. Das ist wertvoll, verhindert aber nichts. Und ein Scanner auf demselben Server wie eine gehackte Website kann selbst auch vom Einbrecher verändert worden sein.
• Sie ersetzen keine Updates. Ein Plugin mit einer bekannten Sicherheitslücke bleibt verwundbar, auch mit einem Sicherheits-Plugin daneben. Manche Sicherheitsdienste bieten „virtuelle Patches", die bekannte Angriffe abwehren, bis Sie aktualisiert haben; praktisch als Überbrückung, nicht als Ersatz.
• Sie sind selbst ein Plugin. Mehr Code, mehr zu aktualisieren, manchmal selbst eine Sicherheitslücke. Und zwei Sicherheits-Plugins gleichzeitig kollidieren oft.
• Sie kosten Rechenleistung, vor allem Scanner, die auf Ihrem eigenen Server laufen.

Eine vernünftige Wahl: Schauen Sie zuerst, was Ihr Hoster bereits tut (Firewall, Malware-Scan, Blockieren von Login-Versuchen). Ergänzen Sie, was fehlt, meist Zwei-Faktor-Authentifizierung und die Begrenzung von Login-Versuchen. Ein umfangreiches Sicherheits-Plugin ist vor allem nützlich bei Hosting, das selbst wenig tut.

Zusammenfassung

• Härten begrenzt den Schaden eines Fehlers oder einer Sicherheitslücke; es ersetzt nicht Updates und Passwörter.
• Verzeichnisse 755, Dateien 644, wp-config.php strenger; niemals 777.
• Schalten Sie DISALLOW_FILE_EDIT ein, blockieren Sie PHP in Uploads, schalten Sie Verzeichnisauflistungen aus und räumen Sie Backups, .git und debug.log aus dem Webverzeichnis.
• Version verbergen ist Aufräumen, keine Sicherheit; Sicherheits-Header helfen dem Browser, Ihre Besucher zu schützen.
• Eine Firewall auf dem Server hält mehr auf als ein Plugin; Sicherheits-Plugins sind eine Ergänzung, kein Ersatz.

Quiz

Aufgabe

Aufgabe A7.4: Was zeigt Ihre Website jedem? Geben Sie die Adresse Ihrer Website ein. Das Programm liest die Startseite und den RSS-Feed (/feed/) und prüft: Steht keine WordPress-Version im Generator-Tag des HTML und des Feeds, zeigt der Header X-Powered-By keine PHP-Version, und sendet Ihre Website X-Content-Type-Options: nosniff, einen Schutz vor Frames (X-Frame-Options oder frame-ancestors) und eine Referrer-Policy? HSTS (Lektion 3.1) und Permissions-Policy dürfen fehlen (orange).

Aufgabe A7.4b: Keine Reste im Webverzeichnis. Weisen Sie nach, dass es Ihre eigene Website ist (TXT-Eintrag oder Datei mit dem Code der Aufgabe). Das Programm fragt danach eine kurze feste Liste ab: das Verzeichnis /wp-content/uploads/ (keine Verzeichnisauflistung), /.git/HEAD, /wp-content/debug.log und ein paar häufige Namen von Kopien von wp-config.php. Gut ist, wenn keiner davon Inhalt zurückgibt (404 oder 403). Das Programm probiert nichts anderes aus und ändert nichts.

Weiterführende Informationen

Diese Artikel beschreiben die Schritte in den Paneelen von WebOké; in anderen Paneelen funktionieren sie ähnlich.

• DirectAdmin Anleitung 11.5: Rechte für Dateien und Verzeichnisse (chmod)
• DirectAdmin Anleitung 11.4: Versteckte Dateien wie .htaccess anzeigen und bearbeiten
• DirectAdmin Anleitung 15.10: Web Application Firewall
• DirectAdmin Anleitung 15.11: Imunify360: Ihre Website auf Malware scannen
• Dateien per .htaccess sperren, z. B. plugin-googlemap2-proxy.php
• PHP-Sicherheit
• WordPress härten (developer.wordpress.org, Englisch): https://developer.wordpress.org/advanced-administration/security/hardening/
• Sicherheits-Header (MDN, Englisch): https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#security