WordPress website beveiligen in 12 stappen

Hoe een site in de praktijk gehackt wordt

Bijna niemand wordt gericht aangevallen. Wat er werkelijk gebeurt is saaier: een bot scant het internet af op sites die een bepaalde plugin in een bepaalde versie draaien, vindt die van jou, en voert een exploit uit die al maanden publiek bekend is. Er zit geen persoon achter en het heeft niets met jouw bedrijf te maken.

Dat is goed nieuws, want het betekent dat je niet tegen een gemotiveerde aanvaller hoeft op te boksen. Je hoeft alleen te zorgen dat je niet in die scan valt. De stappen hieronder staan op volgorde van hoeveel ze werkelijk uitmaken, niet op volgorde van hoe technisch ze klinken.

Ik werk volgens de OWASP-richtlijnen, de internationale standaard voor webapplicatiebeveiliging, en heb meegeholpen aan de technische kant van een ISO/IEC 27001-certificering bij een bedrijf. Codurion zelf is niet ISO-gecertificeerd; dat is werk dat ik bij een werkgever heb gedaan.

1. Updates, en waarom uitstellen het risico is

Verreweg de meeste gehackte sites draaiden software waarvoor de patch al bestond. Zodra een lek gedicht wordt, is het publiek: de melding staat in de changelog en in openbare CVE-databases. Vanaf dat moment weten aanvallers precies waar ze op moeten scannen. De periode tussen "patch beschikbaar" en "jij hebt hem geïnstalleerd" is je risicovenster.

Zet automatische updates aan voor de WordPress-kern en voor beveiligingsreleases. Voor plugins en thema's is automatisch updaten een afweging: het kan je site breken. De praktische middenweg is elke twee weken handmatig bijwerken, met een back-up ervoor. Duurt dat je te lang, dan is het goedkoper om het uit te besteden dan om een hack op te ruimen.

Controleer ook je PHP-versie. Dat wordt het vaakst vergeten. Een site op PHP 7.4 of ouder krijgt geen beveiligingsupdates meer; 7.4 is eind 2022 gestopt. Je ziet het in je hostingpaneel of onder Gereedschap, Websitestatus in WordPress zelf.

2. Plugins zijn je grootste aanvalsvlak

Elke plugin is code van iemand anders die volledige toegang heeft tot je site en je database. Dertig plugins betekent dertig partijen die je vertrouwt en dertig onderhoudsschema's waar je geen invloed op hebt. Dit is in OWASP-termen een supply chain-risico, en het is bij WordPress de belangrijkste oorzaak van incidenten.

Wat je concreet doet:

• Gooi weg wat je niet gebruikt. Gedeactiveerde plugins staan nog steeds op je server en zijn nog steeds kwetsbaar. Deactiveren is niet genoeg, verwijderen wel.
• Kijk voor je installeert naar het onderhoud. Wanneer was de laatste update? Hoeveel actieve installaties? Reageert de maker op supportvragen? Een plugin die twee jaar niet is bijgewerkt, is een openstaande deur.
• Wees extra kritisch op alles wat bestanden of gebruikers aanraakt. Formulieren met bestandsupload, ledenplugins, bestandsbeheerders en back-upplugins hebben veel rechten nodig en zijn daarom een geliefd doelwit.
• Geen nulled thema's of plugins. Betaalde software die je gratis ergens vandaan haalt, bevat met grote regelmaat een achterdeur. Dat is precies het verdienmodel.

Een goede vuistregel: kun je niet in één zin uitleggen wat een plugin doet en waarom je hem nodig hebt, dan hoort hij er niet.

3. Het inlogscherm afschermen

Elke WordPress-site heeft /wp-admin en /wp-login.php, en daar wordt permanent op geprobeerd in te loggen. Drie dingen maken het merendeel van die pogingen zinloos:

• Gebruik nooit "admin" als gebruikersnaam. Dat is de helft van het raadwerk die je weggeeft. Heb je hem, maak dan een nieuwe beheerder aan en verwijder de oude.
• Beperk het aantal pogingen. Zonder limiet kan een bot duizenden wachtwoorden per uur proberen. Met een limiet van vijf per kwartier is dat onbegonnen werk.
• Lange wachtwoorden, uniek per site. Lengte doet meer dan leestekens. Gebruik een wachtwoordmanager; dat is geen luxe maar het minimum.

Een detail dat vaak over het hoofd wordt gezien: standaard vertelt WordPress bij een mislukte poging of de gebruikersnaam bestond. Dat is gratis informatie voor een aanvaller. De meeste beveiligingsplugins kunnen die melding neutraliseren.

4. Tweefactorauthenticatie

Als je één ding doet uit deze lijst, doe dan dit. Tweefactorauthenticatie maakt een gestolen wachtwoord op zichzelf waardeloos, en daarmee vervalt de hele categorie aanvallen die begint met een lek bij een andere dienst waar je hetzelfde wachtwoord gebruikte.

Zet het in elk geval aan voor iedereen met beheerdersrechten. Een app als Google Authenticator of Authy is veiliger dan sms, omdat sms onderschept kan worden via simswapping. Bewaar de herstelcodes ergens buiten je site.

5. Geef iedereen zo min mogelijk rechten

Het principe heet least privilege en het komt hierop neer: iedereen krijgt precies genoeg om zijn werk te doen en niets meer. In de praktijk hebben veel WordPress-sites vijf beheerders terwijl er één nodig is.

Iemand die blogs schrijft heeft genoeg aan de rol Auteur of Redacteur. Een extern bureau dat tijdelijk meekijkt, krijgt een account dat je daarna weer intrekt. Elke beheerder is een volledige sleutel tot je site, en hoe meer sleutels er in omloop zijn, hoe groter de kans dat er eentje uitlekt.

Loop je gebruikerslijst een keer per kwartaal na. Accounts van mensen die er niet meer werken zijn een klassieker.

6. wp-config.php en bestandsrechten

In wp-config.php staan je databasegegevens in leesbare tekst. Twee maatregelen die weinig kosten en veel schelen:

• Vernieuw je security keys. Dat zijn de lange sleutels in wp-config waarmee sessies worden versleuteld. Vernieuwen logt iedereen uit, inclusief een aanvaller met een gestolen sessie. Je genereert ze op de officiële WordPress-sleutelgenerator.
• Zet bestandsrechten goed. Mappen op 755, bestanden op 644, en wp-config.php op 640 of strenger. Staat er ergens 777, dan mag iedereen schrijven, en dat is precies wat een aanvaller zoekt.

Zet ook define('DISALLOW_FILE_EDIT', true); in je wp-config. Zie de volgende stap.

7. De bestandseditor uitzetten

WordPress heeft standaard een editor waarmee je vanuit de beheeromgeving PHP-bestanden kunt aanpassen. Handig bedoeld, maar het betekent dat iemand die één keer als beheerder binnenkomt, direct code op je server kan uitvoeren. Daarmee gaat een gestolen wachtwoord over in volledige controle.

Vrijwel niemand gebruikt die editor bewust. Zet hem uit met de regel hierboven; je verliest er niets mee.

8. HTTPS en security headers

Een geldig certificaat is inmiddels vanzelfsprekend en gratis via Let's Encrypt. Zorg dat al je verkeer erover loopt: een pagina die deels over http laadt, geeft alsnog een waarschuwing.

Wat de meeste WordPress-sites níet hebben, zijn security headers. Dat zijn instructies aan de browser en ze kosten je niets aan snelheid:

• Strict-Transport-Security — dwingt browsers om altijd https te gebruiken
• X-Content-Type-Options: nosniff — voorkomt dat de browser bestandstypes verkeerd interpreteert
• X-Frame-Options of een frame-ancestors-regel — voorkomt dat je site in een iframe van iemand anders wordt geladen
• Referrer-Policy — beperkt wat je doorgeeft aan externe partijen
• Content-Security-Policy — de sterkste, maar ook de lastigste: hij bepaalt welke scripts mogen draaien. Begin in rapportagemodus, anders breek je je eigen site.

Je kunt zelf testen wat je nu hebt via securityheaders.com. De meeste WordPress-sites scoren daar een F, en dat is in een uur naar een B te brengen.

9. Uploads en formulieren

Elk formulier is een plek waar iemand anders data je server in stuurt. Waar het bij WordPress misgaat is vooral bij bestandsupload: als een bezoeker een bestand kan uploaden dat daarna als code wordt uitgevoerd, is je site over.

Beperk toegestane bestandstypen tot wat je echt nodig hebt, sla uploads op buiten de webroot of zorg dat PHP-uitvoering in de uploadmap geblokkeerd is, en vertrouw nooit op de bestandsnaam of de opgegeven mimetype. Dat laatste is in OWASP-termen de kern: alle invoer van buiten is verdacht tot het tegendeel bewezen is.

Zet ook een spamfilter op je formulieren. Niet alleen tegen spam, maar omdat geautomatiseerde formulierinzendingen vaak de verkenningsfase van een aanval zijn.

10. Back-ups die je kunt terugzetten

Een back-up die je nog nooit hebt teruggezet, is geen back-up maar een aanname. Ik kom regelmatig sites tegen waar netjes elke nacht een back-up draait die bij een incident onbruikbaar blijkt: incompleet, corrupt, of op dezelfde server als de site zelf.

Drie eisen: dagelijks, op een andere locatie dan je website, en minstens één keer daadwerkelijk getest door hem ergens terug te zetten. Bewaar ook een paar oudere versies, want een hack wordt soms pas na weken ontdekt en dan is je nieuwste back-up ook besmet.

11. Merken dat er iets gebeurt

De meeste eigenaren ontdekken een hack doordat een klant belt of doordat Google de site markeert. Dat is te laat. Wat wel werkt:

• Search Console met je site erin gekoppeld. Onder Beveiligingsproblemen meldt Google het als er malware gevonden wordt. Gratis, en de meeste sites hebben het niet.
• Uptimemonitoring die je een bericht stuurt als je site plat gaat of ineens omleidt.
• Bestandsintegriteitscontrole, ingebouwd in de meeste beveiligingsplugins: die slaat alarm als een kernbestand verandert.

12. Je hosting doet meer dan je denkt

Goedkope gedeelde hosting betekent vaak dat honderden sites op dezelfde server staan. Wordt daar eentje van gehackt en is de isolatie slecht, dan kun jij meegaan zonder dat je zelf iets fout deed.

Vraag je hostingpartij welke PHP-versies ze ondersteunen, of ze een firewall voor webverkeer draaien, hoe ze accounts van elkaar isoleren, en hoe hun back-upbeleid eruitziet. Krijg je daar geen helder antwoord op, dan weet je genoeg.

En als het toch misgaat

Doe dit in deze volgorde. Zet de site tijdelijk offline of in onderhoudsmodus, zodat bezoekers niet besmet raken en Google je niet markeert. Wijzig daarna alle wachtwoorden: WordPress, hosting, FTP en database. Vernieuw je security keys, zodat bestaande sessies ongeldig worden.

Zet dan een back-up terug van vóór het incident, en niet de nieuwste. Werk vervolgens alles bij voordat je weer live gaat, anders kom je via hetzelfde lek opnieuw binnen. Vraag tot slot in Search Console een herbeoordeling aan als Google je gemarkeerd had.

Zoek niet eindeloos naar het besmette bestand. Bij een goed uitgevoerde hack zijn er meerdere achterdeurtjes en mis je er gegarandeerd één. Terugzetten is vrijwel altijd sneller en betrouwbaarder.

Wanneer beveiligen het probleem niet meer oplost

Ik zeg dit als iemand die zelf jaren met WordPress heeft gewerkt: voor veel sites is het een prima keuze en zijn de stappen hierboven ruim voldoende. Een brochuresite met acht pagina's en drie plugins is met deze lijst goed beschermd.

Er is wel een punt waarop het scheef gaat lopen. Draai je vijfentwintig plugins waarvan er vier niet meer onderhouden worden, zit je vast aan een thema waarvan de maker gestopt is, en durf je niet meer te updaten omdat er dan iets breekt, dan ben je geen beveiliging meer aan het doen maar risico aan het verplaatsen. Op dat moment is opnieuw opbouwen vaak goedkoper dan blijven lappen.

Dat is geen verkooppraatje maar een rekensom die je zelf kunt maken: wat kost het onderhoud per jaar, wat kost een incident, en hoeveel van die plugins heb je echt nodig. Kom je er niet uit, kijk ik er gratis naar en zeg ik wat ik zie. Ook als het antwoord is dat je gewoon moet blijven waar je zit.