Wp-login beschermen voor de feestdagen: praktische stappen die werken

De feestdagen komen eraan: is jouw wp-login klaar voor extra verkeer?

Rond Black Friday en de feestdagen stijgt het aantal bots dat WordPress-sites afspeurt. Je ziet het in je logs: honderden mislukte inlogpogingen op wp-login.php en verkeer naar xmlrpc.php. Het kost servercapaciteit en vergroot de kans op misbruik van zwakke of hergebruikte wachtwoorden. Het goede nieuws: met een paar concrete maatregelen is dit risico goed te beheersen, zonder dat je website onbruikbaar of traag wordt.

Dit artikel is een nuchter stappenplan om je WordPress-inlog af te schermen. Geen merkendiscussies, wel instellingen die je vandaag kunt uitvoeren en die morgen al effect hebben.

Waarom bots juist wp-login en xmlrpc raken

WordPress heeft logische, voorspelbare ingangen: wp-login.php voor inloggen en xmlrpc.php voor externe aanroepen. Dat maakt het voor geautomatiseerde aanvallen makkelijk om deze URL’s te bestoken. Ook als niemand binnenkomt, veroorzaken duizenden pogingen extra CPU- en I/O-belasting. Zeker bij gedeelde hosting kan dat je website merkbaar vertragen.

Beveiliging hier draait om twee dingen: misbruik voorkomen én het aantal nutteloze verzoeken minimaliseren. Je wilt dus zowel sterke authenticatie als slimmere toegang.

Stap 1: korte inventarisatie (10 minuten)

Begin met kijken, niet raden. Controleer:

• Recent aantal mislukte logins en naar welke gebruikersnaam geprobeerd is (vaak “admin”).
• Verzoeken naar xmlrpc.php en pieken in POST-verkeer.
• Of je al een rate limit, WAF of inlogbeperking actief hebt.

Deze snelle check geeft richting. Zie je vooral brute force? Dan helpt limitering en 2FA direct. Zie je veel xmlrpc-verkeer? Dan is uitschakelen of beperken de winstpakker.

Stap 2: zet 2FA aan voor beheerders (en liefst redacteuren)

Tweefactorauthenticatie voorkomt dat een gelekt of geraden wachtwoord genoeg is. Kies een plugin die TOTP (authenticator-app) en bij voorkeur ook passkeys (WebAuthn) ondersteunt. Richt dit zo in:

• Activeer 2FA voor rollen met beheertoegang (administrator, editor).
• Stel een korte overgangsperiode in waarin gebruikers 2FA móeten activeren.
• Maak back-upcodes en bewaar die offline.
• Test met een tweede admin-account voordat je het afdwingt.

Waarom dit werkt: de meeste geautomatiseerde aanvallen mikken op wachtwoorden. Met 2FA loopt zo’n poging vast, zelfs als het wachtwoord klopt.

Stap 3: beperk inlogpogingen en vertraag bots

Stel een limiet in op het aantal mislukte pogingen per IP en gebruikersnaam. Praktisch vertrekpunt:

• Maximaal 5 pogingen per 15 minuten, lockout 30 minuten.
• Verhoog de lockoutduur bij herhaling.
• Activeer “decoy” of “honeypot” waar beschikbaar om slechte clients sneller te blokkeren.

Heb je een WAF of CDN zoals Cloudflare, zet daar ook rate limiting op POST-verkeer naar /wp-login.php en /xmlrpc.php. Dit scheelt serverbelasting omdat verkeer eerder wordt gestopt.

Stap 4: zet een lichte extra drempel op het inlogscherm

Een captcha is geen vervanger van 2FA, maar het tempert botverkeer. Cloudflare Turnstile is daarbij prettig omdat het weinig frictie toevoegt. Voeg die toe aan het inlogformulier en bij voorkeur ook aan wachtwoord-vergeten. Dit haalt een deel van de ruis weg zonder je team lastig te vallen.

Stap 5: verander of bescherm de login-URL (als verkeersrem)

Het verplaatsen van de login-URL is geen echte beveiligingsmaatregel, maar het scheelt wel scanners die blind op /wp-login.php rammen. Gebruik dit als aanvullende stap om de hoeveelheid ruis te beperken. Test wel of je aanmeldlinks in je adminbar en eventuele SSO-koppelingen blijven werken.

Stap 6: schakel xmlrpc uit of beperk het streng

Gebruik je geen diensten die via xmlrpc werken (zoals sommige mobiele apps of Jetpack-functies)? Schakel dan xmlrpc.php helemaal uit. Heb je het nodig, beperk het dan met een allowlist of een extra challenge via je WAF. Dit is een van de meest effectieve manieren om volumeverkeer te drukken.

Stap 7: sterke wachtwoorden en, liever nog, passkeys

Verplicht lange wachtwoorden of passphrases van 14+ tekens voor beheerders. Beter nog: maak passkeys beschikbaar en stimuleer gebruik voor admin-accounts. Combineer dit met een wachtwoordmanager zodat je team geen varianten van “Welkom2024!” gaat verzinnen. Controleer ook:

• Geen account met gebruikersnaam “admin”.
• Verwijder oude of inactieve beheeraccounts.
• Beperk het aantal beheerders tot wat echt nodig is.

Stap 8: veilige mail voor notificaties en herstel

Zorg dat WordPress-mail betrouwbaar werkt, anders kun je geen wachtwoordherstel doen en mis je beveiligingsmeldingen. Gebruik voor SMTP óf OAuth-koppeling óf een applicatiewachtwoord. Sla nooit je primaire e-mailwachtwoord in een plugin op. Test direct:

• Wachtwoord-vergeten op een testaccount.
• Admin-notificaties bij lockouts of nieuwe logins.

Waarom dit telt: beveiliging faalt vaak op praktische dingen. Als herstelmail niet aankomt, kost een lockout onnodig tijd.

Stap 9: plan updates in een vast wekelijks venster

Zet automatische beveiligingsupdates aan en plan één vast moment per week voor plug-in en thema-updates. Kort, voorspelbaar en met een herstelpunt:

• Maak vóór updates een back-up.
• Werk eerst de staging-omgeving bij als je die hebt.
• Controleer na afloop logins en checkout (voor webshops).

Veel kwetsbaarheden worden misbruikt binnen dagen na publicatie. Een klein, vast ritme is vaak genoeg om voor te blijven.

Stap 10: monitoring en simpele regels in je WAF/CDN

Als je een CDN of WAF gebruikt, zet dan een paar gerichte regels:

• Challenge of rate limit voor POST naar /wp-login.php en /xmlrpc.php.
• Eventueel IP-allowlist voor /wp-admin/ als je vanaf een vast kantoor-IP werkt.
• Uitzondering voor admin-ajax.php zodat front-end functies (zoals zoek of winkelmandje) blijven werken.

Stel eenvoudige meldingen in: een alert bij een piek in 401/403/429-statuscodes of bij 5+ lockouts in 10 minuten. Het geeft vroegtijdig zicht op een aanval en op misconfiguraties.

Klein praktijkvoorbeeld

Stel: een kleine webshop ziet ’s avonds 2.000 verzoeken per uur naar wp-login.php. De site blijft online, maar wordt trager tijdens pieken. Door 2FA af te dwingen voor admins, rate limiting in te schakelen (5 pogingen per 15 minuten), Turnstile op het inlogformulier te zetten en xmlrpc.php uit te schakelen, zakt het loginverkeer met 90 tot 95 procent. De CPU-pieken verdwijnen en de site blijft vlot, ook tijdens de feestdagen.

Veelgemaakte valkuilen om te vermijden

• Alleen de login-URL verbergen en verder niets doen. Dat reduceert ruis, maar lost het risico niet op.
• Te agressieve blokkades zonder uitzonderingen, waardoor admin-ajax of PayPal/IPN-calls niet meer werken.
• Geen back-upcodes voor 2FA bewaren en jezelf buiten sluiten.
• SMTP instellen met je hoofdwachtwoord in een plugin. Gebruik applicatiewachtwoorden of OAuth.

Checklist: wat kun je vandaag doen (30 tot 60 minuten)

• Activeer 2FA voor beheerders en maak back-upcodes.
• Zet inloglimieten en voeg Turnstile of een lichte captcha toe.
• Schakel xmlrpc.php uit of beperk deze.
• Controleer admin-accounts, wachtwoordbeleid en verwijder oude accounts.
• Test e-mailherstel en admin-notificaties.

Samenvatting: rustig en robuust de feestdagen in

Wp-login beveiligen is geen groot project. Het zijn kleine, gerichte ingrepen die samen veel ruis en risico wegnemen: 2FA, inlogbeperkingen, xmlrpc indammen, nette mailinstellingen en een wekelijks update-ritme. Bij Rendar zien we dat vooral het combineren van deze maatregelen het verschil maakt: minder serverbelasting, minder meldingen en meer rust in beheer. We richten ons op risico’s die ook daadwerkelijk kunnen optreden en kiezen oplossingen die je team begrijpt en volhoudt.

Wil je dat iemand even meekijkt of je huidige instellingen logisch en toekomstbestendig zijn, of zoek je hulp bij het kiezen van een minimale set plugins en WAF-regels? Je kunt altijd even contact opnemen voor een korte, praktische review.

Begin klein: zet vandaag 2FA aan en een limiet op inlogpogingen. Een uur controle nu voorkomt dagen herstel later.