Bijna elke lijst met WordPress-beveiligingstips bevat hem: verplaats uw inlogpagina. In plaats van uwdomein.nl/wp-admin logt u dan in via uwdomein.nl/mijn-geheime-deur, en aanvallers vinden de pagina zogenaamd niet meer. Er zijn plugins die dit in twee minuten regelen, en veel ondernemers doen het omdat het zo makkelijk voelt.
Wij krijgen regelmatig de vraag of wij dit aanraden. Ons eerlijke antwoord: de WordPress-login verbergen is niet zinloos, maar het is ook lang niet zo nuttig als vaak wordt beweerd. In dit artikel leggen wij uit wat u er wél mee wint, waar het misgaat en waarom wij het pas op de vierde of vijfde plek zetten in een lijst met maatregelen.
Wat het wél oplevert
Laten we eerlijk zijn over het voordeel, want dat is er. Verreweg de meeste aanvallen op inlogpagina’s zijn geautomatiseerd en dom. Een programma werkt een lijst met domeinnamen af, gaat naar /wp-login.php en begint wachtwoorden te proberen. Staat de inlogpagina op een andere plek, dan krijgt dat programma een 404-pagina en gaat het naar het volgende domein.
Het gevolg is dat uw logboeken rustiger worden. In plaats van duizenden geblokkeerde pogingen per week ziet u er misschien tientallen. Dat scheelt serverkracht, het scheelt ruis in uw rapportages, en het scheelt onrust bij de ondernemer die dat rapport leest. Dat laatste is niet niets; wij hebben klanten die het vooral doen omdat het weekrapport dan niet meer zo alarmerend oogt.
Waarom de WordPress-login verbergen geen beveiliging is
Hier komt het standpunt. Het verplaatsen van de inlogpagina verandert niets aan hoe moeilijk het is om in te loggen. Het wachtwoord blijft even zwak of sterk, het account blijft even goed of slecht beschermd. U heeft het slot niet verbeterd; u heeft de deur achter een plant gezet.
En die plant is niet zo groot als hij lijkt. Een aanvaller die het specifiek op uw site heeft gemunt, vindt de nieuwe inlogpagina met weinig moeite:
- Veel thema’s en plugins bevatten links naar de inlogpagina, bijvoorbeeld in reactieformulieren of in de broncode van beveiligde pagina’s.
- Sommige plugins die de login verbergen, laten sporen achter in de broncode waaraan de nieuwe URL is te herleiden.
- De REST API van WordPress verraadt gebruikersnamen via het adres /wp-json/wp/v2/users, tenzij u dat afschermt. De inlogpagina is dan nog niet gevonden, maar de helft van het werk is al gedaan.
- Andere ingangen, zoals xmlrpc.php, blijven gewoon op hun plek staan en accepteren inloggegevens.
Kortom: tegen domme aanvallen helpt het, tegen gerichte aanvallen nauwelijks. En de aanvallen die daadwerkelijk slagen, komen zelden van het domme soort.
Waar het in de praktijk misgaat
Bij een deel van de klanten die met een verborgen inlogpagina bij ons komen, is het inmiddels een probleem geworden in plaats van een oplossing. Een paar situaties die wij vaker zien:
Niemand weet de URL meer. De medewerker die het instelde, is weg. De geheime URL staat nergens gedocumenteerd. De eigenaar kan niet meer in zijn eigen website. Het is op te lossen via de database of via FTP, maar het kost tijd en geld die niet nodig waren.
Plugins die de login verbergen, botsen met andere plugins. Sommige ledenplugins, webshopfuncties en koppelingen verwachten de inlogpagina op de standaardplek. Het gevolg is een omleidingslus of een leeg scherm na het inloggen, en dat uit zich pas na een update, maanden later.
Het geeft een vals gevoel van veiligheid. Dit is de belangrijkste. Wij spraken een boekhoudkantoor in Alkmaar dat de inlogpagina had verplaatst en daarom geen tweestapsverificatie nodig vond. Beheerderswachtwoord: de bedrijfsnaam plus “2020”. De inlogpagina was inderdaad verborgen. De gebruikersnaam stond in de auteurs-URL, het wachtwoord in een oud datalek. Dat de aanvaller de inlogpagina toch vond, was uiteindelijk het minst verrassende deel van het verhaal.
Wat u beter eerst regelt
Als u een middag heeft voor de beveiliging van uw inlogpagina, besteed die dan in deze volgorde:
- Sterke, unieke wachtwoorden voor elk account, opgeslagen in een wachtwoordmanager.
- Tweestapsverificatie voor iedereen met beheerdersrechten. Dit is de maatregel die een gelekt wachtwoord onschadelijk maakt.
- Een limiet op het aantal inlogpogingen per IP-adres.
- De gebruikersnaam “admin” vervangen; waarom dat belangrijk is, leest u in ons artikel over de gebruikersnaam admin.
- XML-RPC uitschakelen en de gebruikerslijst in de REST API afschermen.
Pas als dit alles staat, is de inlogpagina verplaatsen een aardige toevoeging. Het maakt uw logboeken rustiger en haalt de bulk van het domme verkeer weg. Documenteer de nieuwe URL dan wel op een plek waar meerdere mensen bij kunnen.
Hoe wij het zelf aanpakken
Bij de inrichting van structurele websitebeveiliging voor klanten kiezen wij meestal voor een andere route dan verbergen: de inlogpagina blijft op de standaardplek, maar wordt op serverniveau afgeschermd met een firewallregel die geautomatiseerde pogingen afremt en bekende aanvalsnetwerken weert. Daar bovenop komt tweestapsverificatie. Het resultaat is hetzelfde rustige logboek, zonder de risico’s van een vergeten URL of een botsende plugin. Wil een klant de login toch verplaatsen, dan doen wij dat, maar nooit als eerste stap.
Uiteindelijk gaat het erom hoe een aanvaller binnenkomt, en dat is bijna altijd via een zwak of gelekt wachtwoord of een verouderde plugin, niet via het vinden van de inlogpagina. Wie wil begrijpen wat er in die geblokkeerde pogingen precies gebeurt, kan ons artikel over een brute-force-aanval op de inlogpagina lezen.
Conclusie
Het verbergen van de inlogpagina is een cosmetische maatregel met een klein praktisch voordeel. Het is geen slot, het is een gordijn. Regel eerst de wachtwoorden, tweestapsverificatie en een limiet op inlogpogingen. Overweeg daarna pas of een andere inlog-URL voor u de moeite waard is, en schrijf die URL dan op een plek die u over drie jaar nog terugvindt.
