Wie man WPS Hide Login verwendet, um die WordPress-Admin-Seite zu schützen

Die Standard-WordPress-Login-URLs — yoursite.com/wp-admin und yoursite.com/wp-login.php — sind öffentlich bekannt und damit das erste Ziel bei automatisierten Brute-Force-Kampagnen und Credential-Stuffing-Angriffen. WPS Hide Login ist ein schlankes WordPress-Plugin, das diese vorhersehbaren Endpunkte durch eine benutzerdefinierte URL Ihrer Wahl ersetzt, sodass nicht authentifizierte Anfragen an die ursprünglichen Pfade still weitergeleitet werden, anstatt ein Anmeldeformular anzuzeigen.

Dieser Leitfaden behandelt die vollständige Installation, Konfiguration, das Wiederherstellungsverfahren und die mehrschichtige Sicherheitsstrategie für WPS Hide Login — einschließlich technischer Sonderfälle, die die meisten Anleitungen auslassen.

Warum das Ändern der Standard-Login-URL wichtig ist

Sicherheit durch Verschleierung ist für sich allein keine vollständige Verteidigung, aber sie ist eine legitime und messbare erste Schicht. Wenn Bots kein Anmeldeformular finden können, können sie auch keine Anmeldedaten dagegen einreichen. Studien aus Firewall-Protokollen auf Hosting-Ebene zeigen durchgängig, dass /wp-login.php und /wp-admin die überwiegende Mehrheit der WordPress-HTTP-403/429-Ereignisse ausmachen — oft Tausende von Anfragen pro Tag, selbst auf bescheidenen Websites.

Das Ändern der Login-URL beseitigt diese Angriffsfläche ohne Leistungskosten. In Kombination mit starken Passwörtern, Zwei-Faktor-Authentifizierung und einer Web Application Firewall erhöht es den erforderlichen Aufwand für einen erfolgreichen Einbruch erheblich.

Wenn Sie WordPress in einer VPS Hosting-Umgebung betreiben, können Sie dies auf Serverebene mit Nginx-deny-Direktiven oder Apache-.htaccess-Regeln zusätzlich zum Plugin verstärken — eine Kombination, die später in diesem Artikel behandelt wird.

Sicherheitsschichten: WPS Hide Login vs. alternative Ansätze

Bevor wir uns mit der Einrichtung befassen, ist es hilfreich zu verstehen, wo WPS Hide Login im Verhältnis zu anderen Härtungstechniken steht.

WPS Hide Login ist am effektivsten, wenn es mit mindestens einer der serverseitigen Kontrollen in dieser Tabelle kombiniert wird. Es ist kein Ersatz für starke Anmeldedaten oder eine WAF, beseitigt jedoch die leicht zugänglichen Angriffspunkte, auf die automatisierte Tools angewiesen sind.

Schritt 1: Das WPS Hide Login Plugin installieren

1. Melden Sie sich in Ihrem WordPress-Dashboard an.
2. Navigieren Sie zu Plugins > Neu hinzufügen.
3. Geben Sie im Suchfeld WPS Hide Login ein.
4. Klicken Sie auf Jetzt installieren neben dem Plugin, das von WPServeur, nofearinc und Beee veröffentlicht wurde.
5. Klicken Sie auf Aktivieren, sobald die Installation abgeschlossen ist.

Überprüfungstipp: Bestätigen Sie nach der Aktivierung, dass das Plugin unter Plugins > Installierte Plugins als aktiv aufgeführt ist. Das Plugin fügt in dieser Phase keine sichtbaren Frontend-Änderungen hinzu — die Konfiguration erfolgt ausschließlich im Einstellungsbereich.

Schritt 2: Das Plugin konfigurieren

Nach der Aktivierung fügt das Plugin seine Einstellungen am unteren Ende der Seite Einstellungen > Allgemein ein, anstatt einen eigenen Menüpunkt zu erstellen. Dies ist beabsichtigt — es hält die Konfiguration unauffällig.

1. Gehen Sie in Ihrem WordPress-Dashboard zu Einstellungen > Allgemein.
2. Scrollen Sie zum Abschnitt WPS Hide Login am unteren Ende der Seite.

Eine starke Login-URL wählen

Ersetzen Sie im Feld Login-URL den Standardwert durch einen benutzerdefinierten Pfad. Behandeln Sie diesen wie ein sekundäres Passwort: Er sollte nicht aus einem Wörterbuch stammen, nicht offensichtlich sein und nicht von Ihrem Markennamen abgeleitet werden.

Schwache Optionen, die Sie vermeiden sollten:

• /mylogin
• /admin-login
• /wp-login-new
• /login

Bessere Optionen:

• Eine zufällige alphanumerische Zeichenkette: /a7f3kx91
• Ein passphrasenartiger Pfad: /morning-circuit-deploy
• Ein Pfad, der eine legitime Seite imitiert: /resources/team-portal

Die URL unterscheidet auf Linux-basierten Servern zwischen Groß- und Kleinschreibung (was praktisch alle Dedicated Server und VPS-Instanzen unter Ubuntu oder CentOS umfasst). /MyLogin und /mylogin werden als unterschiedliche Pfade behandelt.

Die Weiterleitungs-URL konfigurieren

Das Feld Weiterleitungs-URL bestimmt, wohin Benutzer weitergeleitet werden, wenn sie versuchen, direkt auf /wp-login.php oder /wp-admin zuzugreifen. Wählen Sie dies bewusst:

• Zur Startseite weiterleiten (/): Neutral, gibt dem Angreifer keine Informationen preis.
• Zu einer benutzerdefinierten 404-Seite weiterleiten: Signalisiert, dass die Ressource nicht existiert, was technisch korrekt ist und weiteres Ausprobieren entmutigt.
• Zu einer Honeypot-Seite weiterleiten: Fortgeschrittene Technik — Weiterleitung zu einer Seite, die die IP-Adresse des Besuchers zur Analyse protokolliert.

Vermeiden Sie die Weiterleitung zu einer Seite mit einer sichtbaren „Zugriff verweigert”-Meldung, da dies einem Angreifer bestätigt, dass sich irgendwo auf der Website eine Login-Seite befindet.

1. Klicken Sie auf Änderungen speichern.

Schritt 3: Mit Ihrer neuen Login-URL anmelden

Nach dem Speichern werden die ursprünglichen Login-Endpunkte sofort deaktiviert. Jede Anfrage an /wp-login.php oder /wp-admin wird zur von Ihnen angegebenen URL weitergeleitet.

So greifen Sie auf Ihr Dashboard zu:

1. Navigieren Sie in Ihrem Browser zu https://yoursite.com/your-custom-path.
2. Geben Sie Ihre WordPress-Anmeldedaten wie gewohnt ein.
3. Das Dashboard lädt ohne sichtbaren Unterschied im Verhalten.

Wichtig: Die in WordPress integrierte Funktion „Passwort vergessen?” und die Benutzerregistrierungsabläufe verwenden intern ebenfalls /wp-login.php. WPS Hide Login behandelt diese korrekt, indem es die relevanten Formular-Action-URLs umschreibt — überprüfen Sie jedoch, ob dies in Ihrem spezifischen Theme- und Plugin-Stack funktioniert, bevor Sie es in der Produktion einsetzen.

Schritt 4: Die neue Login-URL sofort als Lesezeichen speichern

Dieser Schritt ist betrieblich entscheidend. Speichern Sie die neue URL als Lesezeichen in Ihrem Browser und hinterlegen Sie sie zusammen mit Ihren Anmeldedaten in Ihrem Passwort-Manager. Wenn Sie mehrere WordPress-Installationen verwalten, dokumentieren Sie die benutzerdefinierte URL in Ihrem internen Betriebshandbuch oder Secrets-Vault.

Verlassen Sie sich nicht auf Ihr Gedächtnis. Das Wiederherstellungsverfahren für eine vergessene benutzerdefinierte Login-URL erfordert Dateisystemzugriff, was in einer Produktionsumgebung störend ist.

Schritt 5: Alle Weiterleitungspfade testen

Das Testen sollte systematisch erfolgen. Öffnen Sie ein privates/Inkognito-Browserfenster (um zwischengespeicherte Sitzungsdaten zu vermeiden) und überprüfen Sie jedes der folgenden Elemente:

• https://yoursite.com/wp-login.php — sollte zur angegebenen URL weiterleiten, kein Anmeldeformular anzeigen.
• https://yoursite.com/wp-admin — sollte weiterleiten, kein Anmeldeformular oder Dashboard anzeigen.
• https://yoursite.com/wp-admin/admin-ajax.php — dieser Endpunkt muss weiterhin zugänglich sein; WPS Hide Login nimmt ihn korrekt von der Weiterleitung aus, um das Brechen von AJAX-abhängigen Plugins zu vermeiden.
• https://yoursite.com/your-custom-path — sollte das WordPress-Anmeldeformular korrekt anzeigen.
• Links zum Zurücksetzen des Passworts per E-Mail — lösen Sie ein Zurücksetzen des Passworts aus und bestätigen Sie, dass der Link in der E-Mail über Ihren benutzerdefinierten Login-Pfad und nicht über den ursprünglichen weitergeleitet wird.

Wenn admin-ajax.php blockiert ist, werden Sie fehlerhafte Frontend-Funktionen in Themes und Plugins sehen, die auf AJAX-Aufrufe angewiesen sind. Dies ist ein bekannter Sonderfall bei der Kombination von WPS Hide Login mit aggressivem Caching oder benutzerdefinierten Nginx-Regeln.

Schritt 6: Verstärkung auf Serverebene (empfohlen)

Fügen Sie für Umgebungen, in denen Sie Serverzugang haben, eine harte Blockierung auf der Webserver-Ebene hinzu, sodass die Standardpfade auch dann geschützt bleiben, wenn das Plugin deaktiviert wird.

Nginx — innerhalb Ihres server {}-Blocks hinzufügen:

location = /wp-login.php {
    return 301 https://yoursite.com/;
}

location ^~ /wp-admin/ {
    # Allow admin-ajax.php for front-end AJAX
    location = /wp-admin/admin-ajax.php {
        try_files $uri =404;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
    return 301 https://yoursite.com/;
}

Apache — zu Ihrer .htaccess-Datei oberhalb des WordPress-Rewrite-Blocks hinzufügen:

<FilesMatch "^wp-login.php$">
    Order Deny,Allow
    Deny from all
</FilesMatch>

Diese Regeln arbeiten unabhängig von WordPress und PHP, was bedeutet, dass sie Anfragen abfangen, bevor WordPress gestartet wird — ein bedeutender Leistungs- und Sicherheitsvorteil.

Schritt 7: Mit ergänzenden Sicherheits-Plugins kombinieren

WPS Hide Login befasst sich mit der URL-Auffindbarkeit. Es schützt nicht vor:

• Credential-Angriffen über den XML-RPC-Endpunkt (/xmlrpc.php)
• Schwachstellen in Themes oder Plugins
• Authentifizierten Angriffen von kompromittierten Konten

Kombinieren Sie es mit Folgendem:

• Limit Login Attempts Reloaded: Erzwingt Sperrrichtlinien nach einer konfigurierbaren Anzahl fehlgeschlagener Versuche. Funktioniert mit Ihrer benutzerdefinierten Login-URL, nicht nur mit der Standard-URL.
• Wordfence Security: Bietet eine Firewall im Lernmodus, einen Echtzeit-Bedrohungsintelligenz-Feed und Dateiintegritätsüberwachung. Das Zwei-Faktor-Authentifizierungsmodul ist besonders wertvoll.
• Disable XML-RPC: Wenn Sie die WordPress-Mobile-App oder Jetpack nicht verwenden, deaktivieren Sie /xmlrpc.php vollständig — es ist ein separater Brute-Force-Angriffsvektor, den WPS Hide Login nicht abdeckt.
• WP 2FA: Fügt zeitbasierte Einmalpasswort-Authentifizierung (TOTP) als zweiten Faktor hinzu, sodass gestohlene Anmeldedaten allein nicht für den Zugriff ausreichen.

Wenn Ihre Website auf einem Plan mit VPS mit cPanel gehostet wird, können Sie auch ModSecurity-Regeln auf Serverebene konfigurieren, um Login-Versuche unabhängig von WordPress-Plugins zu begrenzen.

So stellen Sie den Zugang wieder her, wenn Sie die benutzerdefinierte Login-URL vergessen haben

Dies ist das betrieblich heikelste Szenario. Wenn Sie die benutzerdefinierte Login-URL verlieren und nicht auf das Dashboard zugreifen können, muss das Plugin auf Dateisystemebene deaktiviert werden.

Methode 1: Dateimanager über das Hosting-Kontrollpanel

1. Melden Sie sich in Ihrem Hosting-Kontrollpanel an (cPanel, Plesk oder äquivalent).
2. Öffnen Sie den Dateimanager und navigieren Sie zu /wp-content/plugins/.
3. Benennen Sie den Ordner wps-hide-login in wps-hide-login-disabled um.
4. WordPress deaktiviert das Plugin automatisch, da der Ordnername nicht mehr übereinstimmt.
5. Greifen Sie über yoursite.com/wp-login.php auf Ihre Website zu — die Standard-URL ist jetzt wieder aktiv.
6. Melden Sie sich an, rufen Sie Ihre benutzerdefinierte URL-Konfiguration ab oder setzen Sie sie zurück, und benennen Sie den Ordner dann wieder in wps-hide-login um, um ihn zu reaktivieren.

Methode 2: FTP/SFTP-Zugang

# Connect via SFTP (replace with your actual credentials)
sftp user@yoursite.com

# Navigate to the plugins directory
cd /public_html/wp-content/plugins/

# Rename the plugin folder to deactivate it
rename wps-hide-login wps-hide-login-disabled

Methode 3: WP-CLI (falls auf Ihrem Server verfügbar)

Wenn Ihre Hosting-Umgebung WP-CLI unterstützt — üblich bei VPS Hosting und verwalteten Serverplänen — ist dies die schnellste Wiederherstellungsmethode:

# Deactivate the plugin from the command line
wp plugin deactivate wps-hide-login --path=/var/www/html

# Confirm it is deactivated
wp plugin list --path=/var/www/html

Nachdem Sie sich über die wiederhergestellte Standard-URL angemeldet haben, reaktivieren Sie das Plugin über das Dashboard und konfigurieren Sie Ihren benutzerdefinierten Pfad neu.

Methode 4: Direkte Datenbankbearbeitung

Als letzten Ausweg können Sie die gespeicherte Option des Plugins direkt in der Datenbank entfernen. Dies ist angemessen, wenn kein Dateisystemzugriff verfügbar ist, aber Datenbankzugriff (über phpMyAdmin oder MySQL CLI) besteht.

-- Remove WPS Hide Login configuration from wp_options
DELETE FROM wp_options WHERE option_name = 'whl_page';
DELETE FROM wp_options WHERE option_name = 'whl_redirect';

Nach der Ausführung dieser Abfragen kehrt das Plugin zum Standardverhalten zurück (keine URL-Verschleierung), auch wenn es technisch gesehen noch aktiv ist, sodass Sie sich über /wp-login.php anmelden können.

Mögliche Fallstricke und Sonderfälle

Caching-Konflikte: Vollseiten-Caching-Plugins (WP Rocket, W3 Total Cache, LiteSpeed Cache) können die Weiterleitungsantwort für die alte Login-URL zwischenspeichern. Leeren Sie nach der Konfiguration von WPS Hide Login alle Caches und überprüfen Sie, dass die Weiterleitung nicht aus dem Cache mit einem falschen Ziel bereitgestellt wird.

CDN- und Reverse-Proxy-Überlegungen: Wenn Ihre Website hinter Cloudflare oder einem anderen Reverse-Proxy sitzt, stellen Sie sicher, dass /wp-login.php und /wp-admin nicht auf CDN-Ebene zwischengespeichert werden. Diese Pfade sollten immer den Cache umgehen. Cloudflares Standard-Regel „Cache bei Cookie umgehen” behandelt dies für die meisten WordPress-Setups, aber überprüfen Sie es explizit.

Multisite-Installationen: WPS Hide Login hat eingeschränkte Kompatibilität mit WordPress-Multisite-Netzwerken. Bei subdomain-basiertem Multisite muss die Login-URL jeder Unterseite sorgfältig verwaltet werden. Testen Sie gründlich in einer Staging-Umgebung, bevor Sie es in einem Produktions-Multisite-Netzwerk einsetzen.

Plugin-Konflikte: Einige Mitgliedschafts-Plugins, E-Commerce-Plattformen (WooCommerces „Mein Konto”-Seite) und LMS-Plugins generieren ihre eigenen Anmeldeformulare, die direkt an /wp-login.php senden. Überprüfen Sie nach der Aktivierung von WPS Hide Login alle benutzerdefinierten Anmeldeformulare auf Ihrer Website, um sicherzustellen, dass ihre action-Attribute aktualisiert oder vom URL-Umschreiben des Plugins behandelt werden.

SSL-Anforderung: Führen Sie Ihre benutzerdefinierte Login-URL immer über HTTPS aus. Das Übermitteln von Anmeldedaten über HTTP setzt diese der Netzwerkabfangung aus, unabhängig davon, wie unbekannt die URL ist. Wenn Sie Ihre Website noch nicht gesichert haben, sind SSL-Zertifikate eine Voraussetzung — kein optionales Zusatzprodukt.

Technische Entscheidungs-Checkliste

Verwenden Sie diese Checkliste vor und nach dem Einsatz von WPS Hide Login in einer Produktionsumgebung:

• [ ] Benutzerdefinierte Login-URL ist nicht aus einem Wörterbuch, nicht markenabgeleitet und in einem Passwort-Manager gespeichert
• [ ] Weiterleitungs-URL für blockierte Pfade ist konfiguriert und in einem Inkognito-Fenster getestet
• [ ] admin-ajax.php bleibt zugänglich (mit einer AJAX-abhängigen Frontend-Funktion testen)
• [ ] Links zum Zurücksetzen des Passworts per E-Mail werden korrekt über den benutzerdefinierten Login-Pfad weitergeleitet
• [ ] Alle Vollseiten-Caches nach der Plugin-Aktivierung geleert
• [ ] CDN/Reverse-Proxy bestätigt, dass der Cache für login-bezogene Pfade umgangen wird
• [ ] Serverseitige Blockierung von /wp-login.php und /wp-admin als Defense-in-Depth-Schicht hinzugefügt
• [ ] XML-RPC-Endpunkt bewertet und deaktiviert, falls nicht erforderlich
• [ ] Ergänzende Plugins (Rate-Limiting, 2FA, WAF) aktiv und konfiguriert
• [ ] Wiederherstellungsverfahren dokumentiert und in einer Staging-Umgebung getestet
• [ ] SSL-Zertifikat aktiv und HTTPS siteübergreifend erzwungen

FAQ

Verhindert WPS Hide Login alle Brute-Force-Angriffe?

Nein. Es verhindert automatisierte Angriffe, die auf die bekannten Standard-Login-URLs abzielen. Wenn ein Angreifer Ihre benutzerdefinierte Login-URL entdeckt — durch Quellcode-Exposition, Server-Protokolle oder Social Engineering — können Brute-Force-Versuche wieder aufgenommen werden. Kombinieren Sie URL-Verschleierung immer mit Rate-Limiting und Zwei-Faktor-Authentifizierung.

Wird WPS Hide Login automatische WordPress-Updates oder Cron-Jobs unterbrechen?

Nein. WordPress-Core-Updates, Plugin-Updates und wp-cron.php verwenden /wp-login.php nicht zur Authentifizierung. Sie verwenden Nonces und Anwendungspasswörter oder direkte Dateiausführung. WPS Hide Login greift nicht in diese Prozesse ein.

Was passiert mit der Login-URL, wenn ich WPS Hide Login deaktiviere, ohne den Ordner umzubenennen?

Das Deaktivieren des Plugins über das WordPress-Dashboard stellt /wp-login.php und /wp-admin sofort als funktionsfähige Login-Endpunkte wieder her. Ihre benutzerdefinierte URL hört auf zu funktionieren. Dies ist reversibel — das Reaktivieren des Plugins stellt die benutzerdefinierte URL-Konfiguration wieder her.

Kann ich WPS Hide Login in einem WordPress-Multisite-Netzwerk verwenden?

Mit Vorsicht. Das Plugin funktioniert auf der primären Website des Netzwerks, hat jedoch inkonsistentes Verhalten auf Unterseiten, insbesondere bei Unterverzeichnis-Multisite-Konfigurationen. Testen Sie auf einem Staging-Klon Ihres Netzwerks, bevor Sie es einsetzen, und überprüfen Sie den GitHub-Issue-Tracker des Plugins auf bekannte Multisite-Konflikte mit Ihrer WordPress-Version.

Ist es sicher, die benutzerdefinierte Login-URL mit anderen Administratoren zu teilen?

Behandeln Sie die benutzerdefinierte Login-URL als sensible Anmeldeinformation. Teilen Sie sie nur über verschlüsselte Kanäle (die Freigabefunktion eines Passwort-Managers, eine verschlüsselte Messaging-App) und betten Sie sie niemals in Klartext-E-Mails oder Dokumentationen ein, die in öffentlich zugänglichen Repositories gespeichert sind.