Hoe wapen je je wél tegen botstorms op je WooCommerce-webshop?

De laatste tijd zien we op WooCommerce-webshops een recente vorm van misbruik: botstorms. Geen klanten, maar georganiseerde bots die je catalogus leegtrekken via filter-URL’s — hard genoeg om de shop plat te leggen.

Even kort: wat is een IP-adres?

Elke bezoeker op internet heeft een IP-adres: een soort huisnummer waarmee je server weet “waar komt dit verzoek vandaan?”. Bijvoorbeeld 203.0.113.42.
Een gewone bezoeker komt op een bepaald moment doorgaans vanaf één IP-adres. Bij een botstorm komen er honderden verschillende huisnummers tegelijk binnen — alsof er ineens vanuit de hele wereld tegelijk op je deurbel wordt gedrukt.

Vroeger was een aanval vaak brute force: vanaf één IP-adres heel vaak hetzelfde proberen, bijvoorbeeld wachtwoorden raden tot er eentje lukt. Dan blokkeer je dat ene adres, en het is stil.

Nu werkt het anders — en dat is geen toeval. De bots komen vanaf veel unieke adressen tegelijk, verspreid over de hele wereld. Precies zodat klassieke blokkades per huisnummer of per buurt tekortschieten. Blokkeer je er één, dan zijn er meteen tientallen nieuwe.

Waarom “dit hele blok dicht” niet meer werkt

Veel beveiliging denkt nog in blokken van adressen. Technisch kun je bijvoorbeeld een /24 blokkeren: een blok van 256 opeenvolgende IPv4-adressen. Zie het voor het gemak als een buurt — bijvoorbeeld alles van 203.0.113.1 tot en met 203.0.113.254.

Als alle rotzooi uit die ene buurt komt, kun je die dichtdraaien. Handig.

Bij de aanvallen die we nu zien, komen de bots niet uit één buurt. De ene zit op 203.0.113.42, de volgende op een heel ander netwerk in een ander land. Twintig of honderd “buurten” tegelijk. Dan helpt “één blok dicht” niet meer. Elke bot doet maar een paar klikken; samen leggen ze je shop plat. Die spreiding over unieke IP-adressen is onderdeel van de aanpak — geen bijeffect.

Vaak komen die adressen uit hostingnetwerken, VPN’s of proxynetwerken. Maar ook gewone consumentenaansluitingen kunnen in zo’n zwerm zitten. Alleen naar het soort IP-adres kijken is daarom niet genoeg — gedrag en patronen zeggen meer.

Wat zo’n storm met je shop doet

Op shops die we hosten zagen we pieken van rond de zeshonderd filtercombinaties per minuut. Dat is geen “drukke dag” en geen zoekmachine die even bij je langsloopt. Dat gaat ver over elke redelijke rate limit heen: honderden unieke, zware pagina’s per minuut, zonder plaatjes of opmaak — puur scrape-gedrag.

Denk aan: “toon alle rode jassen, maat M, merk X, onder €50” — steeds een iets andere filter. Voor een klant is dat handig. Voor de webserver is het iets heel anders dan een gewone artikelpagina.

Een normale productpagina kan vaak uit de page cache komen: de server heeft die pagina al klaarliggen en geeft hem in een fractie van een seconde terug, zonder WordPress opnieuw aan het werk te zetten. Een filterpagina is uniek (andere combinatie = andere pagina) en kost honderden keren meer processorkracht, geheugen en databasetijd: WordPress moet nadenken, de database moet zoeken, en PHP (de programmeertaal waarin WordPress/WooCommerce draait) moet de hele pagina opnieuw vanaf nul maken.

Een echte klant laadt daarna ook plaatjes en CSS (de opmaak: kleuren, lettertypes, layout). Deze bots doen dat niet: ze vragen alleen die zware filterpagina’s op. Alsof iemand alleen de keuken leeghaalt — maar wél 600 keer per minuut.

Gevolg: de server raakt vol. Echte klanten krijgen time-outs. Orders haperen. En Google staat in dezelfde file.

Waarom richten ze zich juist op filters?

Filters maken een webshop aantrekkelijk voor scrapers: er zijn bijna eindeloos veel combinaties. Kleur × maat × merk × prijs × sortering levert duizenden of honderdduizenden adressen op — ideaal om producten, prijzen en voorraad systematisch te graaien.

Google waarschuwt zelf dat faceted navigation (navigatie via filters) crawlers kan laten verdwalen in enorme URL-ruimtes. Dat probleem bestaat al langer. Wat wél recent is — en wat wij op shops zien — is iets anders: gedistribueerd misbruik. Zeshonderd filterhits per minuut, vanaf een zwerm unieke IP-adressen die niet in één buurt vallen, zonder assets, met nep-browsers. Dat is geen verdwaalde Googlebot. Dat is een aanval op je capaciteit én op je catalogus.

Daarnaast groeit het ecosysteem van agressieve bots: AI-crawlers, prijsvergelijkers, SEO-tools en pure scrapers. En apart daarvan blijven de klassiekers: wachtwoorden forceren, lekken zoeken, fraude. Maar de filterstorm van dit kaliber is misbruik — en daar moet je als hosting ook zo naar handelen.

Waarom “gewoon een grotere server” tekortschiet

De verleiding is groot: grotere server, meer rekenkracht, “even bijboeken”. Extra capaciteit kan helpen bij pieken — dat hoort bij een gezonde shop. Maar alleen opschalen lost dit misbruik niet op. Je koopt meer capaciteit, terwijl de aanvallers het duurste deel van je applicatie blijven raken — en zelf goedkoop nóg meer IP’s bijhuren. Veel effectiever is het om dat verkeer af te remmen vóórdat WordPress en WooCommerce het zware werk gaan doen.

Een security-plugin in WordPress komt vaak te laat: die begint pas te kijken als de zware pagina al (bijna) wordt opgebouwd.

Hoe wij dat bij XSU aanpakken (in drie lagen)

We combineren maatregelen op de server — automatisch, realtime — zodat jij niet handmatig IP’s hoeft bij te houden.

1. Slechte adressen zo vroeg mogelijk tegenhouden

Op de server houden we lijsten bij met bekende slechte huisnummers, en blokkeren we adressen die zich al misdroegen — vooraf, vóór WordPress aan het werk gaat. Dat scheelt processorkracht bij bekende rotzooi en bij verkeer dat we al hebben leren herkennen.

Tegen een moderne filterstorm is “één buurt dichtdraaien” alleen niet genoeg — daarom komt laag 2. Wel zorgen we dat jij als beheerder en nette zoekcrawlers niet per ongeluk buitengesloten worden.

2. Verdachte filters herkennen — ook over veel IP’s heen

Filters zijn normaal. Scrapers gebruiken ze anders. We beoordelen niet alleen het IP-adres, maar ook het verzoek zelf: welke filters worden gecombineerd, hoe de URL is opgebouwd, of browsergegevens logisch zijn, en of er een verwijzende pagina is (Referer: “waar kom je vandaan?”).

Geen enkel signaal is op zichzelf reden voor een blokkade — privacy-instellingen of apps laten de Referer bijvoorbeeld vaak weg. Juist de combinatie maakt een request verdacht. En als hetzelfde rare filterpatroon vanaf heel veel verschillende IP-adressen tegelijk binnenkomt, herkennen we dat als een zwerm — ook als die adressen niet in één buurt zitten. Precies dat is hoe deze aanvallen rate limits proberen te omzeilen.

Wordt het te gek, dan antwoordt de server met een 429: “even niet, te veel / te verdacht”. De zware shoppagina wordt niet opgebouwd. Bij twijfel liever een lichte check (een kort stapje dat een echte browser wél kan) dan meteen alles dichtdraaien. Ook dit gebeurt vooraf: WordPress en de database doen het zware werk niet.

Dat “even niet” is eerst alleen voor die ene poging. Blijft hetzelfde adres zich misdragen, dan kan een tweede laag het langer blokkeren (uren tot dagen) via fail2ban — een automatische “deurwaarder” voor lastige huisnummers. Niet elk 429 wordt zo’n ban (bij een zwerm doet elk adres vaak maar een paar pogingen — expres), maar hardnekkige rotzooi belandt wél in die langere blokkade.

Onder hoge load zetten we die lichte check eerder in, zodat de shop overeind blijft zonder eindeloos duurder te moeten worden.

3. Loginpogingen en klassieke aanvallen: realtime tijdens de aanval

Bij inloggen, oude WordPress-koppelingen, achterdeurtjes en jacht op geheime bestanden gaat het om bewust misbruik. De eerste pogingen zie je soms nog wél binnenkomen — anders kun je geen onderscheid maken tussen een typfout van jou en een bot die wachtwoorden probeert. Maar zodra het patroon duidelijk is, grijpen we direct in, terwijl de aanval nog loopt: dat huisnummer wordt geblokkeerd, zodat de rest van de storm niet meer doorloopt.

Dat is dus ook realtime — alleen niet “vooraf vóór de eerste klik”, maar realtime achteraf: seconden na misbruik, niet pas morgen als jij de logs opent. En zonder per ongeluk echte bezoekers te raken.

En Google dan?

Blokkeer je te hard, dan is je shop slechter vindbaar. Alleen de naam “Googlebot” in de browserregel zegt weinig: die is makkelijk na te maken. We zorgen dat legitieme zoekmachinecrawlers worden ontzien — onder meer door te controleren dat bekende Google-adresreeksen niet in onze blokkades belanden — terwijl filterzwermen van nep-browsers en scrapers hard worden aangepakt.

Wat levert het op?

Bij een filterstorm eindigt het gros van die misbruik-verzoeken in “even niet” of die lichte check — in plaats van volle, zware shoppagina’s. Echte klanten kunnen blijven browsen en bestellen. Snelheid en bereikbaarheid blijven haalbaar, ook als het buiten onrustig is.

Wat jij wél doet — en wat niet

Wél jouw taak: WordPress, thema en plugins bijhouden, sterke wachtwoorden, geen overbodige plugins. Dat voorkomt klassieke inbraken.

Niet realistisch zelf: een storm van honderden filtercombinaties per minuut, vanaf wisselende unieke IP-adressen, realtime afremmen zonder dat Google of klanten eronder lijden. Daarvoor heb je hosting nodig die dit misbruik automatisch en doorlopend afkapt — vóór het duur wordt. Handmatig adressen blokkeren of alleen een plugin installeren is hier geen doen.

Bij XSU zit die aanpak in onze hosting en optimalisatie — naast snelheid, updates en backups. Zodat jij je op je shop kunt richten, niet op de zoveelste botgolf.

Wil je weten of jouw webshop hier last van heeft? Neem contact op; we kijken graag kort mee.