WordPress absichern - Login, .htaccess und 8G Firewall

WordPress-Installationen sind eines der häufigsten Ziele für automatisierte Angriffe im Netz. Die Login-Seite wp-login.php ist unter einer vorhersehbaren URL erreichbar, der Standard-Benutzername "admin" ist oft noch aktiv, und Brute-Force-Scripts testen rund um die Uhr Passwortkombinationen. Die gute Nachricht: Mit ein paar Zeilen in der .htaccess lässt sich das Risiko drastisch reduzieren - ganz ohne Plugin.

Dieser Artikel zeigt die wichtigsten Massnahmen zum Absichern einer WordPress-Installation: vom htpasswd-Schutz des Logins über das Blockieren von XML-RPC bis zur 8G Firewall von Perishable Press. Alle Massnahmen sind mit fertigen Code-Beispielen zum Kopieren versehen.

wp-login.php per htpasswd schützen

Die wirksamste Einzelmassnahme gegen Brute-Force-Angriffe: Die Login-Seite mit einem zusätzlichen Passwortschutz auf Server-Ebene versehen. Der Angreifer muss dann zuerst den htpasswd-Dialog überwinden, bevor er überhaupt das WordPress-Loginformular sieht. Automatisierte Scripts scheitern an dieser Hürde sofort.

Füge diesen Code in die .htaccess im WordPress-Hauptverzeichnis ein:

<Files wp-login.php>
    AuthType Basic
    AuthName "WordPress Login"
    AuthUserFile /www/htdocs/w012345/.htpasswd
    Require valid-user
</Files>

Ersetze den Pfad durch den absoluten Server-Pfad zu deiner .htpasswd-Datei. Wie du die .htpasswd erstellst und den Server-Pfad herausfindest, erklärt der Artikel htpasswd Generator und Verzeichnisschutz.

Wichtig: Nur wp-login.php schützen, nicht das ganze wp-admin-Verzeichnis. Wenn du stattdessen das gesamte /wp-admin/ per htpasswd absicherst, funktionieren AJAX-Aufrufe im Frontend nicht mehr korrekt. Plugins und Themes, die admin-ajax.php nutzen, bekommen dann einen 401-Fehler. Der Schutz der wp-login.php allein reicht aus - dort findet der Login statt.

XML-RPC blockieren

Die Datei xmlrpc.php ist die XML-RPC-Schnittstelle von WordPress. Sie ermöglicht es, von aussen Beiträge zu veröffentlichen, Kommentare zu verwalten und Pingbacks zu senden. In der Praxis wird sie von den meisten WordPress-Seiten nicht gebraucht, ist aber ein beliebtes Angriffsziel. Über XML-RPC lassen sich Brute-Force-Angriffe besonders effizient durchführen, weil pro Anfrage mehrere Passwörter gleichzeitig getestet werden können (sogenanntes "Multicall").

<Files xmlrpc.php>
    Order Deny,Allow
    Deny from all
</Files>

Wer braucht XML-RPC? Wenn du die WordPress-App auf dem Smartphone nutzt, Jetpack verwendest oder extern Beiträge per API veröffentlichst, brauchst du xmlrpc.php. In allen anderen Fällen kannst du die Datei bedenkenlos blockieren. Die REST-API (seit WordPress 4.7) ersetzt XML-RPC für die meisten Anwendungsfälle.

wp-config.php absichern

Die wp-config.php enthält die Datenbank-Zugangsdaten, die Sicherheitsschlüssel (Salts) und die WordPress-Konfiguration. Wenn ein Angreifer diese Datei lesen kann, hat er vollen Zugriff auf die Datenbank. Normalerweise verhindert PHP, dass die Datei im Browser angezeigt wird - aber bei einer Fehlkonfiguration oder einem PHP-Fehler könnte der Quelltext sichtbar werden.

<Files wp-config.php>
    Order Allow,Deny
    Deny from all
</Files>

Diese Regel blockiert jeden direkten HTTP-Zugriff auf die Datei. WordPress selbst liest die wp-config.php über das Dateisystem, nicht über HTTP - die Regel hat also keine Auswirkung auf die Funktion.

Sicherheits-Header setzen

HTTP-Sicherheits-Header weisen den Browser an, bestimmte Angriffsvektoren zu blockieren. Sie schützen vor Clickjacking, Cross-Site-Scripting (XSS) und MIME-Type-Sniffing. Die folgenden Header gehören in jede WordPress-.htaccess:

# Sicherheits-Header
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-XSS-Protection "1; mode=block"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "geolocation=(), camera=(), microphone=()"

X-Frame-Options SAMEORIGIN verhindert, dass deine Seite in einem iframe auf einer fremden Domain eingebettet wird - das stoppt Clickjacking-Angriffe. X-Content-Type-Options nosniff verhindert, dass der Browser den MIME-Type einer Datei rät und dabei möglicherweise Schadcode ausführt. Der Referrer-Policy-Header schränkt ein, welche Informationen beim Klick auf einen Link an die Zielseite weitergegeben werden.

Weitere .htaccess-Massnahmen

Verzeichnislisting deaktivieren

Options -Indexes

Ohne diese Zeile zeigt Apache den Inhalt eines Verzeichnisses an, wenn keine index.php vorhanden ist. Bei WordPress betrifft das vor allem /wp-content/uploads/ - dort sieht ein Angreifer sonst alle hochgeladenen Dateien.

Sensible Dateien blockieren

<FilesMatch "(\.env|\.git|\.htpasswd|readme\.html|license\.txt)$">
    Require all denied
</FilesMatch>

Die readme.html und license.txt verraten die WordPress-Version. Die .env-Datei kommt bei manchen Setups vor und kann Zugangsdaten enthalten. Diese Dateien braucht kein Besucher.

PHP-Ausführung in /uploads/ verhindern

# In /wp-content/uploads/.htaccess
<Files "*.php">
    Require all denied
</Files>

Diese Regel gehört in eine separate .htaccess im Verzeichnis /wp-content/uploads/. Sie verhindert, dass hochgeladene PHP-Dateien ausgeführt werden. Das ist eine der häufigsten Angriffsmethoden: Ein Angreifer lädt über eine Sicherheitslücke in einem Plugin eine PHP-Datei hoch und führt sie dann über den Browser aus.

8G Firewall für WordPress

Die 8G Firewall von Jeff Starr (Perishable Press) ist ein umfangreicher Satz von .htaccess-Regeln, der bösartige Anfragen auf Server-Ebene blockiert - noch bevor WordPress oder PHP geladen werden. Die Firewall filtert verdächtige Query-Strings, Request-URIs, User-Agents und Referrer und blockiert bekannte Angriffsmuster wie SQL-Injection, Cross-Site-Scripting und Path-Traversal.

Die 8G ist der Nachfolger der 7G Firewall und wird seit Jahren aktiv weiterentwickelt. Sie arbeitet rein auf Apache-Ebene über mod_rewrite und mod_alias, braucht kein PHP und verursacht keinen messbaren Performance-Overhead. Im Gegenteil: Da bösartige Anfragen schon vom Webserver abgefangen werden, wird WordPress gar nicht erst aufgerufen - das spart Server-Ressourcen.

8G Firewall einrichten

Die vollständigen Regeln findest du auf der offiziellen 8G-Seite bei Perishable Press. Kopiere den Code und füge ihn am Anfang deiner .htaccess ein, vor den WordPress-Regeln. Hier ein Auszug der wichtigsten Muster:

# 8G Firewall (Auszug) - vollständig unter perishablepress.com/8g-firewall/
RewriteEngine On

# Bad Query Strings
RewriteCond %{QUERY_STRING} (eval\() [NC,OR]
RewriteCond %{QUERY_STRING} (base64_encode|base64_decode) [NC,OR]
RewriteCond %{QUERY_STRING} (<script) [NC,OR]
RewriteCond %{QUERY_STRING} (javascript:) [NC,OR]
RewriteCond %{QUERY_STRING} (document\.cookie) [NC]
RewriteRule .* - [F,L]

Die 8G Firewall ist modular aufgebaut. Wenn eine Regel bei dir Probleme verursacht (etwa weil ein Plugin bestimmte Query-Strings nutzt), kannst du einzelne Zeilen auskommentieren, ohne die restlichen Regeln zu beeinträchtigen. Jeff Starr dokumentiert auf seiner Website regelmässig, welche Regeln bei bestimmten Plugins oder Themes angepasst werden müssen.

8G Firewall als Plugin. Wer die Regeln nicht manuell in die .htaccess einfügen möchte, kann Jeff Starrs Plugin BBQ Firewall (Block Bad Queries) verwenden. Es setzt die gleichen Filter auf PHP-Ebene um. Die .htaccess-Variante ist schneller, das Plugin ist einfacher zu installieren.

WordPress-Plugins zur Absicherung

Die .htaccess-Massnahmen schützen auf Server-Ebene. Zusätzlich gibt es WordPress-Plugins, die den Schutz auf Anwendungsebene erweitern.

Admin and Site Enhancements (ASE)

Das Plugin Admin and Site Enhancements (ASE) ist ein Schweizer Taschenmesser für WordPress-Administratoren. Es ersetzt eine ganze Reihe einzelner Plugins durch ein einziges: Login-Limit, Login-URL ändern, XML-RPC deaktivieren, Heartbeat-API steuern, Admin-Oberfläche aufräumen und vieles mehr. Über 50 Funktionen in einem Plugin, modular aktivierbar. Besonders praktisch: Die Login-Sicherheit (Limit Login Attempts, Passwort-Stärke erzwingen, Login-Seite umbenennen) ist direkt integriert - kein zusätzliches Plugin nötig.

ASE ist leichtgewichtig, weil nur aktivierte Module geladen werden. Im Vergleich zu Wordfence verbraucht es deutlich weniger Ressourcen und ist eine gute Wahl für Seiten, die keine vollständige WAF brauchen, aber trotzdem die wichtigsten Sicherheitsfunktionen abdecken wollen.

Admin and Site Enhancements - Login-Limit mit fehlgeschlagenen Anmeldeversuchen — ASE Plugin: Die Login-Limit-Funktion zeigt fehlgeschlagene Anmeldeversuche mit IP-Adresse und Benutzername

Wordfence

Das bekannteste WordPress-Sicherheits-Plugin. Wordfence bietet eine Web Application Firewall (WAF), Malware-Scanner, Brute-Force-Schutz und Login-Überwachung. Die kostenlose Version ist für die meisten Seiten ausreichend. Der Nachteil: Wordfence ist ressourcenintensiv und kann auf Shared-Hosting-Servern die Performance beeinträchtigen.

Limit Login Attempts Reloaded

Ein schlankes Plugin, das nach einer einstellbaren Anzahl fehlgeschlagener Login-Versuche die IP des Angreifers für eine konfigurierbare Zeit sperrt. Leichtgewichtiger als Wordfence und für viele Seiten ausreichend. Wer ASE nutzt, braucht dieses Plugin nicht - die Funktion ist dort bereits enthalten. Wenn du dich selbst aussperrst, warte einfach die eingestellte Sperrzeit ab oder lösche den Eintrag in der Datenbank:

UPDATE wp_options SET option_value = '' WHERE option_name = 'limit_login_lockouts';

Checkliste: WordPress absichern

Massnahme	Ebene	Aufwand
wp-login.php per htpasswd schützen	Server	5 Minuten
XML-RPC blockieren	Server	1 Minute
wp-config.php sperren	Server	1 Minute
Sicherheits-Header setzen	Server	2 Minuten
Options -Indexes	Server	10 Sekunden
PHP in /uploads/ verhindern	Server	2 Minuten
8G Firewall einrichten	Server	10 Minuten
Sichere Passwörter verwenden	Benutzer	Sofort
"admin" als Benutzernamen vermeiden	WordPress	Sofort
WordPress, Themes und Plugins aktuell halten	WordPress	Regelmässig

Häufige Fragen

Reicht ein Sicherheits-Plugin oder brauche ich auch die .htaccess-Regeln?

Beides zusammen ist am sichersten. Die .htaccess-Regeln greifen auf Server-Ebene, noch bevor WordPress geladen wird. Das spart Ressourcen und stoppt Angriffe früher. Ein Plugin wie Wordfence ergänzt das um Funktionen wie Malware-Scanning und Login-Überwachung, die auf Server-Ebene nicht möglich sind.

Meine Seite ist klein - brauche ich das überhaupt?

Ja. Brute-Force-Angriffe auf WordPress laufen automatisiert und treffen jede Installation, egal wie gross oder klein. Die Bots suchen nicht gezielt nach wichtigen Seiten, sondern scannen systematisch das gesamte Internet nach WordPress-Installationen.

Kann ich mich durch den htpasswd-Schutz selbst aussperren?

Wenn du Benutzername oder Passwort der htpasswd vergisst, kannst du die .htaccess per FTP bearbeiten und die AuthType-Zeilen entfernen oder auskommentieren. Der Zugang ist sofort wieder frei.

Was mache ich, wenn die 8G Firewall mein Plugin blockiert?

Kommentiere die problematische Regel in der .htaccess aus (mit # am Zeilenanfang). Die 8G ist modular aufgebaut - einzelne Regeln können deaktiviert werden, ohne den Rest zu beeinträchtigen. Auf perishablepress.com gibt es eine FAQ mit bekannten Kompatibilitätsproblemen.