Hoe wijzig ik de inlog-URL van WordPress en verberg ik wp-admin?

Waarom het ertoe doet

Elke WordPress-site ter wereld is bereikbaar op dezelfde twee adressen: /wp-login.php en /wp-admin. Bots weten dat. Ze hoeven je inlogpagina niet te zoeken; ze vragen hem gewoon op bij elke site die ze kunnen bereiken en beginnen wachtwoorden te raden.

Door de login naar een pad te verplaatsen dat alleen jij kent, haal je je site uit die massa. Geautomatiseerde raadscripts lopen tegen een 404 aan en gaan door naar de volgende. Je logs worden rustiger, je server heeft minder werk en de pogingen die overblijven zijn beter te volgen.

Wat dit niet doet. De login verbergen is een laag van verhulling. Het haalt het makkelijke doelwit weg, maar het sluit niets af. WordPress heeft nog andere deuren, vooral xmlrpc.php, dat zelfstandig gebruikersnamen en wachtwoorden accepteert. Een verborgen inlogpagina met een open XML-RPC-deur is als een verborgen voorpoort naast een zijpoort die niet op slot zit. Zie deze stap als de eerste van meerdere:

• beperk mislukte inlogpogingen,
• voeg tweefactorauthenticatie toe voor beheerders,
• sluit inloggen via XML-RPC en lekken van gebruikersnamen af,
• gebruik sterke, unieke wachtwoorden en hou WordPress up-to-date.

Veelgemaakte fouten

• Uitloggen voordat je hebt getest. Test het nieuwe pad altijd in een privévenster terwijl je hoofdtabblad nog is ingelogd. Klopt er iets niet, dan kun je het nog oplossen.
• De URL niet bewaren. "Dat onthoud ik wel" is de meest voorkomende oorzaak van buitensluiting. Zet hem in je wachtwoordmanager.
• Een voor de hand liggend pad kiezen. /login, /admin en /secure zijn het eerste wat bots proberen. Kies iets wat op zichzelf geen gangbaar woord is.
• De andere deuren vergeten. Staat inloggen via XML-RPC nog open, dan verhuist het wachtwoorden raden gewoon daarheen. Lees hoe je XML-RPC veilig uitschakelt.
• Het nieuwe pad cachen. Slaat een CDN of paginacache de inlogpagina op, dan kan het formulier stukgaan. Sluit het pad uit van caching, zoals je voor wp-login.php zou doen.

Zonder plugin

WordPress heeft geen instelling om de inlog-URL te wijzigen. De handmatige methoden zijn:

wp-login.php hernoemen. Sommige handleidingen raden aan wp-login.php naar een nieuwe bestandsnaam te kopiëren en alle verwijzingen erin te vervangen. Dat gaat stuk zodra WordPress update, want de update zet het originele bestand terug en je kopie raakt verouderd. Dat raden we af.

Het bestand op de server afschermen. Op Apache kun je wp-login.php in .htaccess beperken tot je eigen IP-adres:

<Files wp-login.php>
  Require ip 203.0.113.10
</Files>

Dat is degelijk als je altijd vanaf één vast adres werkt. Het sluit je buiten op de dag dat je IP verandert, en op Nginx- of LiteSpeed-servers helpt het niet zonder een bijpassende regel. Ook verbergt het de doorverwijzingen van wp-admin niet.

HTTP-basisauthenticatie gebruiken. Bij veel hosts kun je via het controlepaneel een wachtwoord op wp-login.php zetten. Dat werkt, maar het voegt voor iedereen een tweede inlogvenster toe, en het kan admin-ajax.php-aanroepen vanaf de voorkant breken als het te breed wordt toegepast.

Eerlijk samengevat: de handmatige routes gaan stuk bij updates of hangen af van een vast IP. Een plugin die het verzoek onderschept, is eenvoudiger en overleeft updates.

Als er iets misgaat

• Het nieuwe pad geeft een 404. Controleer het pad op typefouten, leeg daarna je paginacache en CDN-cache en probeer het opnieuw in een nieuw privévenster.

• Je bent buitengesloten. Voeg deze regel toe aan wp-config.php, boven "That's all, stop editing!":

  define( 'GATEKEEPER_LOGIN_SLUG', 'new-path' );
  

  Het inlogformulier opent direct op yoursite.com/new-path.

• Geen toegang tot wp-config.php? Verwijder de map hushfort-security uit /wp-content/plugins/ via FTP of het bestandsbeheer van je host. WordPress gaat terug naar de standaardlogin.

De volledige herstelgids vind je in Buitengesloten na het wijzigen van de inlog-URL.

Met Hushfort

De laag Login verbergen van Hushfort doet niets tot je een pad kiest, dus door hem aan te zetten kun je jezelf niet per ongeluk buitensluiten. Zodra je een pad instelt:

• geven wp-login.php en wp-admin een 404 (of sturen ze, als je dat liever hebt, door naar je homepage of een URL naar keuze);
• blijven admin-ajax.php, de REST API, WP-Cron en XML-RPC werken, zodat je thema en plugins zich gedragen zoals voorheen;
• toont het dashboard een kaart "Als je de toegang kwijtraakt" met je huidige inlog-URL en de noodregel;
• zet het deactiveren van de plugin WordPress terug naar de normale login.

Login verbergen zit in Hushfort Security, de gratis WordPress-beveiligingsplugin. Hushfort Pro voegt Inloglimieten, Tweefactor en Achterdeurslot voor XML-RPC toe, zodat de verborgen login één muur van meerdere is, niet de enige.