Van al het verkeer dat een gemiddelde WordPress-site binnenkrijgt, is een verrassend groot deel niets anders dan geautomatiseerde inlogpogingen. Scripts die dag en nacht wachtwoorden proberen op wp-login.php. Inlogpogingen beperken in WordPress is de maatregel die daar het meeste tegen doet, in verhouding tot de tijd die het kost.

Standaard mag u namelijk oneindig vaak proberen. WordPress zegt netjes dat het wachtwoord fout is en biedt het formulier opnieuw aan, tot in het oneindige. Hieronder leest u wat een verstandige limiet is, welke instellingen ernaast horen, en hoe u voorkomt dat u zichzelf op een vrijdagmiddag buitensluit.

Waar de limiet tegen helpt

Bijna al het aanvalsverkeer op een inlogpagina komt van scripts die lijstjes afwerken: bekende gebruikersnamen tegen bekende wachtwoorden. Een limiet maakt dat werk onbetaalbaar. Wie na vijf pogingen twintig minuten moet wachten, komt in een jaar tijd niet aan een serieuze lijst toe.

Wat het niet tegenhoudt: iemand die uw wachtwoord al kent, bijvoorbeeld doordat het bij een andere dienst is gelekt. Die logt in één poging in. Daarvoor heeft u een uniek wachtwoord en een tweede stap nodig; zie de afweging tussen een wachtwoordmanager en tweestapsverificatie.

Het weert ook geen aanvallen die de inlogpagina overslaan. Aanvallen via XML-RPC of via de interface van WordPress lopen langs een andere deur. Een goede plugin telt die pogingen mee; controleer dat, want niet alle doen dat.

Welke instellingen verstandig zijn

De standaardwaarden van veel plugins staan te ruim of juist te streng. Deze verhoudingen werken in de praktijk goed voor een gewone bedrijfssite.

  • Aantal pogingen: vier of vijf. Genoeg voor iemand die zich vertypt, te weinig voor een script. Twee of drie levert vooral geïrriteerde collega’s op.
  • Blokkeerduur: twintig tot zestig minuten. Lang genoeg om een aanval onrendabel te maken, kort genoeg om uzelf niet de dag te bederven.
  • Bij herhaling langer blokkeren. Wie binnen 24 uur drie keer de limiet raakt, mag gerust een etmaal wachten.
  • Tel het geheugen per uur of per dag. Staat de teller na vijf minuten weer op nul, dan probeert een script het gewoon in rondjes.
  • Blokkeer op ip-adres, niet alleen op gebruikersnaam. Anders werkt een aanvaller simpelweg de namen af.

Verberg daarnaast wát er fout was. WordPress meldt standaard of de gebruikersnaam bestaat, en dat is gratis informatie. De meeste beveiligingsplugins hebben een instelling die daar één neutrale melding van maakt.

Uzelf niet buitensluiten

Dit is het punt waarop het in de praktijk misgaat, en het is goed te voorkomen.

  1. Zet uw eigen vaste ip-adres op de uitzonderingenlijst, als u op kantoor een vast adres heeft. Vraag dat na bij uw internetleverancier; het is vaak een kwestie van een pakket met een vast adres.
  2. Weet hoe u zichzelf deblokkeert. Dat kan via het hostingpaneel door de betreffende plugin uit te schakelen, of door zijn map te hernoemen. Zoek dat één keer uit als het rustig is, niet als u er al buiten staat.
  3. Zorg dat uw beheerdersmail werkt. Veel plugins sturen een deblokkeerlink naar het beheerdersadres. Komt die mail niet aan, dan heeft u niets aan die functie.
  4. Gebruik een wachtwoordmanager. Dan tikt u nooit meer verkeerd en raakt u de limiet simpelweg niet.
  5. Waarschuw uw team voordat u de limiet aanzet. Anders staat er maandagochtend een rij bij uw bureau.

Vergeet ook uw mobiele verbinding niet: op 4G heeft u een ander en wisselend adres, dus een uitzondering op kantoor-ip helpt u onderweg niet.

Waarmee u het combineert

Een limiet op inlogpogingen wordt sterker in combinatie met een paar andere dingen. Geen van alle ingewikkeld.

Een tweede stap bij het inloggen. Dit is de maatregel die het wachtwoord zelf minder belangrijk maakt. Voor beheerders zou het standaard aan moeten staan.

Geen makkelijk te raden gebruikersnamen. Zolang uw beheerder “admin” of uw bedrijfsnaam heet, is de helft van het raadwerk al gedaan. Zie ook hoe uw inlognaam via de auteur-url naar buiten lekt.

Een firewall die het volume eerder afvangt. Bij een pluginlimiet komt het verkeer nog steeds op uw server aan; bij grote aanvallen merkt u dat aan de snelheid. Een filter dat vóór uw hosting zit, houdt dat weg.

Meldingen die iemand leest. Een blokkade die niemand opmerkt, is een gemiste waarschuwing. Zet meldingen aan voor herhaalde blokkades, niet voor elke losse poging, anders leest u ze na een week niet meer.

Wat u niet hoeft te doen

Er wordt vaak aangeraden om de inlogpagina te verplaatsen naar een geheim adres. Dat weert een deel van het domme verkeer, maar het is geen bescherming: wie gericht kijkt, vindt hem alsnog. Erger is dat u het uzelf en uw collega’s lastig maakt en dat u bij een pluginstoring uw eigen ingang kwijt bent. Als u het doet, doe het dan bewust en leg het adres vast op een plek buiten de site.

Zet ook niet zomaar hele landen op slot. Het klinkt effectief, maar u blokkeert er even vrolijk een klant mee die op vakantie is of een leverancier die via een buitenlands netwerk werkt.

Een limiet instellen en daarna de meldingen ook echt volgen, hoort bij het inrichten en bewaken van de beveiliging van een WordPress-site. Bij WebMaintor is dit de eerste instelling die we controleren bij een nieuwe site, simpelweg omdat het de goedkoopste maatregel is met het grootste zichtbare effect in de logboeken.

Concrete volgende stap: kijk in uw beveiligingsplugin of er een limiet actief is en op hoeveel pogingen die staat. Staat er niets, dan is dat het vinkje dat u vandaag nog aanzet.