De afgelopen maanden zien wij een duidelijke toename van aanvallen en overbelastingen op WordPress-websites en WooCommerce-webshops. Het gaat daarbij niet om uitzonderingen. Het is een gestage stroom geworden, en de oorzaak is bijna altijd dezelfde: achterstallig onderhoud, verouderde plugins of een configuratie die nooit is aangepast nadat de site live ging. Wij grijpen in waar dat nodig is om onze servers en de andere klanten daarop te beschermen, maar we willen nog eens duidelijk maken waar de verantwoordelijkheid ligt.

Het beheer en onderhoud van een website is de verantwoordelijkheid van de eigenaar, of van de partij die de website heeft gebouwd en beheert. Dat geldt voor de software, voor de plugins en thema's, en ook voor de inhoud die op de site wordt geplaatst. Wij leveren de hostingomgeving en beschermen die naar beste vermogen, maar wij hebben geen zicht op en geen zeggenschap over wat er binnen een website gebeurt. Wij zijn daar dan ook niet verantwoordelijk voor.

De verandering zit in het tempo. In juli van dit jaar werd een kwetsbaarheid in WordPress bekend die twee losse fouten combineerde tot een volledige overname zonder dat er ingelogd hoefde te worden. Het bijzondere eraan was niet de fout zelf, maar hoe die gevonden werd: een onderzoeker gebruikte daar een AI-model voor, en had er ongeveer tien uur voor nodig. Aanvallers deden vervolgens hetzelfde met dezelfde middelen en hadden binnen enkele uren werkende exploits. Waar er vroeger dagen zaten tussen het bekend worden van een lek en de eerste massale aanvallen, zijn dat nu uren.

Dat betekent iets heel praktisch voor iedere sitebeheerder. Een update die je "volgende week wel even doet" is geen uitgestelde taak meer, maar een openstaand risico. En het raakt niet alleen WordPress: hetzelfde geldt voor Joomla, Drupal, TYPO3, Magento en elk ander CMS.

De meeste beheerders werken hun WordPress- of WooCommerce-installatie nog wel bij. Waar het misgaat, zit vaak een laag dieper. Een plugin die netjes op de laatste versie staat maar al drie jaar geen enkele update meer heeft gekregen, is geen veilige plugin. Die is verlaten. Hetzelfde geldt voor thema's die door de maker zijn stopgezet, of voor premium-plugins waarvan de licentie is verlopen en die daardoor geen beveiligingsupdates meer ontvangen.

Controleer dus periodiek of wat je gebruikt überhaupt nog onderhouden wordt. Een plugin die al langere tijd stil ligt of als niet-getest met recente WordPress-versies staat aangemerkt, hoort vervangen te worden voordat er iets misgaat, niet erna.

Over illegaal verkregen software zijn wij kort: nulled plugins en thema's worden op onze omgeving niet getolereerd. Vrijwel elke gekraakte variant bevat verborgen code, en dat is geen vermoeden maar een structureel patroon. Wie zoiets installeert nodigt de aanvaller zelf binnen, en brengt daarmee ook andere klanten op dezelfde server in gevaar.

Binnen Plesk vind je onder Security Measures een reeks concrete aanbevelingen voor WordPress-installaties, met uitleg per punt. Loop die door en pas toe wat van toepassing is, maar maak altijd eerst een backup voordat je iets wijzigt.

Daarnaast zijn er goede beveiligingsplugins beschikbaar. Wordfence is de bekendste, maar Solid Security, Sucuri Security, All-In-One Security en Patchstack zijn eveneens serieuze en betrouwbare opties. Welke je kiest is minder belangrijk dan dat je er één actief gebruikt en de meldingen daadwerkelijk leest.

Een deel van de problemen die wij tegenkomen is geen inbraak, maar overbelasting. Vooral WooCommerce-webshops zijn hier gevoelig voor. Filters op categoriepagina's zijn vaak onbeperkt combineerbaar, waardoor er tienduizenden unieke adressen ontstaan die geen van alle uit cache geserveerd kunnen worden. Geautomatiseerde bezoekers lopen die combinaties systematisch af en leggen zo een complete server plat, zonder dat er ook maar iets gehackt hoeft te worden.

Dat is te voorkomen met de juiste instellingen. Zorg dat filterpagina's niet geïndexeerd worden, begrens het aantal producten dat een bezoeker in één keer kan opvragen, sluit parameterpatronen uit in je robots.txt en zet caching goed op. Ook dit hoort bij het beheer van de webshop en ligt bij de eigenaar of diens webbouwer, niet bij ons.

Op al onze shared- en resellerservers draaien meerdere beschermingslagen: een web application firewall, malwarescanning, bescherming tegen brute force en geautomatiseerde blokkades tegen bekende kwaadaardige adressen en AI-crawlers. Die vangen veel af, en dagelijks meer dan de meeste klanten zich realiseren.

Wat zulke bescherming niet kan, is onderscheid maken tussen een echte bezoeker en een geautomatiseerd verzoek dat er precies hetzelfde uitziet. Een filteraanvraag op een webshop is nu eenmaal een normaal verzoek aan een pagina die de shop zelf publiceert. En geen enkele firewall repareert een plugin met een bekend lek erin.

Wij vragen daarom van iedere klant met een CMS-website hetzelfde: houd hem actueel, controleer periodiek wat je draait, en zorg dat de beveiliging op orde is. Twijfel je of dat bij jou goed geregeld is, neem dan contact op met de partij die je website heeft gebouwd. Kun je die niet meer bereiken, dan is dat op zichzelf al een signaal dat er iets moet gebeuren.

Kom je er zelf niet uit, dan kunnen wij op verzoek een WordPress- of WooCommerce-installatie voor je opschonen of beter beveiligen. Dit gebeurt op basis van beschikbaarheid en is afhankelijk van de werkdruk van onze technici, en wordt uitgevoerd tegen de op dat moment geldende tarieven voor technische werkzaamheden. Het betreft eenmalige werkzaamheden en geen doorlopend onderhoud: na afronding blijven het beheer, de updates en de beveiliging van de website de verantwoordelijkheid van de eigenaar of beheerder.

Zoek je juist wel iemand die het onderhoud structureel oppakt, dan kunnen wij je in contact brengen met partijen die periodiek onderhoud uitvoeren en de beveiliging van je WordPress- of WooCommerce-website regelmatig controleren. Laat het ons weten via een supportticket, dan denken wij met je mee. De uiteindelijke overeenkomst sluit je rechtstreeks met de betreffende partij.

Op grond van onze algemene voorwaarden zijn wij gerechtigd maatregelen te treffen wanneer een website of server de beschikbaarheid, stabiliteit of veiligheid van onze infrastructuur aantast, dan wel een gevaar oplevert voor bezoekers of derden. Hieronder vallen in elk geval buitensporig hoge serverbelasting, het verspreiden van malware of phishing, en installaties waarvan is vastgesteld dat zij zijn gecompromitteerd.

Deze maatregelen kunnen bestaan uit het beperken van de beschikbare capaciteit, het blokkeren van specifiek verkeer, of het geheel of gedeeltelijk buiten werking stellen van de betreffende website. Gaat de verstoring uit van een virtuele server, en raakt deze daarmee de werking van het onderliggende fysieke systeem of van andere klanten daarop, dan kunnen dezelfde maatregelen op die gehele virtuele server worden toegepast. Wij stellen de klant hiervan zo spoedig mogelijk in kennis. In spoedeisende gevallen geschiedt dit achteraf.

De maatregel wordt opgeheven zodra de klant de onderliggende oorzaak heeft weggenomen. Het herstellen en beveiligen van de website of server berust bij de klant of de door hem aangewezen beheerder.

Interessant leesmateriaal:

• Hackers are mass-exploiting two WordPress flaws, and AI found the way in
• WordPress took a beating this past month...
• An AI found a $500k WordPress exploit in 10 hours for $25
• 4 Overlooked WordPress Security Vulnerabilities
• WordPress Security in the Age of AI