Brute force aanval voorkomen WordPress in 7 stappen

Open de access-logs van een willekeurige WordPress-site die een paar weken online staat zonder beveiliging. Negen van de tien keer zie je honderden, soms duizenden POST-verzoeken naar wp-login.php of xmlrpc.php, vanuit IP-adressen verspreid over de hele wereld. Geen menselijke aanvallers. Botnets die elke dag het hele internet aflopen op zoek naar gokbare combinaties.

Brute force aanval voorkomen WordPress is geen ingewikkeld onderwerp. Het is een rij maatregelen die elk afzonderlijk klein lijken, maar samen de aanvalsroute vrijwel volledig dichtzetten. Geen exotische tools nodig. Geen dure abonnementen. Wel discipline.

Dit artikel beschrijft zeven stappen waarmee je het bot-verkeer wegfilter en de kans op een geslaagde aanval naar vrijwel nul terugbrengt. WordPress is mijn dagelijkse omgeving, maar de principes (sterke wachtwoorden, rate-limiting, 2FA, server-niveau filtering) gelden net zo goed voor Joomla en Drupal.

Stap 1: Sterke en unieke wachtwoorden

De basis. Een brute-force-aanval probeert combinaties uit een woordenlijst plus bekende lekken. Een zwak wachtwoord (admin123, welkom2024, de bedrijfsnaam plus 1) valt meestal binnen minuten.

Wat werkt:

• Minimaal twaalf tekens, willekeurig gegenereerd
• Hoofdletters, kleine letters, cijfers en symbolen
• Geen woorden, namen of jaartallen die op je site of social media staan
• Voor elke admin een eigen wachtwoord, nooit hergebruiken tussen sites

Een wachtwoordmanager (Bitwarden, 1Password, KeePassXC) doet dit voor je. Genereert wachtwoorden, slaat ze op, vult ze in. Geen briefjes onder het toetsenbord, geen Excel met wachtwoorden.

Een snelle check: voer je e-mailadres in op Have I Been Pwned. Staat je adres in lekken, dan zijn je oude wachtwoorden ergens openbaar. Wijzig ze, ook al gebruik je ze al jaren probleemloos.

Stap 2: Geen admin als gebruikersnaam

WordPress maakt al jaren geen admin-account meer aan bij installatie, maar legacy-sites hebben het er vaak nog. Botnets gokken bijna altijd admin als gebruikersnaam, dus die helft van de combinatie krijgen ze gratis als je dat laat staan.

Wat te doen: maak een nieuwe admin-gebruiker aan met een willekeurige naam, log daarmee in, en verwijder de oude admin. Wijzig bij het verwijderen welke gebruiker de bestaande content erft (dezelfde nieuwe admin).

Doe hetzelfde met gebruikersnamen die je naam, je bedrijfsnaam of editor zijn. Een gebruikersnaam die niet op de site staat (in author-archieven, comments, sitemap), is moeilijker te raden.

WordPress toont gebruikersnamen standaard op /author/-pagina’s en in REST API-endpoints. Wil je dat afschermen, dan bieden plugins als WP 2FA, Wordfence of een snippet in je theme-functies de mogelijkheid om dit te verbergen.

Stap 3: Login-pogingen beperken (rate-limiting)

Standaard staat WordPress toe dat iemand het oneindig aantal keer een wachtwoord probeert. Een botnet kan dus duizenden combinaties per uur uitproberen tot er iets klopt.

Rate-limiting blokkeert IP-adressen na een aantal mislukte pogingen. De drempel: meestal vijf foutieve pogingen in vijf minuten, gevolgd door een blokkade van vijftien minuten tot een uur.

Plugins die dit doen:

• Limit Login Attempts Reloaded: lichtgewicht, gratis, een vinger in de pap genoeg
• Wordfence: rate-limiting zit standaard in de gratis versie
• WP Limit Login Attempts: alternatief met geo-blocking

Voor wie geen plugin wil toevoegen: rate-limiting op server-niveau via Nginx of via een WAF zoals Cloudflare is een schonere oplossing. Zie stap 7.

Stap 4: Twee factor authenticatie verplichten

Zelfs als een aanvaller je wachtwoord raadt, komt hij er niet in zonder de tweede factor. Twee factor authenticatie is de enkele maatregel die brute-force volledig uitschakelt als aanvalsvector.

In het kort: een plugin (Two Factor, WP 2FA, of Wordfence Login Security) plus een authenticator-app op je telefoon. Bij elke login: wachtwoord, plus een zescijferige code uit de app.

Verplicht 2FA voor alle admin- en editor-rollen, niet alleen voor de eigenaar. Een editor met een zwak wachtwoord blijft anders een open deur. WP 2FA en Wordfence Login Security ondersteunen verplichte 2FA per rol, met een uitstel-window voor nieuwe gebruikers.

Voor het volledige stappenplan: zie het artikel over twee factor authenticatie WordPress instellen in de categorie website beveiliging.

Stap 5: XML-RPC beperken of uitschakelen

xmlrpc.php is een oudere WordPress-interface voor remote publiceren en pingbacks. Voor 95% van de WordPress-sites in 2026 niet meer nodig. Tegelijk is het een populair brute-force-doelwit, omdat één request meerdere wachtwoord-pogingen tegelijk kan testen.

Drie opties, oplopend in effectiviteit:

1. Beperk XML-RPC tot vertrouwde IP’s via .htaccess of Nginx-config. Houdt sommige Jetpack-functionaliteit werkend.
2. Schakel XML-RPC volledig uit via een plugin (Disable XML-RPC) of via een filter in functions.php. Gebruik je Jetpack, mobiele apps voor WordPress, of een externe publicatietool? Eerst checken.
3. Blokkeer op WAF-niveau via Cloudflare of Sucuri. Schoonste optie, omdat het verkeer je server niet eens bereikt.

Voor de doorsnee MKB-site is volledig uitschakelen de juiste keuze. Pas dit aan als je expliciet weet dat een tool XML-RPC nodig heeft.

Stap 6: Login-URL hernoemen (security through obscurity)

WordPress-loginpagina staat standaard op /wp-login.php en /wp-admin/. Botnets weten dat. Een eenvoudige maatregel: hernoem de login-URL naar iets willekeurigs.

Plugins zoals WPS Hide Login of de login-hide-functie in Wordfence verplaatsen je login naar bijvoorbeeld /mijngeheime-deur/. Standaardverzoeken naar wp-login.php krijgen een 404. Botnets die niet weten waar je login is, kunnen niets uitproberen.

Belangrijk: dit is geen vervanging van rate-limiting of 2FA. Een gerichte aanvaller vindt de echte URL alsnog via subtiele lekken (REST API-eindpunten, cookies, login-knoppen in thema’s). Maar het filtert het massale botverkeer wel weg, en dat is verreweg het grootste volume.

Wat je nooit doet: alleen op deze maatregel vertrouwen. Sterke wachtwoorden, rate-limiting en 2FA blijven nodig. Login-hernoeming is een filter aan de buitenkant.

Stap 7: Server- en WAF-niveau bescherming

De effectiefste maatregelen filteren brute-force-verkeer voordat het je WordPress-server bereikt. Twee plekken waar dat kan.

Cloudflare (gratis tier). Voor de meeste MKB-sites is dit een no-brainer. Je laat je DNS via Cloudflare lopen, en hun WAF blokkeert al een groot deel van het bot-verkeer voordat het bij je hosting komt. In het Cloudflare-dashboard zet je extra een rate-limiting-regel voor /wp-login.php en /xmlrpc.php. Klaar.

Voor configuratiedetails: de Cloudflare-documentatie heeft een specifieke handleiding voor WordPress-rate-limiting.

Sucuri WAF (betaald). Een stap zwaarder. Sucuri filtert proactief op WordPress-specifieke patronen en biedt geo-blocking, virtual patching en uitgebreidere DDoS-bescherming. Voor webshops en B2B-sites met klantdata vaak de moeite waard.

Server-niveau (Nginx/Apache). Voor wie eigen hosting beheert: een limit_req-blok in Nginx of een mod_security-regel in Apache filtert brute-force voor het PHP raakt. Werkt sneller en goedkoper dan een plugin. Vereist server-toegang en weten wat je doet.

In mijn praktijk combineer ik bij klanten meestal: Cloudflare gratis aan de buitenkant, Wordfence Free voor de plugin-laag, sterke wachtwoorden en 2FA op alle admins. Dat dekt verreweg de meeste situaties zonder kosten te maken.

Wat ik aanraad voor een typische MKB-site

Niet alle zeven stappen tegelijk inrichten. Op volgorde van impact:

1. Sterke wachtwoorden voor alle admins (vandaag nog te doen)
2. 2FA verplicht voor alle admin- en editor-rollen (binnen 30 minuten)
3. Login-rate-limiting via Wordfence Free of Limit Login Attempts (15 minuten)
4. XML-RPC uitschakelen tenzij actief gebruikt (5 minuten)
5. Verwijder admin als gebruikersnaam (10 minuten)
6. Cloudflare gratis aansluiten met rate-limiting-regel (een uur)
7. Login-URL hernoemen als extra filter (10 minuten)

Met deze zeven heb je het massale brute-force-verkeer praktisch geneutraliseerd. Een gerichte aanvaller (zeldzaam bij MKB) komt verder niet door 2FA heen.

Voorbeeldscenario: een lokale dienstverlener kwam met de melding dat zijn site dagelijks langzaam laadde tussen 02:00 en 04:00 ’s nachts. In de logs: duizenden login-pogingen vanuit een Aziatisch botnet. Na een uur werk (Cloudflare-rate-limiting, Wordfence Free, 2FA verplicht, XML-RPC uit): het verkeer was weg, site bleef snel, geen login-pogingen meer voorbij de WAF.

Wil je hulp bij hardening of bij de configuratie? Stuur me je URL en je serverlogs of plugin-meldingen, dan kijk ik welke maatregelen het meest helpen. Setup en hardening reken ik op uurbasis tegen €70 per uur. Geen 24/7-support; spoedwerk in de avond of het weekend gaat tegen €105 per uur. Direct contact met degene die het werk uitvoert.

Meer praktische uitleg over beveiliging vind je in de categorie website beveiliging. Voor doorlopend onderhoud kun je terecht op de pagina diensten. Voor de bredere context van WordPress-beveiliging is de WordPress-hardening documentatie een goede vervolgstap.