Cloudflare WAF custom rules voor Magento: admin, REST en checkout

Managed Rules vangen bekende aanvallen. Custom rules vangen wat specifiek is voor jouw shop: jouw admin-pad, jouw koppelingen, jouw checkout. Op Cloudflare Pro heb je er 20. Dat is genoeg om een Magento-webshop flink dicht te zetten, als je ze bewust kiest.

Dit artikel geeft concrete voorbeelden met expressies, in volgorde van prioriteit. Ze zijn bedoeld als startpunt. Pas paden en IP-adressen aan op je eigen installatie en test ze eerst smal. De achtergrond bij Managed Rules staat in Cloudflare Managed Rules uitgelegd.

Wat je moet weten over custom rules op Pro

• 20 regels. Dat telt voor alle custom rules samen.
• Alle acties behalve Log. Je kunt niet "droog" draaien. Test met Managed Challenge op een smal bereik.
• Geen regex. Reguliere expressies zijn er pas vanaf Business. Gebruik contains, starts_with, ends_with en in.
• Volgorde telt. Regels worden op volgorde uitgevoerd. Blokkeert een eerdere regel een request, dan lopen de latere niet meer.

Zet een skip-regel voor vertrouwde bronnen bovenaan en je blokkeerregels daarna.

Regel 1: admin alleen vanaf bekende IP-adressen

Het admin-pad van Magento is configureerbaar. Gebruik je eigen pad, niet de standaard /admin. De regel:

(starts_with(http.request.uri.path, "/jouw-admin-pad")
 and not ip.src in {203.0.113.10 203.0.113.11})

Actie: Block. Dit is een van de sterkste maatregelen die je kunt nemen, mits je IP-adressen stabiel zijn. Werk je thuis of onderweg, gebruik dan een vaste VPN-uitgang. Zonder dat sluit je jezelf buiten. Zie ook Magento admin beveiligen.

Let op: dit werkt alleen als je server het echte IP-adres krijgt. Anders klopt ip.src wel in Cloudflare, maar je andere maatregelen niet.

Regel 2: gevoelige bestanden en mappen blokkeren

Je shop heeft nooit een reden om deze paden publiek te serveren:

(http.request.uri.path contains "/.git"
 or http.request.uri.path contains "/.env"
 or http.request.uri.path contains "/app/etc/"
 or http.request.uri.path contains "/var/log"
 or http.request.uri.path contains "/phpinfo"
 or ends_with(http.request.uri.path, ".sql")
 or ends_with(http.request.uri.path, ".bak"))

Actie: Block. Die paden hoor je ook al op serverniveau dicht te zetten. Dit is een tweede laag, voor als een configuratiefout je server toch iets laat serveren.

Regel 3: REST-API beperken tot wat je gebruikt

Magento's REST-API staat onder /rest/. Gebruik je die niet publiek, dan hoort ze niet publiek open te staan:

(starts_with(http.request.uri.path, "/rest/")
 and not ip.src in {198.51.100.20})

Actie: Block. Gebruikt je storefront zelf REST of GraphQL, of praat je ERP via een vast IP met je shop, dan zet je die bron in de uitzonderingslijst. Koppeling met meerdere systemen? Beperk dan per pad in plaats van alles dicht te zetten. Zie ook API-beveiliging voor e-commerce.

Gebruik hier Block, geen challenge. Een challenge-pagina kan niet worden getoond in een API- of AJAX-request. De aanroep faalt dan op een onduidelijke manier.

Regel 4: bots op wachtwoordresets en registratie

Aanmaken van accounts en wachtwoordreset zijn favoriet bij bots:

(http.request.method eq "POST"
 and (http.request.uri.path contains "/customer/account/create"
 or http.request.uri.path contains "/customer/account/forgotpassword"))

Actie: Managed Challenge, op de pagina-aanvraag. Voor het POST-verzoek zelf werkt rate limiting beter. Zie rate limiting op Cloudflare Pro.

Regel 5: landen waar je niet aan levert

Lever je alleen in Nederland en België, dan is uitdagen van verkeer uit andere landen een optie voor je admin en je API's:

(starts_with(http.request.uri.path, "/jouw-admin-pad")
 and not ip.src.country in {"NL" "BE"})

Gebruik dit niet op je volledige storefront zonder je klantenbestand te bekijken. Een Nederlandse klant op vakantie of een Duitse grensklant is ook een klant. Landfilters zijn grof. Ze houden bulkverkeer weg, geen gerichte aanvaller met een VPN.

Regel 6: zoekmachines en betaalproviders erdoor laten

Zet bovenaan een skip-regel voor wat nooit geblokkeerd mag worden. Cloudflare kent het veld cf.client.bot voor geverifieerde bots. Voor betaalproviders: skip de webhook-paden, en laat de applicatie de handtekening of het token valideren. Gebruik geen IP-lijst van een provider zonder te controleren dat die actueel en officieel is.

Hoe je 20 regels verdeelt

Een reservevoorraad is nuttig. Tijdens een aanval wil je snel een regel kunnen toevoegen.

Valkuilen

• Je sluit jezelf buiten. Test een admin-regel met je eigen IP in de lijst en houd een tweede toegangsweg achter de hand.
• Challenge op AJAX. Challenge-acties werken niet op verzoeken die geen pagina tonen.
• Pad niet exact. Gebruik starts_with voor een prefix. contains raakt ook ongewenste paden.
• Vergeten bij een migratie. Wissel je van admin-pad of IP's, dan breken je regels stil.

Een regel veilig uitrollen

Een custom rule die te streng is, kost je omzet. Rol elke regel daarom in drie stappen uit.

1. Schrijf de expressie en lees hem hardop terug. Klopt de logica? Een or waar een and hoort, is een klassieker.
2. Begin met een zachte actie. Managed Challenge, of Log als je plan dat toelaat (zie hierboven: lagere plannen kennen de Log-actie niet). Zet bij twijfel eerst een gelijkwaardige regel op een testomgeving.
3. Controleer de events na een paar dagen. Raakt de regel alleen wat je bedoelde? Pas dan naar Block.

Een regel testen zonder risico

Wil je zeker weten dat een IP-allowlist voor /admin goed werkt, test dan op deze manier:

• Open het admin-pad vanaf een toegestaan netwerk: moet normaal laden.
• Open het vanaf een mobiel netwerk (niet toegestaan): moet geblokkeerd of uitgedaagd worden.
• Controleer dat andere paden niet geraakt worden, zoals de storefront en de zoekfunctie.
• Test ook paden die op /admin lijken, zoals een aangepaste admin-URL of een extensie die zijn eigen backendpaden gebruikt.

Een veelgemaakte fout is een regel die ook de Ajax-verzoeken van een beheerpagina blokkeert, waardoor beheerders met een halfladen scherm zitten.

Volgorde en uitzonderingen

Regels worden in een bepaalde volgorde beoordeeld. Een Skip-regel voor betrouwbaar verkeer (bijvoorbeeld de IP's van je betaalprovider of de crawlers van een zoekmachine) moet vóór de blokkades staan. Leg daarom je regels in deze volgorde:

1. Skip-regels voor betrouwbare, geverifieerde bronnen
2. Specifieke blokkades (gevoelige bestanden, admin)
3. Uitdagingen voor risicovolle acties (login, registratie, wachtwoordreset)
4. Algemene beperkingen (landen, user-agents)

Controleer in de documentatie of de volgorde in jouw dashboard overeenkomt met de volgorde van uitvoer, en verifieer dat in je events.

Reken met je limiet

Op Pro heb je een beperkt aantal custom rules. Gebruik ze voor wat geld oplevert:

Combineer verwante paden in één regel met de operator in of or, zodat je niet voor elk pad een regel verbruikt. Houd een reserve van enkele regels vrij voor noodgevallen, zoals een snelle blokkade tijdens een actieve aanval.

Wanneer custom rules niet voldoende zijn

Zodra je regels nodig hebt met reguliere expressies, meer regels dan je plan toelaat, of fijnmazige scoring van bots, stuit je op de grenzen van Pro. Dan is het zinvol om het plan te heroverwegen (zie Cloudflare Free, Pro of Business), of een deel van de logica naar je eigen server of applicatie te verplaatsen. Een WAF-regel is een stok achter de deur, geen vervanging voor een goed afgeschermde applicatie. Hoe wij dat inrichten staat bij webshop security.