Brute-force op wp-login.php stoppen zonder zware plugins

Elke WordPress-site krijgt dag en nacht automatische inlogpogingen te verwerken op wp-login.php en xmlrpc.php. Dat is niet persoonlijk: botnets proberen op miljoenen sites tegelijk standaard-wachtwoorden uit. Je stopt het niet met een zware security-plugin, maar met een paar lichte maatregelen — een sterke gebruikersnaam en wachtwoord, tweefactorauthenticatie, een limiet op inlogpogingen, het blokkeren van xmlrpc.php en een hoster die deze IP's op serverniveau bant.

Wat er precies gebeurt (en waarom jouw site het ook krijgt)

Criminelen verzamelen grote netwerken van gehackte computers en servers: botnets. Die netwerken doen maar één ding, de hele dag door: WordPress-sites opzoeken en inloggen proberen. Ze werken met lijsten van veelgebruikte combinaties — admin met welkom123, admin met de domeinnaam als wachtwoord, en zo duizenden varianten verder.

Het doel is niet jouw site specifiek. Het doel is een site binnenkomen, welke dan ook. Een gehackte WordPress-site is geld waard: hij kan spam versturen, malware verspreiden, of zelf onderdeel worden van het botnet. Omdat het volledig geautomatiseerd is, kost een extra doelwit de aanvaller niets — en dus staat elke site die publiek bereikbaar is op de lijst. Ook die van jou, ook als er "niets te halen valt".

Er zijn twee vaste ingangen die ze proberen:

• wp-login.php — de normale inlogpagina van WordPress.
• xmlrpc.php — een oude koppeling waarmee externe programma's met WordPress kunnen praten. Extra populair bij aanvallers, omdat je er via één verzoek honderden wachtwoordpogingen doorheen kunt duwen.

Hoe je het herkent

Drie signalen komen steeds terug:

1. Je site wordt traag zonder duidelijke reden. Elke inlogpoging start WordPress volledig op: PHP draait, de database wordt bevraagd. Bij een rustige aanval merk je niets, maar bij honderden of duizenden pogingen per uur gaat dat ten koste van je echte bezoekers.
2. Je access-log staat vol met POST-regels naar wp-login.php. In het logboek van je hosting (bijna elk paneel heeft een access-log) zie je dan regel na regel POST /wp-login.php of POST /xmlrpc.php, vaak vanaf steeds wisselende IP-adressen uit de hele wereld.
3. Je krijgt mails over geblokkeerde inlogpogingen. Heb je een plugin die inlogpogingen beperkt, dan stuurt die meldingen: "IP geblokkeerd na te veel mislukte pogingen". Eén zo'n mail per week is normaal; tien per dag betekent dat er een botnet op je site zit.

Belangrijk om te weten: zelfs als álle pogingen mislukken, kost het je site prestaties. Het probleem is dus niet alleen "komen ze binnen", maar ook "wat kost het onderweg".

Waarom een zware security-plugin vaak niet de oplossing is

De reflex is begrijpelijk: security-probleem, dus security-plugin installeren. En zulke plugins doen op zich nuttige dingen. Maar voor dít probleem — brute-force in volume — zit er een weeffout in de aanpak.

Een plugin draait binnen WordPress. Dat betekent: voordat de plugin ook maar iets kan blokkeren, is de aanvraag al door de webserver aangenomen, is PHP opgestart, is WordPress geladen en is er verbinding met de database gemaakt. Pas dán zegt de plugin "nee". De rem zit te laat: al het zware werk is op dat moment al gedaan.

Bij een handvol pogingen per dag maakt dat niets uit. Bij een botnet dat er duizenden per uur doet, betekent het dat je server voor elke poging het volledige WordPress-circus draait — alleen om hem af te wijzen. Ik zie in de praktijk regelmatig sites waar de security-plugin de server júist zwaar belastte, terwijl het botnet er vrolijk op door bleef hameren. De site was "beveiligd" en tegelijk trager en kwetsbaarder voor overbelasting dan ervoor.

Daar komt bij dat de grote security-suites zelf fors zijn: eigen firewall-laag in PHP, live traffic-logging in de database, scans op de achtergrond. Op een drukke site stapelt dat op.

De conclusie is niet "doe niets". De conclusie is: blokkeer zo veel mogelijk vóórdat WordPress eraan te pas komt, en houd wat er in WordPress zelf draait licht.

Wat wél werkt

1. Sterke wachtwoorden en geen "admin" als gebruikersnaam

De basis, maar hij doet het meeste werk. Botnets gokken; met een lang, uniek wachtwoord (een wachtwoordmanager maakt dat makkelijk) is de kans dat ze goed gokken praktisch nul.

Gebruik daarnaast nooit admin als gebruikersnaam — dat is de eerste die elke bot probeert. Heb je die nog? Maak een nieuwe beheerder aan met een andere naam, log daarmee in en verwijder het oude admin-account (wijs de berichten toe aan de nieuwe gebruiker).

2. Tweefactorauthenticatie (2FA)

Met 2FA is een geraden wachtwoord alleen niet meer genoeg: er is ook een code van je telefoon nodig. Een lichte plugin zoals Two-Factor of WP 2FA regelt dit in een paar minuten. Voor de accounts met beheerdersrechten zou ik dit altijd aanzetten; voor die accounts is de schade bij een geslaagde inbraak het grootst.

3. Inlogpogingen beperken met een lichte plugin

Een kleine plugin als Limit Login Attempts Reloaded doet één ding: na een paar mislukte pogingen wordt het IP-adres tijdelijk geweigerd. Dat haalt de scherpe randjes van een aanval af zonder de bagage van een complete security-suite. Let wel: dit werkt nog steeds binnen WordPress, dus het lost de serverbelasting maar deels op. Zie het als een goede tussenlaag, niet als eindstation.

4. Blokkeer xmlrpc.php als je het niet gebruikt

De meeste sites gebruiken xmlrpc.php helemaal niet meer. Gebruik je géén Jetpack, niet de klassieke WordPress-app en geen externe koppeling die erop leunt? Dan kun je het bestand volledig dichtzetten. Op een Apache- of LiteSpeed-server zet je dit in de .htaccess in de hoofdmap van je site:

# xmlrpc.php volledig blokkeren
<Files "xmlrpc.php">
    Require all denied
</Files>

Draai je op een oudere Apache-versie, dan is de variant Order allow,deny gevolgd door Deny from all het equivalent.

Kanttekening: Jetpack en de (oudere) WordPress-mobiel-app communiceren via xmlrpc.php. Gebruik je die, blokkeer het bestand dan niet — je koppeling valt anders stil. Twijfel je? Blokkeer het, test of alles nog werkt, en draai het terug als er iets stukgaat. De regel is met één aanpassing weer weg.

5. Zet de inlogpagina achter een extra slot

De krachtigste maatregel aan de sitekant: laat de webserver zelf de inlogpagina afschermen, vóórdat WordPress opstart. Twee smaken:

Basic-auth (extra wachtwoordvenster). De browser vraagt eerst een apart gebruikersnaam/wachtwoord voordat je überhaupt de WordPress-inlogpagina te zien krijgt. Bots stranden op dat eerste slot, en dat slot is voor de server vrijwel gratis. Maak eerst een wachtwoordbestand aan (dat kan via je hostingpaneel of met het commando htpasswd; zet het bestand búiten je webmap) en voeg dan toe aan .htaccess:

# Extra wachtwoord op de inlogpagina
<Files "wp-login.php">
    AuthType Basic
    AuthName "Beveiligde inlog"
    AuthUserFile /pad/buiten/webmap/.htpasswd
    Require valid-user
</Files>

IP-beperking. Werk je altijd vanaf een vast IP-adres (kantoor of thuis met vast IP), dan kun je de inlogpagina daartoe beperken:

# Inloggen alleen vanaf eigen IP
<Files "wp-login.php">
    Require ip 203.0.113.10
</Files>

Vervang het voorbeeld-IP door je eigen adres; meerdere adressen zet je achter elkaar op dezelfde regel. Let op: bij een wisselend IP (de meeste thuisverbindingen, en zeker mobiel) sluit je jezelf hiermee buiten. Basic-auth is dan de praktischere keuze.

Eén uitzondering om te kennen: sommige plugins (zoals WooCommerce in bepaalde flows) sturen bezoekers langs wp-login.php voor wachtwoord-resets. Test na het instellen even of "wachtwoord vergeten" voor je klanten nog werkt.

6. De serverkant: waar het écht gestopt hoort te worden

Alles hierboven kun je zelf doen. Maar de structurele oplossing zit een laag dieper: op de server. Een hoster die meekijkt in de logs kan een IP dat op wp-login.php staat te rammen op firewallniveau blokkeren, bijvoorbeeld met fail2ban. Het verschil is fundamenteel: een firewall-block stopt het verkeer voordat de webserver, PHP of de database er ook maar iets van merkt. Geen belasting, geen tragere site, geen ruis in je logs. De rem zit dan wél op de goede plek.

Op de servers die ik beheer werkt het precies zo: mislukte inlogpogingen worden automatisch geteld, en een IP dat doordramt gaat op firewallniveau dicht — de rest van de aanval komt simpelweg de server niet meer op. De sites zelf hebben daar geen plugin voor nodig en merken er niets van.

Wat je van je hoster mag verwachten

Dit is een redelijk lijstje om aan je hostingprovider voor te leggen:

• Automatische bans op serverniveau (fail2ban of vergelijkbaar) voor brute-force op wp-login.php en xmlrpc.php.
• Monitoring: valt een aanval op door load of logvolume, dan hoort de hoster dat te zien — niet jij pas als je site traag is.
• Hulp bij de .htaccess-maatregelen hierboven, als je daar zelf niet uitkomt.
• Een mens die reageert als je site onder vuur ligt, niet een ticketwachtrij van drie dagen.

Krijg je op de eerste vraag een ontwijkend antwoord, dan weet je genoeg: dan draait elke botnet-poging gewoon je PHP en database aan, en ben je afhankelijk van plugins die te laat remmen.

Samengevat

Brute-force op je inlogpagina is achtergrondruis van het internet: iedereen krijgt het, dag en nacht, en het is nooit persoonlijk. De verdediging hoeft niet zwaar te zijn — hij moet vooral op de juiste plek zitten:

1. Sterk wachtwoord, geen admin-gebruikersnaam.
2. 2FA op alle beheerdersaccounts.
3. Een lichte plugin die inlogpogingen beperkt.
4. xmlrpc.php dicht als je het niet gebruikt.
5. Basic-auth of IP-beperking op wp-login.php.
6. Een hoster die aanvallers op firewallniveau blokkeert, vóórdat PHP eraan te pas komt.

Met die zes punten ben je voor 99% van deze aanvallen simpelweg geen interessant doelwit meer — zonder dat je site er trager van wordt.