Cloudflare WAF false positives oplossen: events lezen en regels tunen

Een klant meldt dat hij niet kan afrekenen. Een medewerker krijgt een foutpagina in de admin. Je ERP-koppeling levert opeens geen orders meer. Drie keer de kans dat je Cloudflare WAF een legitiem verzoek blokkeert.

Het goede nieuws: Cloudflare laat precies zien welke regel afging. Het slechte nieuws: wie niet weet waar hij moet kijken, zet uit pure frustratie de hele WAF uit. Dit artikel laat zien hoe je een false positive opspoort en oplost, zonder je beveiliging op te geven.

Stap 1: bevestig dat het de WAF is

Vraag de melder om een tijdstip, een URL en zo mogelijk het Ray ID van de foutpagina. Een Cloudflare-blokpagina toont dat ID. Met dat ID en tijdstip vind je het event terug.

Controleer ook of het echt Cloudflare is. Een 403 kan ook van je eigen server, een module of je firewall komen. Het blokkeren door Cloudflare herken je aan de Cloudflare-foutpagina.

Stap 2: open de events

In het dashboard van je zone ga je naar Analytics en dan naar het tabblad Events. Cloudflare onderscheidt twee weergaven:

• Security Events. Alleen de requests waarop een beveiligingsfunctie actie ondernam of iets markeerde.
• Security Analytics. Alle verkeer, ook requests waar niets mee gebeurde.

De bruikbare onderdelen:

• Events by service. Zie of het Managed rules, Rate limiting of een custom rule was.
• Top events by source. Welke IP's, paden, user agents of landen.
• Sampled logs. Klap een event open en bekijk de details. Via "Edit columns" toon je kolommen als Rule ID, User agent en Path.

Een enkel request kan meerdere events opleveren, één per functie die het raakte. Zie je er dus twee voor één verzoek, dan is dat normaal.

Stap 3: filter op het probleem

Voeg een filter toe op pad, IP of Rule ID. Een paar waarschuwingen uit de documentatie: zet geen aanhalingstekens om waarden, gebruik geen AS-voorvoegsel voor ASN's en wildcards worden niet ondersteund. Standaard kijkt het overzicht naar de laatste 24 uur. Cloudflare bewaart events 31 dagen op Free, Pro en Business.

Let op sampling. Bij veel verkeer toont het dashboard een steekproef. Lijkt de lijst onvolledig, verklein dan het tijdvenster.

Stap 4: bepaal de oorzaak

Je ziet nu welke regel of welk onderdeel de aanvraag raakte. Dan zijn er vier typische gevallen:

Stap 5: los het smal op

De regel van de drie: zo klein mogelijk.

1. Een exception (skip). Sla alleen die regel, voor alleen dat pad, over. Een exception gaat vóór een override.
2. Een override op de regel. Verander de actie van één regel, bijvoorbeeld van Block naar Managed Challenge.
3. Een override op een tag of de hele set. Alleen als meerdere regels uit dezelfde klasse steeds problemen geven.

Zet nooit de hele ruleset uit om één probleem op te lossen. Als je even wilt testen, gebruik dan de schakelaar bij de deployment-regel, en zet hem daarna weer aan.

Veelvoorkomende false positives bij webshops

• Zoekopdrachten met speciale tekens. Bijvoorbeeld een merknaam met een apostrof of haakjes.
• Opslaan van producttekst in de admin. De editor stuurt HTML, wat op een XSS-poging lijkt.
• Checkout-opmerkingen. Vrije tekst met leestekens.
• Webhooks en API-calls. JSON-bodies met velden die een regel niet kent.
• Uploads. Bij een gevoelige OWASP-threshold kan een bestandsupload regel 949110 raken.

Test een wijziging voor je haar breed uitrolt

Op Pro bestaat de actie Log niet voor custom rules. Je kunt een nieuwe regel dus niet droog draaien. Werk daarom zo:

• Maak de regel eerst smal, op één pad en één bron.
• Gebruik Managed Challenge in plaats van Block.
• Kijk na een paar uur in de events of er verkeer op valt dat er niet op hoort te vallen.
• Verbreed pas daarna.

Leg vast wat je uitzondert

Elke exception is een gat. Noteer waarom hij bestaat, wie hem vroeg en wanneer je hem opnieuw bekijkt. Anders ontstaat een stapel uitzonderingen die niemand meer durft aan te raken. Als regels worden verwijderd, toont het dashboard "Rule unavailable". Check dan de audit logs om te zien wie wat wijzigde.

Een voorbeeld van begin tot eind

Een casus laat zien hoe het werkt. Dit is een voorbeeld, geen echt klantverhaal.

Een klant meldt dat het opslaan van een nieuw adres in het account een foutpagina geeft. Je vraagt om het Ray ID van die pagina. Daarmee zoek je in de security events. Je ziet dat een managed rule het verzoek heeft geblokkeerd. In het verzoek zit een adresveld met een &-teken en een regel met Apt. 3', waarin het apostrof de regel aan het schrikken maakt.

De oplossing is niet de regel uitzetten. Je maakt een exception voor die regel, voor het pad /customer/address/formPost, methode POST. Verder blijft de set overal actief. Je test met hetzelfde adres, ziet dat het werkt, en legt de uitzondering vast.

Een checklijst voor het onderzoek

Loop dit af voordat je een regel aanraakt.

1. Is het de WAF? Controleer of de foutpagina van Cloudflare komt en een Ray ID toont.
2. Welke regel of welk onderdeel heeft geblokkeerd? Zoek op Ray ID.
3. Welk pad, welke methode, welke parameter?
4. Is het verzoek legitiem? Reproduceer het zelf met dezelfde invoer.
5. Treft het één gebruiker of velen?
6. Is het sinds een bepaalde wijziging begonnen? Kijk naar recente deployments, regelwijzigingen of updates van de managed rules.

Vaak lost stap 6 het mysterie op. Een nieuwe functie in de shop stuurt ineens andere data, en de WAF reageert daarop.

Hoe smal moet een exception zijn?

Hoe smaller, hoe beter. Een goede exception is te omschrijven in één zin: "regel X niet toepassen op POST naar pad Y". Een slechte is: "managed rules niet toepassen op alles onder /customer". Die tweede opent een groot deel van je shop.

Werk van smal naar breed:

1. Eén regel, één pad, één methode.
2. Eén regel, een groep paden.
3. Een groep regels, één pad. Alleen als je meerdere regels op hetzelfde formulier ziet afgaan.
4. De set uitzetten voor één pad. Alleen voor paden die je bewust anders behandelt, zoals een betaalwebhook met eigen authenticatie.

Wat je nooit doet

• De hele WAF uitzetten omdat een klant klaagt. Je verruilt één probleem voor een groot risico.
• Een exception maken op IP-adres van de klant. IP's wisselen en dit lost de oorzaak niet op.
• Exceptions niet opschrijven. Over een jaar weet niemand meer waarom.
• Alleen de klant geloven. Reproduceer het probleem zelf.

Wat te doen als je het event niet vindt

Soms zie je geen event voor een geblokkeerd verzoek. Mogelijke oorzaken:

• Het verzoek is niet door de WAF geblokkeerd, maar door een andere functie, zoals rate limiting of bot-bescherming. Controleer die logs ook.
• De retentie is verstreken. Het logvenster is beperkt, dus bewaar belangrijke gevallen.
• Het filter staat te smal, bijvoorbeeld op de verkeerde hostnaam of tijdzone.
• De fout zit in je origin of in Cloudflare-caching, niet in de WAF.

Een tip: spreek met je team af dat elke klantklacht over een blokkade met Ray ID en tijdstip wordt vastgelegd. Dat versnelt het onderzoek enorm. Zie ook ons overzicht over webshop security voor de andere lagen die je op orde wilt hebben.