Brute force is de eenvoudigste aanval die er bestaat: blijven proberen tot het raak is. MITRE beschrijft hem (CAPEC-112) als een reeks pogingen tegen een geheim van eindige omvang, wat betekent dat hij altijd slaagt als je hem zijn gang laat gaan. Alle verdediging draait er dus om de operatie te lang of te duur te maken om de moeite waard te zijn. Op WordPress begint die achtergrondruis vaak al zodra een site online staat.
Hoe een brute-force-aanval werkt
Een programma stuurt combinaties van gebruikersnaam en wachtwoord naar het inlogformulier en kijkt naar het antwoord. Op WordPress zijn de gebruikelijke doelwitten wp-login.php en xmlrpc.php. De gebruikersnaam is vaak vooraf geraden: admin, de naam van de site, of een auteursnaam die via gebruikersenumeratie is achterhaald.
De varianten
- Uitputtend: alle mogelijke combinaties, alleen realistisch tegen heel korte geheimen.
- Met een woordenboek: lijsten met veelgebruikte wachtwoorden, met varianten (hoofdletter, jaartal, cijfer aan het eind). Dit is de meest voorkomende vorm tegen websites.
- Gespreid: het werk wordt verdeeld over duizenden gekaapte machines (een botnet), die elk maar een paar pogingen doen.
- Met gestolen inloggegevens: er wordt niet meer geraden, maar combinaties uit datalekken worden opnieuw geprobeerd. Dat is credential stuffing, een directe verwant van brute force.
De WordPress-documentatie wijst op een effect dat vaak wordt onderschat: ook als ze mislukken, verbruiken deze pogingen middelen en kunnen ze een server vertragen of zelfs overbelasten. Ons artikel over brute force op WordPress laat zien hoe je ze in je logbestanden herkent.
Hoe je je beschermt
Doeltreffende bescherming werkt op meerdere niveaus. Het NIST vraagt in zijn richtlijn SP 800-63B om het aantal opeenvolgende mislukte pogingen op een account te beperken tot hooguit 100, en staat lagere drempels toe. Het vraagt ook om veelgebruikte of al gelekte wachtwoorden te weigeren wanneer ze worden ingesteld.
- Lange en unieke wachtwoorden, gemaakt door een wachtwoordmanager: daarmee wordt het woordenboek nutteloos.
- Tweefactorauthenticatie voor alle accounts met veel rechten: een gevonden wachtwoord is dan niet meer genoeg.
- Het beperken van inlogpogingen, op serverniveau of met een plugin. Onze gids over drempels en blokkeerduur beschrijft de instellingen en de valkuilen (proxy, gedeeld netwerk).
- Minder open deuren: schakel XML-RPC uit als je het niet gebruikt, en scherm
wp-login.phpaf op IP-adres of met een serverwachtwoord waar dat kan. - Filteren vooraf: een web application firewall of een CDN houdt een deel van het verkeer tegen voordat het PHP bereikt, wat de server ontlast.
Voor WordPress
WordPress heeft zelf geen beperking van inlogpogingen en geen tweefactorauthenticatie: daarvoor heb je een plugin of een serverregel nodig. Vermijd een account met de naam admin, geef de rol Beheerder alleen aan mensen die hem echt nodig hebben en bekijk regelmatig de lijst met accounts via wp user list --role=administrator. Gebruik voor externe toepassingen liever applicatiewachtwoorden, die je een voor een kunt intrekken, dan het hoofdwachtwoord.
WP Masquerade verplaatst de inlogpagina en blokkeert XML-RPC, al in de gratis versie. De Pro-versie voegt het beperken van inlogpogingen toe (3 tot 30 mislukte pogingen, blokkade van 1 tot 60 minuten) met neutrale foutmeldingen. Het is geen netwerkfirewall: tegen een sterk gespreide aanval blijven een uniek wachtwoord en een tweede factor het echte verweer.
Veelgemaakte fouten
- Alleen vertrouwen op een ander inlogadres: dat vermindert de ruis, maar beschermt geen zwak wachtwoord.
- Twee plugins naast elkaar gebruiken die dezelfde mislukte pogingen tellen: deblokkeren wordt dan een puzzel.
- De proxy of het CDN vergeten: zonder herstel van het echte IP-adres delen alle bezoekers dezelfde teller.
- Periodiek nieuwe wachtwoorden afdwingen: het NIST vraagt juist om dat niet meer te eisen, behalve bij een vermoeden van misbruik.