Als je met Google gaat zoeken naar manieren om je WordPress-site te beveiligen, dan ga je hele hordes lijstjes met maatregelen vinden. Deze lijstjes gaan vaak niet veel verder dan het intrappen van een paar open deuren zoals “niet het admin account gebruiken” en “regelmatig een backup maken”.

Uiteraard maakt iedereen al gebruik van een ander account dan het admin account!

Regelmatig een backup maken en die op een andere locatie dan je WordPress site bewaren is er ook zo eentje. Natuurlijk, één keer per jaar een backup maken is ook een vorm van regelmaat…

Ook zorgen we er met zijn allen voor dat WordPress en diens plugins altijd zijn bijgewerkt naar de laatste versie. Mochten daar onoverkomelijke fouten in zitten, dan toch in ieder geval de een-na-laatste versie!

Wachtwoorden van minimaal acht tekens in een combinatie van hoofdletters, kleine letters, cijfers en leestekens zijn een vanzelfsprekendheid – toch?

Nou even serieus. Dit soort maatregelen lijkt me toch echt wel het minimum, maar er is meer mogelijk, ook zonder meteen bakken met geld te moeten uitgeven!

Blokkeren die hap

Een voorbeeld van een extra beveiliging is een plugin die het aantal loginpogingen beperkt,  in combinatie met een IP-blokkade en een whitelist.

Op het moment dat te vaak wordt geprobeerd in te loggen vanaf een bepaald IP-adres, wordt die gebruikersnaam en IP-adres geblokkeerd. Een whitelist is een lijst met IP-adressen vanwaar altijd mag worden ingelogd. In deze lijst staat bijvoorbeeld het IP-adres van je eigen provider.

Hoewel zeer effectief heeft deze methode twee nadelen. Het eerste nadeel is dat als je je eigen wachtwoord niet meer weet en je teveel pogingen hebt gedaan, je eigen account ook wordt geblokkeerd. Het tweede nadeel is dat er behoorlijk wat werk bij komt kijken. Zelfs als je gebruikmaakt van automatische detectie en blokkering, kan je er niet aan ontkomen de whitelist en blokkades regelmatig te controleren. Je loopt anders het risico dat je bezoekersaantallen langzaam teruglopen naar heel-laag.

Daar staat dan weer tegenover dat je de gevolgen van een brute force aanval enigszins kunt beperken. Een brute force aanval wil zeggen dat in een rap tempo inlogpogingen worden gedaan met gebruikersnamen die worden aangemaakt bij een eerste installatie van WordPress. Beroemde websites en hostingproviders weten daarover mee te praten – die krijgen tig-duizenden van dit soort aanvallen per dag.

Plaatjes kijken en sommetjes maken

Een andere, heel eenvoudige en effectieve manier van beveiligen is een captchaplugin. Dit is een plugin die je bij het inloggen een plaatje met letters en cijfers of een sommetje voorschotelt om uitgerekend en ingevoerd te worden. Ik geef de voorkeur aan een sommetje, maar dan wel eentje die werkt met een willekeurige volgorde van cijfers en woorden zoals de plugin van BestWebSoft.

Reden is dat de image scanners tegenwoordig zo goed zijn dat de loginbots soms toch in staat zijn de juiste letters en cijfers in te voeren. En voor zover dat niet zo is, zijn de afbeeldingen zo goed dat je ze zelf niet meer kunt lezen!

Een brute force login is hiermee niet te voorkomen, maar het wordt die hackersbende wel stukken lastiger gemaakt zonder dat het veel extra werk met zich meebrengt. Zeker als je gebruikmaakt van een combi van plaatjes en sommetjes in één plugin.

Tweewegverkeer

Een methode die de laatste tijd in opkomst is, is tweewegauthenticatie en verificatie. Nadat je je gebruikersnaam en wachtwoord hebt ingevoerd, krijg je (bijvoorbeeld) een sms-je toegestuurd met een code die ook moet worden ingevoerd voordat je verder kunt. In plaats van sms kan je vaak ook gebruikmaken van een app. Afhankelijk van de plugin zijn er meerdere mogelijkheden.

Deze methode is erg veilig omdat wordt gebruikgemaakt van de combinatie “iets wat je weet”, “iets wat je hebt” en “iets wat je krijgt”. Wat je weet is je gebruikersnaam en wachtwoord. Wat je hebt is een mobieltje met een 06-nummer. Wat je krijgt is de toegestuurde code via een sms of een app.

Ook hiermee kunnen de gevolgen van een brute force aanval niet worden voorkomen. Sterker nog, een dergelijke aanval kan juist zorgen voor een overbelaste webserver doordat steeds weer een nieuwe code wordt aangemaakt en verstuurd. Nog los van de stortvloed aan sms-jes, mocht je van dit medium gebruikmaken. Daarom is het goed dit type beveiliging te combineren met de eerder beschreven methode van account- en IP-adresblokkade.

Daarnaast is het zaak te zorgen voor een workaround voor de momenten dat je telefoon of diens internetverbinding het even laat afweten.

Kaartlezer of biometrie

Even met eenvoud als uitgangspunt: De meest veilige methode blijft nog altijd het gebruik van een kaartlezer met bijhorende plugin, een methode die banken en webwinkels veel gebruiken. Ook hier wordt gewerkt met de eerder genoemde combinatie, maar nu met je rekeningnummer en pincode (is iets wat je weet) en je bankpas (is iets wat je hebt).

Samen met een kaartlezer levert dit een code op die bij iedere login anders is (iets wat je krijgt). Heb je een andere bankpas dan op dat moment bekend bij de bank, dan klopt het pasnummer niet en wordt de verkeerde code aangemaakt waardoor je niet verder kan.

Andere varianten op dit principe zijn een vingerafdruk, irisscan of gezichtsherkenning (als vervanger voor je rekeningnummer en bankpas). In vaktermen ook wel aangeduid als biometrische beveiliging.

De verantwoordelijkheid van je hostingprovider

Een brute force aanval blijft altijd een lastige, zeker als je site vanuit verschillende locaties en in zeer rap tempo wordt bestookt met verschillende soorten “aanvragen”. Waarbij de hackersbende ook andere php-scripts probeert te starten dan die van WordPress zelf. Dit type aanval is ook bekend als een distributed denial-of-service aanval (afgekort tot DDOS).

Het enige wat hier helpt is een firewall zoals de Stingray van Riverbed. Dit soort firewalls slaat alarm en werpt blokkades op bij een bepaalde combinatie van aantallen gebruikers, hun afkomst en wat ze doen.

Hoewel er voor WordPress verschillende plugins zijn die hetzelfde nastreven, ben ik van mening dat dit type beveiliging een verantwoordelijkheid is van je hostingprovider omdat deze maatregel bij de voordeur het meest effectief en efficiënt is. Bovendien gaat zo’n maatregel niet ten koste van de prestaties van de virtuele server waarop jouw website draait.

Voor de andere maatregelen ligt dat anders. Die kennen vaak een meer persoonlijk smaakje. Bijvoorbeeld vanwege de functies van je site. Immers, het maakt nogal wat uit of je iets doet waar betalingen aan zijn gekoppeld of iets met alleen blogs en forums. Je kan niet van je provider verwachten dat hij zijn dienstverlening aanpast aan de specifieke wensen van elke klant en de functies van iedere site.

Geen garanties

Hoewel firewalls en alle andere vormen van beveiliging steeds beter worden, geeft het nooit een 100% garantie dat er echt helemaal niks kan gebeuren. Al was het alleen maar omdat die hackersbende steeds beter wordt en het maken van WordPress en plugins mensenwerk blijft waardoor fouten en beveilingslekken ontstaan. Het blijft dus een haasje-over verhaal; het ene moment is je firewall met alle andere maatregelen aan de winnende hand en het andere moment ligt het voordeel bij de hackersbende.

Dat mag geen excuus zijn om niks te doen; beveiligen is een must, ook al zijn er geen garanties! Laat je agrarisch denkvermogen voor je werken met een realistische risicoanalyse en dito maatregelen. Vraag jezelf ook eens af hoe erg het is als je site inderdaad wordt gehackt en wat er nodig is om de zaak gerepareerd te krijgen. Want nogmaals, het maakt nogal wat uit of je iets doet waar betalingen aan zijn gekoppeld of iets met blogs en forums.

Misschien meer nog dan in veel andere gevallen geldt hier: Eerst denken, dan doen. Want anders verzuip je in de risicoanalyses en veiligheidsmaatregelen. Met als resultaat een site zonder bezoekers omdat er niet meer mee is te werken!


Geschreven door