Tien regels voor een veilige WordPress Website

Een veilige WordPress website: Omdat geen dag gehackt-dag zou moeten zijn!

Waarom is WordPress eigenlijk zo populair bij hackers?

Wanneer je een beetje het nieuws over de digitale wereld volgt, vraag je je wellicht af of WordPress wel zo’n veilige oplossing is. Want bijna wekelijks zie je een bericht langskomen dat de zoveelste WordPress plugin een veiligheidslek heeft en misbruikt wordt om sites te hacken. Kan je niet beter voor een ander, minder bekend CMS kiezen?

Wanneer deze gedachte door je hoofd speelt, vergeet dat niet, dat je juist zoveel hoort over hacks van WordPress omdat WordPress zo immens populair is. Wanneer een CMS als ‘Backdrop CMS’, ‘Pico’ of ‘PageKit’ gehackt zouden worden, drie minder bekende CMS-en, dan zou je er nergens over lezen. Want wie interesseert zich voor marginale CMS-en?

1. WordPress heeft een groot marktaandeel

Juist dat grote marktaandeel van WordPress maakt het zo interessant om WordPress aan te vallen. Volgens de meest conservatieve schattingen, draait ongeveer 40% van alle websites wereldwijd op WordPress. Dat is behoorlijk wat. Wanneer je potentieel met één methode 40% van alle websites kunt hacken, dan is het zeker de moeite waard, om daar energie in te steken.

2. Veel websites worden slecht tot niet onderhouden

Omdat het zo makkelijk is om een WordPress website te bouwen, zijn er talloze websites die worden opgezet, maar slecht of niet onderhouden. Denk hier bijvoorbeeld aan een website voor een hobbyclub, vereniging of voor een tijdelijke fondswerving actie.

Of iemand laat een site bouwen, en bezuinigt op de verkeerde zaken, door na het bouwen van de site geen onderhoud te (laten) verrichten.

3. Het is niet altijd -of eigenlijk maar zelden- om de informatie te doen

Ik hoor regelmatig dat iemand zich niet kan voorstellen dat zijn site waarde voor anderen heeft. Hij heeft toch immers geen klantenbestanden of andere kostbare informatie? Alleen maar vijf pagina’s informatie over zijn bedrijf. Daar is toch niemand in geïnteresseerd?

Maar ook wanneer de informatie binnen en op je site niet interessant is voor hackers, heeft de site nog steeds waarde. Het gaat niet om je pagina’s, maar het gaat om de ‘motor’ daarachter. Jouw site kan -wanneer gehackt- gebruikt worden voor het versturen van SPAM, het verspreiden van malware of je site te gebruiken in een bot-netwerk om DDOS aanvallen op andere sites uit te voeren.

Een veilige WordPress website: Tien gouden regels!

In dit blogartikel bespreek ik een tiental manieren waarmee je de veiligheid van je WordPress website kan verhogen. Sommige zijn eenvoudig te implementeren, andere kosten wat meer moeite. Het is in ieder geval goed om met minimaal de meest eenvoudig te implementeren regels te beginnen.

En bedenk: Niet WordPress is onveilig, maar slecht beheer is onveilig.

1. Houd WordPress, thema’s en plugins altijd up-to-date!

Dit is eigenlijk de meest belangrijke regel. En ook de meest eenvoudig uit te voeren regel. Het is helaas ook de regel die het meest overtreden wordt. Het probleem met alle software die online staat is, dat er eigenlijk geen software is zonder beveiligingslekken. En hoe langer de software onveranderd online staat, des te groter de kans is, dat het beveiligingslek ontdekt en benut wordt.

Eén van de grote voordelen van WordPress is dat er letterlijk miljoenen WordPress professionals zijn die met dit CMS werken. En dus ook miljoenen mensen dagelijks speuren naar mogelijke veiligheidsproblemen met WordPress, WordPress thema’s en WordPress plugins.

Dus die potentiële gaten worden meestal snel gevonden en gedicht. Het is dus zaak regelmatig de kern van WordPress en de plugins en thema’s te updaten. Vergeet geen back-up te maken voor je dit doet!

Het regelmatig updaten van je plugins is in principe niet veel werk. Maar wanneer je niet dagelijks met je website werkt, is dit wel typisch iets wat je makkelijk vergeet. Het is mogelijk om plugins op ‘auto-update’ in te stellen. Dat is beter dan niet updaten, maar het behelst nog steeds een ander gevaar. Want bij een update kan er altijd iets mis gaan: Door een foutje in een plugin, of een conflict met een andere plugin gaat je site down. Om dit soort ellende te voorkomen biedt WordPression een beheersdienst voor je website aan, waarbij backups, updates en een regelmatige controle met betrekking tot de beschikbaarheid van je site gewaarborgd worden.

2. Gebruik alleen betrouwbare plugins en thema’s

WordPress is leuk en lekker voordelig. Tot op zekere hoogte. Want hoewel er letterlijk duizenden gratis plugins voor WordPress zijn, zal je wanneer je een commerciële website hebt toch af en toe behoefte hebben aan een ‘premium plugin’. En zo’n ‘premium plugin’ kost meestal van enkele tientjes tot enkele honderden euro’s per jaar.

En al snel komt de verleiding hier op te gaan besparen. Kan ik die plugin ergens anders niet goedkoper krijgen?

En al snel kom je aan bij sites waar je die éne plugin die je wilde ineens een fractie kost van wat je ervoor betaald had. Of sterker nog, voor een relatief klein bedrag per maand of jaar kan je honderden premium plugins onbeperkt downloaden!

Dit zijn echter meestal zogenaamde ‘nulled’ plugins, plugins waarbij de controle op licentiecode in de programmatuur is aangepast, zodat je geen licentie meer hoeft te hebben. Het probleem is echter, dat je geen flauw idee hebt, wat er nog meer aangepast kan zijn. Net zo eenvoudig als een licentiecontrole kan worden aangepast, kan ook een ‘achterdeurtje’ worden ingebouwd. Lees meer hierover in mijn artikel over nulled plugins.

3. Gebruik sterke wachtwoorden en tweefactorauthenticatie (2FA)

WordPress dwingt geen sterke wachtwoorden af, maar gelukkig zijn er wel plugins die dat wel doen. Een plugin zoals bijvoorbeeld de ‘Password Policy Manager‘ van miniOrange. Hiermee kan je de ‘bijzondere tekens’ instellen die minimaal in een wachtwoord voor moeten komen, maar kan je de gebruiker ook dwingen regelmatig zijn wachtwoord aan te passen. Als je deze plugin wilt uitproberen, kan dat op TasteWP.

Voor 2FA is ‘Two Factor’ van WordPress mijn favoriet: Eenvoudig, makkelijk te installeren en effectief. En ook deze plugin kun je in TasteWP proberen.

Door 2FA te gebruiken, kan je hacken via passwords aanzienlijk verminderen. Ook dit is een manier om een meer veilige WordPress website te krijgen, met een geringe inspanning.

4. Beperk het aantal beheerdersaccounts

Wanneer je de huisdeursleutel aan iedereen die een keer bij je in huis is geweest geeft, dan kun je er gif op innemen, dat vroeg of laat iemand daar misbruik van maakt.

Geef alleen de ‘admin’ rol aan mensen die ook daadwerkelijk regelmatig ‘admin’ taken uitvoeren. Niet aan Pieter, omdat hij nu eenmaal de eigenaar van het bedrijf is, maar eigenlijk alleen maandelijks een blogpost schrijft. Niet aan Ad, omdat zijn naam nu eenmaal met dezelfde letters begint, en niet aan Joke die nu al een half jaar niet meer bij het bedrijf werkt.

Iedere admin is een potentieel risico. Niet alleen omdat de persoon zelf iets fout zou kunnen doen, maar ook omdat ieder extra wachtwoord een extra veiligheidsrisico is.

En hoe zit dit dan met mensen die tijdelijk admin rechten nodig hebben. Bijvoorbeeld bij technische problemen die je zelf niet op kan lossen, en waar iemand anders toch echt naar moet kijken?

Elementor heeft een eenvoudige plugin gemaakt, de Temporary Login plugin,waarmee je een login URL met een ‘verloopdatum’ aan kan maken. Heb je bijvoorbeeld een technisch probleem en je wilt dat WordXPression hier voor je naar kijkt, dan geef je -bijvoorbeeld- een ‘verloopdatum’ van een dag na vandaag, maakt een inlog-url en stuur die per mail. Wil je het eerst een keer uitproberen, kan dit natuurlijk op TasteWP.

5. Gebruik een veilige hostingomgeving

Een goede beveiliging begint op server niveau. In het bijzonder wanneer je een ‘shared hosting’ account hebt, het type account wat vrijwel iedere hoster standaard aanbiedt, kan het ‘lek’ op één website een toegangspoort bieden tot alle accounts.

Wanneer veiligheid van het grootste belang voor je is, en je bent bereidt extra voor die veilighied te betalen, kies dan altijd voor een VPS. Omdat een VPS geen resources met andere accounts deelt, kan je dus alleen door je eigen ‘falen’ in de problemen komen, niet door het falen van anderen die toevallig gebruik maken van dezelfde server.

Een aantal minimum eisen die je aan je hosting account moet stellen:

• Minimaal dagelijkse backups
• Firewall, die je zelf in kan stellen (welke poorten wel en niet open)
• Malware scans
• Regelmatige updates
• Moderne PHP versies, liefst ‘oude’ PHP versies verwijderd -speciaal op shared hosting omgevingen.

6. Maak regelmatig back-ups

De vraag is niet of er iets misgaat, maar wanneer. En hoe ernstig de gevolgen zijn. Vroeg of laat overkomt het iedereen: Je moet een backup terug zetten. En dan kun je er maar beter één hebben. En liefst een recente ook.

Echter, de éne backup is de andere niet. En om te voorkomen, dat je onverwacht toch niet de backup hebt die je nodig hebt, is het belangrijk goed de verschillen te begrijpen.

De systeem-backup

De systeem-backup is een back-up van het gehele systeem. Dus met alle software, data… alles. Dat is van levensbelang wanneer je server het begeeft, maar je hebt er weinig aan, wanneer je na het installeren van een plugin merkt, dat je een backup terug moet zetten.

De account-backup

Een account backup is een backup van je gehele account. Wanneer je binnen dat account meerdere websites mag hebben, wil dat dus zeggen, dat alle websites dus in deze backup voorkomen. Evenals mogelijk, indien je email ook via het account gaat, je email.

Wanneer je een website van enkele dagen terug wilt herstellen, houd er dan rekening mee, dat je email die sinds die tijd verzonden is niet meer terug zal vinden in je email account. Ook zullen andere websites binnen dat account terug gaan naar de ‘oude’ versie van je website.

De website backup

Voor de continuïteit van je website is de website backup de meest belangrijke. Het is ook de meest simpele. Jouw website bestaat in principe uit de bestanden voor je website (software en content) en de database.

Wanneer je hostingprovider aangeeft, dat er ‘dagelijkse backups’ worden gemaakt is het belangrijk te weten waarvan. Dat hij dagelijkse systeembackups maakt is leuk, maar dat zal je niet verder helpen, wanneer je een backup terug wilt zetten na het mislukken van je laatste plugin update. Heb je meerdere websites binnen hetzelfde account, zal je ook weinig hebben aan je account-backup.

Incrementele backups

Iets wat ook belangrijk is om bij stil te staan, is een dagelijkse backup goed is voor een website waar weinig aan verandert. Heb je een druk bezochte webshop met enkele duizenden bestellingen per dag, dan heb je weinig aan een dagelijkse backup. Wanneer om 3 uur ‘s nachts een backup wordt gemaakt en om 17 uur er -na 5.000 bestellingen- iets gebeurt, waardoor een backup teruggezet moet worden, ben je na het terugzetten van de backup 5.000 bestellingen kwijt. Heb je 5 bestellingen per dag, dan kan je aan de hand van de bestelbevestigingen per email die orders nog wel toevoegen. Maar dat doe je liever niet met 5.000 bestellingen.

Het eerder genoemde WordXPression Service Contract biedt ondermeer de mogelijkheid om uurlijks een ‘incrementele backup’ te maken. Dat wil zeggen, dat dagelijks een complete backup wordt gemaakt, maar per uur de veranderingen gedurende het laatste uur worden opgeslagen. Zo is altijd terug te gaan tot een specifiek tijdstip waarom zo’n uurlijkse backup is gemaakt.

Wil je nog specifieker, en tot op de seconde terug kunnen gaan naar een specifieke versie van een backup zijn hier ook een aantal specifieke oplossingen voor. Houd er wel rekening mee, dat de oplossingen navenant kostbaar zijn. Maar mocht voor je een ‘uurlijkse backup’ nog niet voldoen, neem dan contact op en we maken een belafspraak om het één en ander eens door te spreken.

On-site, off-site en lokaal

Wanneer we het hebben over backups is er een drietal termen van belang:

• On-site : De backup wordt opgeslagen binnen hetzelfde account. Een voordeel is, dat dit bij het terugzetten van de backup de snelste methode is. Het nadeel is, dat de grootte van de backup meetelt in de maxium opslag van je account. En gaat er iets fout met de server, ben je ook de backup kwijt.
• Off-site : Dit wil zeggen, dat de backup ‘ergens anders’ is opgeslagen. Om hem terug te zetten, moet deze eerst verplaatst worden naar het account binnen de server. Het voordeel is dat het je geen schijfopslag kost. Een tweede voordeel is, dat een ‘off-site’ backup vaak ook fysiek off-site is. De backup is opgeslagen in een ander datacentrum dan de site zelf. Het nadeel is, dat het langer duurt deze terug te zetten.
• Lokaal : De backup staat bij jou. Waarschijnlijk ook gedownload vanuit de website. In principe is een lokale backup een bijzonder soort off-site backup. Eén die je zelf helemaal onder controle hebt.

7. Beveilig het inlogscherm

Er zijn veel manieren waarop je site aangevallen kan worden, maar een heel populaire manier is door brute force of slimme trucs gewoon via een gebruikersnaam en login in te loggen.

Er zijn diverse plugins beschikbaar om dit te doen, en binnenkort komt er een blogartikel waarin diverse plugins die je inlogpagina beschermen vergeleken worden. Wil je op de hoogte blijven, schrijf je dan in voor de nieuwsbrief onder aan deze pagina.

8. Controleer regelmatig op verdachte activiteiten

En dat is gemakkelijker gezegd dan gedaan. Want hoe weet je als leek welke activiteiten verdacht zijn? En hoe reageer je daarop? Dit is iets waarover ik op zichzelf een heel blogartikel kan schrijven. Ook dit is een artikel wat je in de nabije toekomst mag verwachten. Schrijf je in voor de nieuwsbrief om op de hoogte te blijven.

9. De botte bijl: Maak de plugins en themes directories ‘read only’

Deze oplossing is niet voor iedereen. Maar het is wel een manier om veel hack-pogingen te slim af te zijn. Je moet iets van het bestandssysteem van Linux begrijpen en je moet niet echt bezwaar hebben tegen behoorlijk wat extra werk. Maar als je voor ‘veiligheid voor alles’ kiest, maak je hier wel heel grote stappen.

Veel malware speciaal gericht op WordPress maakt gebruik van eenzelfde methode. Via ‘code injection’, het aanroepen van ‘externe’ code door fouten in een script van de WordPress code, een plugin of een thema, worden bestanden in een plugin of thema overschreven door ‘foute’ bestanden, of worden ‘foute’ bestanden toegevoegd aan de bestanden van een plugin.

Omdat je in WordPress online plugins kunt updaten vanuit WordPress zelf moet WordPress update rechten hebben in de themes en de plugins folders.

Ontneem je die rechten, kan malware geen code meer plaatsen binnen die folders. Maar kan jij ook geen nieuwe plugins en thema’s meer installeren of updaten.

Maar je moet toch kunnen updaten?

Inderdaad. Maar dat doe je via een FTP programma. Zelf zou ik FileZilla aanbevelen. Maar dat is gewoon mijn persoonlijke smaak.

Het is een hoop extra werk, want je moet bijhouden welke plugins zijn geupdate, deze downloaden, lokaal uitpakken en weer uploaden. Een hoop werk dus. Maar het kan eenvoudiger.

10. Gebruik Bedrock voor een professionelere en veiligere WordPress Structuur

Ik heb in het verleden al eens een artikel over Bedrock geschreven. En in de toekomst zal er nog meer verschijnen. Zoals bijvoorbeeld deze pagina, waar Bedrock nader op wordt uitgelegd.

Eén van de grootste beveiligingsproblemen van WordPress is de kwetsbaarheid van bestanden omdat zowel de content als de code zich direct onder de ‘webroot’ bevinden. Bedrock pakt dat allemaal iets anders aan.

In basis is Bedrock gewoon de WordPress code, maar door de bestanden slimmer in te delen en een aantal slimme tools te gebruiken, is het gehele systeem een stuk veiliger.

Veel conflicten worden voorkomen door het gebruik van Composer

De basis van Bedrock is Composer.

Composer is een ‘PHP Package Manager’. Je kan een ‘package’ misschien het best vergelijken met een plugin. Maar het werkt toch ietsje anders. Omdat in een Composer package meer informatie is opgeslagen over de onderlinge afhankelijkheden. Laat me dat eens op een eenvoudige manier duidelijk maken.

Wanneer ik in WordPress twee plugins heb, die allebei -bijvoorbeeld- de Mollie API aan willen roepen, dan hebben beide plugins de PHP code voor de Mollie PHP ‘ingesloten’.

Wordt dezelfde plugin als ‘package’ aangeleverd, dan werkt het iets anders. Geen van beide packages zal de PHP Mollie API ‘ingesloten’ hebben, maar ze zullen naar een apart Composer package met die API verwijzen. Bovendien zullen beide plugin-packages aangeven, welke minimum versie van dat Mollie-package ze nodig hebben.

Op deze manier worden veel plugin conflicten voorkomen.

Versiebeheer via Git

Git is een versiebeheer systeem. Het houdt de veranderingen in de code bij en maakt het eenvoudig terug te gaan naar bepaalde versies. Blijkt een systeem na een update niet meer te werken, kan je makkelijk terug naar een vorige versie zonder een backup terug te hoeven zetten.

Het maakt staging plugins zoals besproken in mijn artikel hierover overbodig.

Wanneer we de situatie zoals beschreven in punt 9 vergelijken met Bedrock, dan zijn de belangrijkste verschillen ten voordele van Bedrock:

1. Je hoeft zelf niet in de gaten te houden welke plugins zijn geupdate, dat doet Composer voor je.
2. Je hoeft niets down te loaden, uit te pakken en weer up te loaden. Dat doen Git en Composer in een perfecte samenwerking voor je.
3. Je kan terug naar een eerdere situatie zonder backups terug te hoeven zetten.

Er kleeft echter ook een aantal nadelen aan:

1. Het opzetten van een WP Bedrock site kost meer tijd en bredere kennis.
2. Het beheren van een WP Bedrock site is complexer
3. De staging veronderstelt dat in de verschillende stages ook daadwerkelijk getest wordt, wat weer tijd kost, anders is de staging betekenisloos.

Bedrock is vooral interessant voor bedrijven met grote bezoekersaantallen, websites met veel maatwerk of websites met een hoge omzet. Denk je dat jouw site tot die categorie behoort, neem dan eens contact op, om het één en ander te bespreken.

Blijf op de hoogte!

Wil je op de hoogte blijven, schrijf je dan hieronder in voor de nieuwsbrief van WordXPression.