WordPress-Adminbereich per IP-Freigabe oder HTTP-Authentifizierung zusätzlich schützen

Der Adminbereich einer WordPress-Website ist standardmäßig für jeden im Internet erreichbar. Wer die Anmeldeseite kennt, kann Passwörter durchprobieren oder auf Lücken in Admin-Seiten von Plugins zielen. Eine zweite Schutzschicht auf Ebene des Webservers stoppt solche Anfragen, bevor WordPress überhaupt geladen wird: entweder eine Freigabe nur für bestimmte IP-Adressen oder eine zusätzliche Passwortabfrage per HTTP-Authentifizierung. Die offizielle Hardening-Dokumentation von WordPress empfiehlt genau diesen Ansatz, warnt aber, dass ein unsauberer Schutz von /wp-admin/ Funktionen wie admin-ajax.php beschädigen kann. Diese Anleitung zeigt eine für Apache getestete Konfiguration, die den Adminbereich absichert und das Frontend weiter funktionieren lässt.

Voraussetzungen

• WordPress: aktuelle Version, getestet mit WordPress 7.1.2 und PHP 8.4.
• Webserver: Apache 2.4 mit erlaubten .htaccess-Dateien und den Modulen mod_auth_basic, mod_authn_file und mod_authz_host. Bei den meisten Webhosting-Tarifen mit Apache ist das der Fall. Für Nginx siehe Schritt 6.
• HTTPS: Pflicht. HTTP-Authentifizierung überträgt Benutzername und Passwort nur Base64-kodiert, ohne HTTPS also praktisch im Klartext.
• Dateizugriff: SFTP oder SSH, um .htaccess-Dateien anzulegen. Für htpasswd brauchen Sie SSH; viele Hoster bieten alternativ einen Verzeichnisschutz in der Verwaltungsoberfläche.
• Rolle: Administrator im WordPress-Backend.
• Backup: eine Kopie der vorhandenen .htaccess-Dateien. Ein Fehler in einer .htaccess führt zu Status 500 für die ganze Website.
• Feste IP-Adresse Ihres Büros, falls Sie nach IP freigeben wollen. Wechselnde Adressen von Privatanschlüssen eignen sich nicht.

Schritt 1: Methode wählen

Beide Verfahren haben Stärken und Grenzen. Die Tabelle hilft bei der Entscheidung.

Methode	Vorteil	Nachteil	Geeignet für
IP-Freigabe	Kein zusätzliches Passwort, Angreifer von außen erhalten sofort 403	Funktioniert nur mit festen IP-Adressen; unterwegs und im Homeoffice gesperrt	Büros mit fester IP und VPN
HTTP-Authentifizierung	Von überall nutzbar, unabhängig von der IP	Zweites Passwort, das verteilt und gepflegt werden muss	Verteilte Teams, Agenturen
Kombination mit RequireAny	Aus dem Büro ohne Abfrage, von außen mit Passwort	Etwas mehr Konfiguration	Die meisten Unternehmen

Diese Anleitung setzt die Kombination um. Wenn Sie nur eine Methode möchten, lassen Sie die jeweils andere Zeile weg. Den Schutz vor Brute-Force-Angriffen auf die Anmeldung ergänzt die Anleitung Brute-Force-Angriffe auf wp-login.php abwehren, die zusätzlich die Begrenzung von Anmeldeversuchen und XML-RPC behandelt.

Verifizieren: Sie haben sich für eine Methode entschieden und kennen gegebenenfalls die feste IP-Adresse Ihres Büros, etwa über die Anzeige Ihres Routers.

Schritt 2: Passwortdatei anlegen

Die Passwortdatei muss außerhalb des öffentlich erreichbaren Verzeichnisses liegen, sonst kann sie jeder herunterladen und offline angreifen. Der Webserver-Benutzer muss sie lesen können. Legen Sie sie mit dem Apache-Werkzeug htpasswd an; -c erzeugt eine neue Datei, -B speichert das Passwort als bcrypt-Hash:

mkdir -p /var/www/.auth
htpasswd -cB /var/www/.auth/.htpasswd-wp verwalter

Das Werkzeug fragt das Passwort zweimal ab und meldet „Adding password for user verwalter“. Für weitere Personen lassen Sie -c weg, da es die Datei sonst überschreibt. Legen Sie je Person ein eigenes Konto an, damit Sie beim Ausscheiden eines Mitarbeiters nur einen Eintrag entfernen müssen:

htpasswd -B /var/www/.auth/.htpasswd-wp mitarbeiterin
htpasswd -D /var/www/.auth/.htpasswd-wp ehemaliger

Den vollständigen Pfad benötigen Sie in Schritt 3. Beim Webhosting ohne SSH fragen Sie Ihren Hoster nach dem Pfad oberhalb des Webverzeichnisses oder nutzen den Verzeichnisschutz der Verwaltungsoberfläche.

Verifizieren: Die Datei enthält je Benutzer eine Zeile im Format name:$2y$… und liegt nicht unter dem Webverzeichnis.

Schritt 3: wp-admin mit Ausnahmen schützen

Legen Sie im Ordner wp-admin eine Datei .htaccess mit folgendem Inhalt an. Ersetzen Sie die Beispiel-IP und den Pfad:

AuthType Basic
AuthName "Verwaltung"
AuthUserFile /var/www/.auth/.htpasswd-wp
<RequireAny>
    Require ip 203.0.113.10
    Require valid-user
</RequireAny>

<FilesMatch "^(admin-ajax|admin-post|load-styles|load-scripts)\.php$">
    Require all granted
</FilesMatch>
<FilesMatch "\.(css|js)$">
    Require all granted
</FilesMatch>

Warum die Ausnahmen nötig sind: Viele Plugins schicken Anfragen von Besuchern an admin-ajax.php, etwa Kontaktformulare, Warenkörbe oder Filter. admin-post.php verarbeitet Formulare nicht angemeldeter Besucher. Die Anmeldeseite wp-login.php lädt ihre Stile über load-styles.php und Skripte aus wp-admin/js/. Im Labor lieferte load-styles.php ohne Ausnahme Status 403, das Apache-Log zeigte „AH01630: client denied by server configuration“. Ohne diese Ausnahmen würden Besucher ohne Server-Passwort Fehler oder eine unformatierte Anmeldeseite sehen.

<RequireAny> bedeutet, dass eine der beiden Bedingungen genügt. Mehrere IP-Adressen oder Netze trennen Sie mit Leerzeichen, etwa Require ip 203.0.113.10 198.51.100.0/24. Für reine IP-Freigabe ohne Passwort entfernen Sie die ersten drei Zeilen und die Zeile Require valid-user.

Verifizieren: Rufen Sie die Adressen von einem nicht freigegebenen Anschluss auf, etwa per Smartphone ohne WLAN. Im Labor ergab das:

/wp-admin/                        401
/wp-admin/options-general.php     401
/wp-admin/admin-ajax.php          400 (WordPress antwortet, fehlender Parameter)
/wp-admin/admin-post.php          200
/wp-admin/load-styles.php         200
/wp-admin/js/user-profile.min.js  200

Der Status 400 bei admin-ajax.php ist korrekt: Die Anfrage erreicht WordPress, nur fehlt der Parameter action.

Schritt 4: wp-login.php einbeziehen

Die Anmeldeseite liegt nicht in wp-admin, sondern im Hauptverzeichnis. Ohne weitere Regel bleibt sie erreichbar, im Labor mit Status 200. Ergänzen Sie in der Haupt-.htaccess ganz oben, außerhalb der Markierungen # BEGIN WordPress und # END WordPress, diesen Block. Die Hardening-Dokumentation weist darauf hin, dass WordPress alles zwischen diesen Markierungen überschreiben kann.

<Files "wp-login.php">
    AuthType Basic
    AuthName "Verwaltung"
    AuthUserFile /var/www/.auth/.htpasswd-wp
    <RequireAny>
        Require ip 203.0.113.10
        Require valid-user
    </RequireAny>
</Files>

Im Labor lieferte wp-login.php danach ohne Server-Passwort 401, mit Server-Passwort 200, die Startseite blieb bei 200. Eine vollständige Anmeldung mit Server-Passwort und anschließendem WordPress-Login führte zum Dashboard.

Bedenken Sie die Nebenwirkung: Auch Kunden oder Mitglieder, die sich über wp-login.php anmelden, etwa in Shops mit Kundenkonto oder Mitgliederbereichen, erhalten die zusätzliche Passwortabfrage. Nutzt Ihre Website solche Konten, schützen Sie nur wp-admin oder beschränken Sie den Schutz auf eine IP-Freigabe für Ihre Mitarbeiter und lassen Kunden einen anderen Anmeldeweg des Shop-Plugins nutzen.

Verifizieren: curl -I https://ihre-domain.de/wp-login.php liefert von außen 401 mit der Zeile WWW-Authenticate: Basic realm="Verwaltung", die Startseite liefert 200.

Schritt 5: Funktionen der Website prüfen

Testen Sie nach dem Einrichten alle Funktionen, die Besucher nutzen, von einem nicht freigegebenen Anschluss aus: Kontaktformular absenden, Artikel in den Warenkorb legen, Suche und Filter, Newsletter-Anmeldung, Kommentar schreiben. Prüfen Sie außerdem, ob externe Dienste auf wp-admin zugreifen, etwa Zahlungsanbieter mit Rückmeldungen oder Apps, die sich per REST-API verbinden. Die REST-API unter /wp-json/ und wp-cron.php liegen außerhalb von wp-admin und sind von der Regel nicht betroffen, im Labor antwortete /wp-json/ weiterhin mit 200.

Schlägt eine Funktion fehl, öffnen Sie in den Entwicklertools des Browsers den Reiter „Netzwerk“ und suchen nach Anfragen mit Status 401 oder 403. Ergänzen Sie die betroffene Datei in der <FilesMatch>-Liste aus Schritt 3.

Ein Serverschutz wie dieser ist keine einmalige Einstellung: Neue Plugins bringen neue Anfragen mit, IP-Adressen ändern sich, Mitarbeiter kommen und gehen. Wer diese Pflege nicht selbst im Kalender halten möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate.de übernimmt Einrichtung und Wartung einer Firewall sowie Updates von WordPress, Plugins und Themes mit Kompatibilitätsprüfung.

Verifizieren: Alle Besucherfunktionen arbeiten ohne Passwortabfrage, und im Apache-Fehlerprotokoll erscheinen keine neuen Einträge „AH01630“ für Dateien, die Besucher benötigen.

Schritt 6: Besonderheiten bei Proxy, CDN und Nginx

Reverse-Proxy oder CDN: Steht ein Proxy oder CDN vor dem Webserver, sieht Apache als Absender die Adresse des Proxys, nicht die des Besuchers. Eine IP-Freigabe würde dann entweder alle sperren oder alle durchlassen. Das Apache-Modul mod_remoteip übernimmt die echte Besucheradresse aus einem Header, muss aber in der Serverkonfiguration eingerichtet werden, nicht in der .htaccess. Nutzen Sie in diesem Fall ausschließlich HTTP-Authentifizierung, bis die Konfiguration geklärt ist. Diese Variante haben wir im Labor nicht getestet.

Nginx: Nginx liest keine .htaccess-Dateien. Die Entsprechungen sind die Direktiven allow und deny aus dem Modul ngx_http_access_module, auth_basic und auth_basic_user_file aus ngx_http_auth_basic_module sowie satisfy any aus dem Core-Modul als Gegenstück zu RequireAny. Die Ausnahmen für admin-ajax.php und die übrigen Dateien brauchen dort eigene location-Blöcke mit PHP-Weitergabe. Die Nginx-Variante haben wir nicht getestet; lassen Sie sie im Zweifel vom Hoster einrichten.

Verifizieren: Bei Proxy- oder Nginx-Betrieb liefert curl -I auf /wp-admin/ von außen 401 oder 403 und auf /wp-admin/admin-ajax.php 400.

Typische Fehler

• Status 500 für die ganze Website: Syntaxfehler in der .htaccess oder ein Modul fehlt. Datei per SFTP umbenennen, Fehlerprotokoll des Hosters lesen, korrigieren.
• Passwortabfrage erscheint, Anmeldung klappt nie: Der Pfad in AuthUserFile stimmt nicht oder der Webserver darf die Datei nicht lesen. Pfad absolut angeben und Leserechte prüfen.
• Anmeldeseite ohne Formatierung: load-styles.php oder CSS-Dateien sind gesperrt. Im Labor meldete Apache „AH01630: client denied by server configuration: /var/www/html/wp-admin/load-styles.php“. Ausnahmen aus Schritt 3 ergänzen.
• Kontaktformular oder Warenkorb funktionieren nicht: admin-ajax.php ist nicht ausgenommen und liefert 401. <FilesMatch>-Block prüfen.
• Aus dem Büro trotzdem gesperrt: Die IP-Adresse hat sich geändert oder ein Proxy verdeckt sie. Aktuelle Adresse prüfen oder auf Passwortschutz ausweichen.

Häufige Fragen

Ersetzt das die Zwei-Faktor-Anmeldung?

Nein. Die Serverabfrage hält automatisierte Angriffe fern, die Zwei-Faktor-Anmeldung schützt das einzelne Konto. Beides ergänzt sich, siehe WordPress-Login mit Zwei-Faktor-Authentifizierung absichern.

Merkt sich der Browser das Server-Passwort?

Ja, die meisten Browser speichern es bis zum Schließen oder im Passwortmanager. Das ist bequem, bedeutet aber auch, dass ein entsperrter Arbeitsrechner Zugang zur Abfrage hat.

Kann ich den Schutz schnell wieder entfernen?

Ja. Löschen oder benennen Sie wp-admin/.htaccess um und entfernen Sie den <Files "wp-login.php">-Block aus der Haupt-.htaccess. Die Änderung wirkt sofort.

Reicht es, die Anmeldeadresse per Plugin umzubenennen?

Das verringert automatisierte Anfragen, ist aber keine Zugangskontrolle. Wer die neue Adresse kennt, erreicht die Anmeldung wie zuvor.

Testumfang

Wir haben den Schutz unter WordPress 7.1.2 mit Apache durchgespielt, und die Anmeldung klappte mit Passwortabfrage, IP-Freigabe und beiden kombiniert bis ins Dashboard. Fehlt die Ausnahme, meldet Apache den Fehler AH01630.

Nginx, Server hinter einem Proxy sowie Shop- und Formular-Plugins haben wir nicht geprüft. Nutzen Sie so etwas, testen Sie die Regeln bitte zuerst auf einer Kopie Ihrer Website.

Fazit

Eine Serverabfrage vor wp-admin und wp-login.php hält einen Großteil automatisierter Angriffe fern, bevor WordPress Rechenzeit aufwendet. Entscheidend sind die Ausnahmen für admin-ajax.php, admin-post.php und die Stil- und Skriptdateien, sonst leidet das Frontend. Wenn Sie Firewall, Updates und Backups lieber dauerhaft betreuen lassen, übernimmt das die WordPress-Wartung von Marcel Schönfelder.

Weiterführende Anleitungen und Quellen

• Brute-Force-Angriffe auf wp-login.php abwehren
• WordPress-Login mit Zwei-Faktor-Authentifizierung absichern
• wp-config.php härten: Salts, Dateibearbeitung und Debug-Einstellungen
• WordPress Advanced Administration: Hardening WordPress
• Apache HTTP Server 2.4: Authentication and Authorization
• Apache HTTP Server 2.4: htpasswd
• nginx.org: ngx_http_auth_basic_module