--- title: "WordPress-Adminbereich per IP-Freigabe oder HTTP-Authentifizierung zusätzlich schützen" date: 2026-09-30T21:20:15+02:00 modified: 2026-11-09T11:43:21+01:00 category: wordpress type: how_to author: Marcel Schönfelder canonical: https://s-edv.com/anleitungen/wordpress-adminbereich-ip-freigabe-http-auth-schuetzen keywords: - WordPress - Sicherheit - htaccess - Apache - Login reading_time: 8 --- # 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 Konfiguration für Apache, die den Adminbereich absichert und das Frontend weiter funktionieren lässt. **Kurzfassung:** Legen Sie mit `htpasswd -cB` eine Passwortdatei außerhalb des Webverzeichnisses an. In `wp-admin/.htaccess` verlangen Sie mit `` entweder eine freigegebene IP-Adresse oder ein gültiges Server-Passwort. Nehmen Sie `admin-ajax.php`, `admin-post.php`, `load-styles.php`, `load-scripts.php` sowie CSS- und JavaScript-Dateien per `` aus, sonst brechen Formulare, Warenkörbe und die Anmeldeseite. Schützen Sie `wp-login.php` mit derselben Regel in der Haupt-`.htaccess`. Prüfen Sie jede Adresse mit `curl` auf die erwarteten Statuscodes. ## Voraussetzungen - [ ] **WordPress:** aktuelle Version. - [ ] **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](https://s-edv.com/anleitungen/wordpress-brute-force-wp-login-xmlrpc-abwehren), die zusätzlich die Begrenzung von Anmeldeversuchen und XML-RPC behandelt. > **Prüfen:** 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: ```bash 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: ```bash 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. > **Prüfen:** 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: ```apache AuthType Basic AuthName "Verwaltung" AuthUserFile /var/www/.auth/.htpasswd-wp Require ip 203.0.113.10 Require valid-user Require all granted Require all granted ``` 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/`. Ohne Ausnahme liefert `load-styles.php` Status 403, das Apache-Log zeigt „AH01630: client denied by server configuration“. Ohne diese Ausnahmen würden Besucher ohne Server-Passwort Fehler oder eine unformatierte Anmeldeseite sehen. `` 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`. ```plaintext /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`. > **Prüfen:** Rufen Sie die Adressen von einem nicht freigegebenen Anschluss auf, etwa per Smartphone ohne WLAN. Das ergibt: ## Schritt 4: wp-login.php einbeziehen Die Anmeldeseite liegt nicht in `wp-admin`, sondern im Hauptverzeichnis. Ohne weitere Regel bleibt sie erreichbar, 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. ```apache AuthType Basic AuthName "Verwaltung" AuthUserFile /var/www/.auth/.htpasswd-wp Require ip 203.0.113.10 Require valid-user ``` Danach liefert `wp-login.php` ohne Server-Passwort 401, mit Server-Passwort 200, die Startseite bleibt bei 200. Eine vollständige Anmeldung mit Server-Passwort und anschließendem WordPress-Login führt 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. > **Prüfen:** `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; `/wp-json/` antwortet 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 ``-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](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=artikel&utm_campaign=39) übernimmt Einrichtung und Wartung einer Firewall sowie Updates von WordPress, Plugins und Themes mit Kompatibilitätsprüfung. > **Prüfen:** 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](https://httpd.apache.org/docs/2.4/mod/mod_remoteip.html) ü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. **Nginx:** Nginx liest keine `.htaccess`-Dateien. Die Entsprechungen sind die Direktiven `allow` und `deny` aus dem Modul [ngx_http_access_module](https://nginx.org/en/docs/http/ngx_http_access_module.html), `auth_basic` und `auth_basic_user_file` aus [ngx_http_auth_basic_module](https://nginx.org/en/docs/http/ngx_http_auth_basic_module.html) 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. Lassen Sie die nginx-Konfiguration im Zweifel vom Hoster einrichten. > **Prüfen:** 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. Apache meldet „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. ``-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](https://s-edv.com/anleitungen/wordpress-login-zwei-faktor-authentifizierung-einrichten). ### 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 ``-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. ## 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](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=fazit&utm_campaign=39). ## Weiterführende Anleitungen und Quellen - [Brute-Force-Angriffe auf wp-login.php abwehren](https://s-edv.com/anleitungen/wordpress-brute-force-wp-login-xmlrpc-abwehren) - [WordPress-Login mit Zwei-Faktor-Authentifizierung absichern](https://s-edv.com/anleitungen/wordpress-login-zwei-faktor-authentifizierung-einrichten) - [wp-config.php härten: Salts, Dateibearbeitung und Debug-Einstellungen](https://s-edv.com/anleitungen/wordpress-wp-config-haerten-salts-dateibearbeitung-debug) - [WordPress Advanced Administration: Hardening WordPress](https://developer.wordpress.org/advanced-administration/security/hardening/) - [Apache HTTP Server 2.4: Authentication and Authorization](https://httpd.apache.org/docs/2.4/howto/auth.html) - [Apache HTTP Server 2.4: htpasswd](https://httpd.apache.org/docs/2.4/programs/htpasswd.html) - [nginx.org: ngx_http_auth_basic_module](https://nginx.org/en/docs/http/ngx_http_auth_basic_module.html)