Magento admin brute force: helpt een custom admin-URL echt?

Een eigen admin-URL stopt geen aanvaller, hij filtert alleen de bots. Wat wel werkt: lockout, 2FA en de admin buiten bereik van de wereld.

Elke Magento-beheerder kent het advies: verander /admin naar iets anders. Het is gratis, het kost vijf minuten en het voelt als beveiliging. Maar helpt het echt tegen brute force? Het eerlijke antwoord is: een beetje, en niet waar het ertoe doet.

Wat is brute force op de admin?

Bij brute force probeert een aanvaller veel wachtwoorden na elkaar. Dat kan op twee manieren:

• Klassieke brute force. Één account, duizenden wachtwoorden.
• Credential stuffing. Combinaties van gebruikersnaam en wachtwoord uit andere lekken, in de hoop dat iemand ze hergebruikt. Dit is veel gevaarlijker, want de wachtwoorden zijn echt.

Voor klantaccounts schreven we daar apart over, in credential stuffing op klantaccounts. Hier gaat het om de admin.

Het doel is meestal een admin-account. Met een admin kan een aanvaller code in je CMS zetten, een betaalmodule aanpassen of een skimmer plaatsen. Het admin-paneel is daarmee een van de meest waardevolle doelen van je shop.

Security through obscurity: wat een custom URL wel en niet doet

Een custom admin-URL verbergt de ingang. Dat is security through obscurity: het werkt zolang niemand de URL kent.

• Het houdt geautomatiseerde bots weg die blind /admin proberen.
• Het vermindert ruis in je logs. Je ziet minder mislukte logins.
• Het kost je bijna niets.

• Het stopt geen gerichte aanvaller. Admin-URL's lekken uit: via oude documentatie, een sitemap, een screenshot, een e-mail met een link, een browsergeschiedenis of een foutmelding.
• Het beschermt niet tegen gestolen wachtwoorden. Wie de URL en het wachtwoord heeft, komt binnen.
• Het beschermt niet tegen kwetsbaarheden die geen admin-login nodig hebben. Een lek als SessionReaper heeft niets met je admin-pad te maken.

Zie het als een slot dat je op de brievenbus zet, terwijl de voordeur openstaat. Niet slecht, wel niet de hoofdzaak.

Hoe stel je een custom admin-URL in?

Als je het toch doet, doe het dan goed. De waarde staat in app/etc/env.php onder backend en frontName. Je past hem aan met de CLI:

bin/magento setup:config:set --backend-frontname="kies-iets-onvoorspelbaars"
bin/magento cache:flush

Wat telt:

• Kies niets raadbaars zoals beheer, backend, manage of de naam van je bedrijf.
• Zet de waarde niet in documentatie, tickets of chats die breed gedeeld worden.
• Geef het door aan mensen die het nodig hebben, via een wachtwoordmanager.
• Controleer na de wijziging of de oude URL niet meer werkt, en of integraties of bookmarks niet breken.

Gebruik het als extra laag, nooit als enige laag.

Wat werkt wel: de lagen op een rij

Een goede verdediging heeft meerdere lagen. Als één laag faalt, houdt een andere stand.

1. 2FA

Magento heeft sinds 2.4.0 standaard 2FA op de admin. Dit is verreweg de belangrijkste maatregel tegen gestolen of geraden wachtwoorden. Zonder tweede factor is een gelekt wachtwoord genoeg.

Zorg dat:

• 2FA aan staat voor iedereen, ook voor het bureau en freelancers.
• Je een app-gebaseerde methode of hardware key gebruikt, niet alleen een methode die je kunt onderscheppen.
• Je herstelprocedure is geregeld, zodat niemand 2FA uitzet "omdat het lastig is".

Details en rollen staan in Magento admin beveiligen.

2. Lockout-instellingen

Magento kan accounts tijdelijk blokkeren na mislukte pogingen. Je vindt de instellingen in de admin onder Stores, Configuration, Advanced, Admin, onder het kopje Security. Kijk daar naar:

• het maximale aantal mislukte inlogpogingen voordat een account wordt geblokkeerd;
• de duur van de blokkade;
• of de secret key aan staat voor admin-URL's.

Controleer de waarden in je eigen installatie en kies ze niet te soepel. Een lage drempel stopt klassieke brute force vrijwel direct.

Let op de keerzijde: lockout kan misbruikt worden om een legitieme gebruiker buiten te sluiten. Dat is een kleine overlast vergeleken met een overgenomen admin, maar houd er rekening mee.

Lockout werkt per account. Een aanvaller die één wachtwoord probeert op duizend accounts, zit er vaak onder. Dat is waarom je meer lagen nodig hebt.

3. IP-allowlist of VPN

De sterkste maatregel tegen brute force is dat de aanvaller de loginpagina niet eens kan bereiken. Beperk /admin tot bekende IP-adressen of tot een VPN.

Een voorbeeld in nginx:

location /kies-iets-onvoorspelbaars/ {
    allow 203.0.113.10;   # kantoor
    allow 203.0.113.11;   # VPN-uitgang
    deny all;

    try_files $uri $uri/ /index.php$is_args$args;
}

Gebruik je eigen IP-adressen en pas het pad aan. Test goed: de beperking moet ook gelden voor de admin-gerelateerde routes, en je moet zelf niet buitengesloten raken. Draai je achter een CDN of reverse proxy, zorg dan dat nginx het echte client-IP ziet. Anders beoordeel je het IP van de proxy.

Is een allowlist praktisch? Voor een team met een vast kantoor of VPN: ja. Voor mensen die overal werken: een VPN met een vast uitgangs-IP is dan de oplossing. Hosting met zo'n optie kan dit vereenvoudigen. Zie ook /magento/hosting.

4. WAF en rate limiting

Een web application firewall kan verdachte login-pogingen herkennen en afknijpen, ook als ze over veel IP-adressen verspreid zijn. Regels die we vaak inzetten:

• Rate limiting op het admin-login-pad.
• Een challenge (bijvoorbeeld een captcha-achtige controle) bij verdacht gedrag.
• Blokkeren van bekende kwaadaardige bronnen en bots.

Hoe je zoiets opzet lees je in WAF en bot-bescherming en in het Cloudflare Pro-stappenplan. Een WAF vervangt 2FA niet, hij vermindert de aanvalsdruk.

5. Sterke wachtwoorden en een wachtwoordmanager

Hergebruikte wachtwoorden zijn de reden dat credential stuffing werkt. Eis unieke wachtwoorden per persoon, in een wachtwoordmanager. Deel nooit één admin-account. Eén account per persoon betekent dat je kunt zien wie wat deed, en dat je iemand direct kunt uitsluiten.

6. Monitoring van mislukte logins

Je kunt een aanval alleen stoppen als je hem ziet. Let op:

• Pieken in mislukte admin-logins.
• Logins van onbekende landen of op vreemde tijdstippen.
• Een succesvolle login direct na veel mislukte pogingen. Dat is het signaal dat het misgegaan kan zijn.
• Nieuwe admin-accounts, wijzigingen in rollen of in configuratie.

Het hoeft niet duur te zijn. Een melding bij een nieuwe admin-gebruiker en een dagelijks overzicht van mislukte logins pakken al veel. Zie security logging voor webshops.

Vergelijking van maatregelen

Je ziet dat alleen 2FA en toegangsbeperking het probleem van een gelekt wachtwoord oplossen. Daar begin je mee.

Wat wij aanraden, in volgorde

1. Zet 2FA aan en houd het aan, voor iedereen.
2. Beperk de admin tot een IP-allowlist of VPN waar dat kan.
3. Stel lockout in op strakke waarden.
4. Zet een WAF met rate limiting voor de admin.
5. Monitor mislukte logins en nieuwe admin-gebruikers.
6. Verander de admin-URL als laatste, als kleine extra stap.

Een custom URL kost weinig en mag gewoon op de lijst staan, zolang je niet denkt dat je daarmee klaar bent. Heb je de eerste vijf op orde, dan is de URL vrijwel bijzaak.

Wanneer is dit overkill?

Een kleine shop met twee beheerders hoeft geen VPN-infrastructuur. 2FA, lockout en sterke wachtwoorden dekken dan al een groot deel. Voeg een IP-allowlist toe zodra het team groter wordt, er externe partijen toegang hebben, of een inbraak veel schade zou doen. Heb je een uitgebreide checklist nodig, dan staat die in ons artikel over de Magento 2 security-checklist.

Veelgestelde vragen

Is een custom admin-URL in Magento nuttig?

Een beetje. Het houdt bots weg die blind /admin proberen en vermindert ruis in je logs. Het stopt geen gerichte aanvaller en beschermt niet tegen een gelekt wachtwoord. Zie het als extra laag, niet als vervanging van 2FA.

Waar stel ik de admin-URL in?

De waarde staat in app/etc/env.php onder backend en frontName. Je past hem aan met bin/magento setup:config:set --backend-frontname="...". Leeg daarna de cache en controleer of alles nog werkt.

Welke maatregel helpt het meest tegen brute force?

2FA in combinatie met toegangsbeperking. 2FA maakt een geraden of gelekt wachtwoord onbruikbaar. Een IP-allowlist of VPN zorgt dat aanvallers de loginpagina niet bereiken.

Hoe zie ik of iemand mijn admin probeert te kraken?

Controleer de webserverlogs en het admin-actiepatroon op veel mislukte logins, onbekende IP-adressen en nieuwe admin-gebruikers. Een succesvolle login na een reeks mislukte pogingen is het belangrijkste alarmsignaal.

Moet ik mijn admin achter een VPN zetten?

Niet altijd, maar het is een van de sterkste maatregelen. Voor shops met veel omzet, externe beheerders of kaartverwerking in de eigen checkout is het sterk aan te raden.

Wil je dat iemand je admin-beveiliging doorloopt en afstelt? Neem contact op of lees meer op /security/magento.