Cloudflare OWASP Core Ruleset: paranoia level en threshold instellen

De OWASP Core Ruleset in Cloudflare blokkeert niet bij de eerste verdachte regel. Hij telt punten. Elke regel die matcht, tikt een score op. Pas als het totaal een drempel haalt, grijpt Cloudflare in. Wie dat model begrijpt, kan de set tunen. Wie het niet begrijpt, blokkeert vroeg of laat zijn eigen klanten.

Dit artikel legt de twee instellingen uit die het verschil maken: de paranoia level en de score threshold. Eerst de basis uit Cloudflare Managed Rules uitgelegd, als je die nog niet kent.

Wat is de OWASP Core Ruleset?

Het is Cloudflares implementatie van de OWASP ModSecurity Core Rule Set, versie 3.3.0. De regels werken samen aan één "threat score" per request. Matcht een regel, dan gaat de score van die regel erbij. Komt het totaal boven de ingestelde drempel, dan voert Cloudflare de actie uit die op de laatste regel van de set staat.

De regelgroepen komen overeen met bekende aanvalsklassen. Cloudflare noemt onder meer:

Cloudflare zegt er zelf bij dat de CRS "relatief statisch" blijft, terwijl de eigen Managed Ruleset vaker verandert. Lees ook de waarschuwing: de OWASP-set is gevoelig voor false positives en geeft naast de Managed Ruleset en de WAF attack score maar beperkte extra winst.

Paranoia level: hoe streng zijn de regels?

De paranoia level loopt van PL1 tot PL4. PL1 is de standaard. Hoe hoger het niveau, hoe meer regels meedoen.

• Een niveau is cumulatief. Kies je PL3, dan zijn de regels van PL1, PL2 en PL3 actief.
• Hoger = meer bescherming, meer kans op false positives.
• PL4 is de strengste stand. Voor applicaties met complexe invoer moet je daar waarschijnlijk regels uitzetten.

Voor een webshop is PL1 een logisch startpunt. Je zoekfunctie, je filters en je adresvelden sturen veel tekens naar de server. Dat geeft op hogere niveaus snel valse alarmen.

Score threshold: hoeveel punten tellen?

De threshold bepaalt wanneer de actie afgaat. Cloudflare kent drie standen:

Let op de naamgeving. "Low" is de minst gevoelige stand, want je hebt een hoge score nodig. "High" is de gevoeligste. Cloudflare waarschuwt dat uploads bij High regel 949110 (Inbound Anomaly Score Exceeded) kunnen triggeren.

Een veilige configuratie om mee te beginnen

1. Zet de Cloudflare Managed Ruleset aan en laat die een week draaien.
2. Zet de OWASP-set aan met PL1 en een Medium of Low threshold.
3. Kies als actie Managed Challenge, niet Block. Een echte klant kan dan nog door.
4. Bekijk de events. Zie false positives oplossen.
5. Pas pas na weken de level of threshold aan.

Op Pro kun je custom rules niet in Log-modus zetten. Voor de OWASP-set geldt dat de actie op de set staat. Een challenge is daarom de veiligste testactie.

Wat een score-gebaseerde aanpak betekent in de praktijk

Eén verdacht teken is zelden genoeg. Een zoekopdracht met een apostrof levert een klein score-incrementje op. Een URL met SQL-fragmenten, een vreemde User-Agent en een scriptlabel in een veld samen overschrijden de drempel. Dat is de gedachte erachter: meerdere zwakke signalen vormen één sterk signaal.

Voor webshops zijn dit de plekken waar false positives ontstaan:

• Zoekvelden met speciale tekens.
• Rijke teksteditors in de admin, waar HTML wordt opgeslagen.
• Checkoutvelden met adressen en opmerkingen.
• API-aanroepen van ERP- en PSP-koppelingen met JSON in de body.

Beperk daarom het bereik. Je kunt de set via de scope alleen laten gelden voor de publieke storefront, en je admin en API's er apart in behandelen.

Tunen zonder blind te raden

Cloudflare noemt drie manieren om met een false positive om te gaan: individuele regels of regels met een tag uitzetten, de threshold aanpassen, of een WAF-exception maken. De volgorde van voorkeur:

1. Exception voor het pad of de parameter. Smal en veilig.
2. Regel uitzetten voor een specifieke regel-ID. Als één regel steeds de oorzaak is.
3. Threshold verhogen naar Low. Hiermee ga je minder gevoelig. Doe dit pas als de rest niet werkt.

Moet je de OWASP-set eigenlijk wel aanzetten?

Een eerlijk antwoord: niet altijd. Als je de Cloudflare Managed Ruleset draait, goede custom rules hebt en je applicatie gepatcht is, voegt de OWASP-set weinig toe en kost hij onderhoud. Hij is zinvol als je een laag wilt met een bekende, publiek gedocumenteerde regelbasis, bijvoorbeeld voor een audit, of als je maatwerkcode hebt waar je niet blind op vertrouwt.

Een voorbeeld van hoe de score oploopt

Anomaly-scoring is makkelijker te begrijpen met een rekenvoorbeeld. De getallen hieronder zijn illustratief om het principe te tonen. De werkelijke scores per regel vind je in de regelomschrijvingen.

Stel, een bezoeker zoekt op een productnaam met een aanhalingsteken en een haakje. Eén regel matcht op het aanhalingsteken en geeft een lage score. Een tweede regel matcht op het haakje en telt daar iets bij op. Pas als de optelsom de ingestelde drempel haalt, treedt de actie in werking (regel 949110 doet die controle).

Dat verklaart twee dingen die je in de praktijk ziet:

• Een verzoek met één verdacht teken wordt zelden geblokkeerd, tenzij je de drempel laag zet.
• Een verzoek met veel kleine aanwijzingen kan wel geblokkeerd worden, ook als geen enkele regel afzonderlijk erg is.

Zo kies je paranoia level en threshold samen

Beide instellingen werken door elkaar. Een hoger paranoia level activeert meer regels, en dus kan de score sneller oplopen. Een lagere threshold laat de actie eerder afgaan. Wie beide verscherpt, krijgt veel false positives.

Wil je een instelling verhogen, doe dat dan één stap tegelijk: eerst het paranoia level of de threshold, niet allebei. Anders weet je niet wat de oorzaak was van een stijging in blokkades.

Een testplan voor de eerste twee weken

1. Week 1: observeren. Zet de set aan met een zachte actie. Noteer dagelijks welke regel-ID's het vaakst afgaan en op welke paden.
2. Groepeer de hits. Welke komen van je eigen beheerders? Welke van betaalproviders of koppelingen? Welke van onbekende bezoekers?
3. Maak exceptions voor het aantoonbaar legitieme. Eén pad, één regel.
4. Week 2: verscherp. Als de ruis laag is, zet je de actie op blokkeren of een challenge. Behoud de logging.
5. Controleer de conversie. Een daling die samenvalt met de omzetting is een alarmsignaal.

Wat er zelden goed gaat

• De set aanzetten op Block zonder test. Het is het snelste pad naar boze klanten.
• Alleen naar de blokkades kijken. Ook uitgedaagde en gelogde verzoeken vertellen iets.
• Exceptions op te brede paden. Een uitzondering voor / laat de set in feite uitstaan.
• De drempel verlagen om "veiliger" te zijn. Zonder tests levert dat vooral meer ruis op.

Past de OWASP-set bij jouw shop?

Voor veel webshops is de Cloudflare Managed Ruleset in combinatie met goede custom rules en rate limiting een betere eerste stap. De OWASP-set is vooral interessant als je zelf wilt kunnen sturen op scores, of als er een eis is vanuit een audit. In dat geval: begin laag, wees geduldig, en leg elke uitzondering vast. Zie ook Cloudflare Managed Rules uitgelegd en onze pagina over webshop security.