Rate limiting op Cloudflare Pro: login, checkout en zoeken

Een bot probeert 10.000 wachtwoorden op je klantlogin. Een andere test gestolen kaarten op je checkout. Een derde scrapt je catalogus tot je server zweet. Alle drie hebben iets gemeen: een enkel IP-adres doet veel te veel requests. Rate limiting is het gereedschap daartegen.

Op Cloudflare Pro heb je er twee. Dit artikel laat zien wat je met twee regels kunt, wat Pro niet kan en waar je ze het best inzet. Voor het bredere botverhaal: WAF en bot-bescherming voor je webshop.

Wat Pro je geeft

Uit Cloudflares overzicht van de limieten per plan:

Twee dingen vallen op. Je telt op IP-adres en niet op iets slimmers. En je kunt niet op de HTTP-statuscode tellen. Dat betekent: je telt alle requests naar een pad, niet alleen de mislukte logins.

Wat dat betekent voor de praktijk

Een mislukte-login-regel ("blokkeer na vijf foute logins") kan op Pro niet. Je telt wel het aantal POST-achtige aanvragen naar het loginpad per minuut. Op Pro kies je een limiet die een mens nooit haalt en een bot snel overschrijdt.

Daarnaast: kantoren en mobiele netwerken delen IP-adressen. Zet je de limiet te laag, dan blokkeer je tien collega's omdat één bot-achtig gedrag vertoont. Daarom werkt een ruime marge beter dan een scherpe.

Regel 1: login en wachtwoordreset samen

Gebruik de ene regel voor alle accountpaden die bots aanvallen. Voor Magento zijn dat de loginpaden van klanten:

• /customer/account/login
• /customer/account/loginPost
• /customer/account/forgotpassword

Een voorbeeld van een expressie:

(starts_with(http.request.uri.path, "/customer/account/login")
 or starts_with(http.request.uri.path, "/customer/account/forgotpassword"))

Stel de periode op een minuut en de limiet op een aantal dat een normale klant nooit haalt, bijvoorbeeld tien. Kies als timeout een tijd die bots afremt zonder echte klanten lang te stoppen, bijvoorbeeld een kwartier.

Let op: de exacte paden kunnen verschillen per thema, Hyvä-checkout of module. Controleer in je netwerkpanel welke URL's je login echt aanroept.

Regel 2: checkout en betaalacties

Carding is de aanval waarbij iemand met gestolen kaarten test of ze werken. Het patroon is veel pogingen vanaf weinig IP's. Gebruik de tweede regel op het pad waar betaalpogingen binnenkomen. Welk pad dat is, hangt af van je checkout. Open je netwerkpanel tijdens een testbestelling en kijk welke POST-verzoeken er gaan.

Een lage limiet per minuut werkt hier goed. Een mens plaatst niet vijftien keer per minuut een bestelling. Zorg dat je PSP-webhooks buiten deze regel vallen. Zie Super Bot Fight Mode zonder je betalingen te breken.

En de zoekfunctie?

Scrapers en zoekbots maken je zoekfunctie duur. Met slechts twee regels moet je kiezen. Is scraping je grootste probleem, dan zet je je tweede regel op /catalogsearch/. Is carding je grootste risico, dan wint de checkout. Heb je meer nodig, dan is Business een serieuze overweging. Zie Free, Pro of Business.

Kies de juiste actie

Op Pro kies je uit blokkeren of uitdagen. Voor login en checkout in de browser is een challenge een vriendelijker stap dan een harde blokkade. Voor API-verkeer is blokkeren de enige werkende optie, want een challenge kan geen pagina tonen aan een script.

Combineer rate limiting met andere lagen

Rate limiting is één laag. Een goed gelaagd systeem bestaat uit:

1. Bot-bescherming die geautomatiseerd verkeer herkent.
2. Rate limiting op de gevoelige paden.
3. Een captcha-alternatief op formulieren. Zie Cloudflare Turnstile.
4. 2FA en sterke wachtwoorden bij de klant.

Controleer of het werkt

Bekijk na uitrol in de events hoeveel verkeer de regel raakt en van wie. Is het vooral een paar IP's met honderden requests, dan werkt hij. Zie je veel verschillende IP's die er één of twee keer op vallen, dan zit je limiet te laag of is het geen bot.

Hoe een aanvaller je limiet ziet

Een rate limit is alleen nuttig als hij past bij hoe aanvallers werken. Denk even mee.

• Brute force op één account. Veel pogingen vanaf één IP. Een IP-limiet vangt dit.
• Credential stuffing. Pogingen met gelekte combinaties, verdeeld over veel IP-adressen, vaak een of twee per IP. Een IP-limiet raakt dit nauwelijks. Daarvoor heb je bot-detectie, challenges en monitoring van mislukte logins nodig.
• Carding. Kleine testbetalingen om gestolen kaarten te valideren. Vaak via de checkout of een betaalformulier. Beperk betaalacties en let op patronen in mislukte betalingen.
• Scraping. Veel verzoeken naar producten of zoek. Een limiet per IP kan helpen, maar een aanvaller met veel IP's omzeilt dat.

Het inzicht: rate limiting op IP-basis (wat Pro biedt) is een bruikbare eerste laag, geen volledige oplossing. Het is vooral nuttig tegen simpele, snelle aanvallen.

Een waarde kiezen

Een te lage limiet raakt echte klanten, een te hoge doet niets. Zo vind je een redelijke waarde:

1. Kijk in je logs naar het normale gedrag. Hoeveel loginpogingen doet een echte klant per minuut? Meestal een of twee.
2. Kies een grens ruim boven dat normale gedrag. Een kantoor of school met één uitgaand IP kan meerdere legitieme gebruikers hebben.
3. Kies een actie die een echte gebruiker kan herstellen: Managed Challenge boven een harde blokkade.
4. Kies een korte timeout. Een echte klant moet snel weer verder kunnen.

Controleer in de Cloudflare-documentatie de actuele limieten voor periode en timeout van jouw plan. Die kunnen veranderen.

Een rustige uitrol

Let op campagnemomenten: een flinke mailing of een tv-spot kan veel legitiem verkeer tegelijk brengen. Check vooraf of je limieten dat aankunnen, vooral op zoek- en productpagina's.

Aanvullende maatregelen op je eigen server

De platformgrens is een deel van het plaatje. Voeg toe wat jij zelf in de hand hebt:

• Accountvergrendeling of vertraging na mislukte logins in de applicatie. Dit werkt per account, niet per IP, en pakt dus ook verspreide aanvallen aan.
• 2FA voor beheerders. Zie Magento admin beveiligen.
• Meldingen bij ongebruikelijke inlogpogingen voor klanten.
• Alerts op pieken in mislukte logins of betalingen.

Meten of het werkt

Kijk niet alleen naar het aantal geblokkeerde verzoeken. Kijk ook naar:

• Het aantal mislukte logins per uur voor en na de regel
• Het aantal mislukte betalingen en geweigerde kaarten
• Het aantal klachten over geblokkeerde toegang
• De serverbelasting tijdens een piek

Daalt de belasting en blijft de conversie gelijk, dan werkt de regel. Meer over bot-aanvallen lees je in webshop beveiligen tegen bots en op onze pagina webshop security.