Cloudflare Managed Rules uitgelegd: sets, acties en overrides

Cloudflare Managed Rules zijn kant-en-klare regels die aanvalspatronen herkennen. Jij schrijft ze niet, Cloudflare onderhoudt ze. Op Pro zet je ze met een schakelaar aan. De vraag is niet óf, maar welke set, in welke stand, en wat je doet bij een false positive.

Dit artikel legt uit welke sets er zijn, hoe ze werken en hoe je ze tunet zonder je shop te breken. Het is onderdeel van onze aanpak voor webshop security.

Welke managed rulesets bestaan er?

Cloudflare beschrijft in zijn documentatie vier sets:

Voor die laatste raadt Cloudflare zelf de nieuwere functie "leaked credentials detection" aan. Bouw er dus geen nieuwe configuratie op.

Cloudflare Managed Ruleset: de basis

Dit is de set die je als eerste aanzet. Hij bevat handmatig geschreven, op signaturen gebaseerde regels en wordt vaak bijgewerkt. Wanneer er een nieuwe kwetsbaarheid breed wordt misbruikt, komt er doorgaans snel een regel bij.

Dat is waardevol voor Magento. Maar het is geen vervanging voor patchen. Een regel dekt bekende aanvalsroutes af. Een lek in de code blijft bestaan.

OWASP Core Ruleset: scoren in plaats van blokkeren

De OWASP-set werkt anders. Elke regel die matcht, verhoogt een score. Pas als de totale score een drempel overschrijdt, voert Cloudflare de ingestelde actie uit. Dat is de anomaly-scoring van de ModSecurity Core Rule Set. De details staan in Cloudflare OWASP Core Ruleset instellen.

Een eerlijke kanttekening, rechtstreeks uit de Cloudflare-documentatie: deze set is gevoelig voor false positives. Bovenop de Managed Ruleset en de WAF attack score levert hij volgens Cloudflare maar beperkt extra winst op. Zet hem dus niet blind aan.

Hoe zet je een set aan?

In de Cloudflare-dashboardomgeving van je zone:

1. Open de Security-instellingen.
2. Filter eventueel op "Web application exploits".
3. Zet de gewenste set aan.
4. Controleer de deploymentinstellingen. Beperk eventueel het bereik of voeg overrides toe.
5. Sla op.

Cloudflare maakt hierbij een regel met de actie Execute. Met de schakelaar ernaast zet je de set tijdelijk uit zonder de configuratie te verliezen. Handig bij een vermoede false positive.

Acties, overrides en exceptions

Elke regel heeft een standaardactie, afhankelijk van de ernst. Die kun je aanpassen. Er zijn twee gereedschappen:

• Override. Verander de actie of zet regels uit. Dat kan voor de hele set, voor regels met een bepaalde tag, of voor één regel. Overrides op een set of tag gelden ook voor toekomstige regels.
• Exception. Sla regels of hele sets over voor bepaalde requests. Een exception gaat vóór een override.

Gebruik een exception als je één specifiek pad wilt uitzonderen, bijvoorbeeld een webhook-URL van je betaalprovider. Gebruik een override als een hele klasse regels te streng is.

Een praktische volgorde

1. Zet de Cloudflare Managed Ruleset aan met de standaardacties.
2. Kijk een week naar je WAF-events voordat je iets aanpast.
3. Voeg exceptions toe voor wat aantoonbaar legitiem is.
4. Overweeg pas daarna de OWASP-set, met een lage paranoia level.

Wat managed rules niet doen

• Ze lossen geen kapotte autorisatie op. Als een klant via een aanpasbaar ID andermans bestelling kan zien, ziet geen regel dat.
• Ze beschermen je admin niet tegen een gestolen wachtwoord. Daarvoor heb je 2FA en IP-beperking nodig.
• Ze vervangen geen extensiebeheer.

Zo lees je wat een managed rule doet

Een regel in een managed ruleset heeft een ID, een omschrijving, een standaardactie en tags (bijvoorbeeld voor het soort aanval of het product waar het om gaat). Voor het tunen heb je vooral die tags en ID's nodig.

Een rustige manier van werken:

1. Zet de set aan in de standaardstand.
2. Kijk in je security events welke regel-ID's afgaan, en op welke paden.
3. Gaat er een regel af op iets dat je kent en vertrouwt, schrijf dan eerst op waarom het een false positive is. Is het een admin-actie? Een betaalprovider? Een zoekopdracht met tekens die op SQL lijken?
4. Maak een zo smal mogelijke exception: één regel, één pad, één methode.

Een hele regelgroep uitzetten omdat één regel in de weg zit, is de meest gemaakte fout. Je verliest dan bescherming op alle andere paden.

Voorbeelden uit de praktijk van een webshop

Dit zijn typen verkeer die vaak wél legitiem zijn maar verdacht lijken. Welke regel precies afgaat, verschilt per situatie. Zoek het zelf op in je events.

• Admin-formulieren die HTML of JavaScript bevatten. Een CMS-blok of e-mailtemplate in Magento kan opmaakcode bevatten. Voor een WAF lijkt dat op een injectie.
• Zoektermen met aanhalingstekens, streepjes of haakjes. Een klant zoekt op een artikelnummer als AB-100 (zwart). Dat lijkt op SQL-syntaxis.
• Webhooks met JSON-bodies. Betaalproviders sturen payloads met rare tekens. Als een webhook faalt, zie je dat vaak pas in de orderstatus.
• Importtools en feeds. Een product-feed die via een API wordt aangeleverd, bevat veel tekens die een WAF kan raken.

Voor deze categorieën maak je exceptions op pad, niet op de hele set.

Wat je in je dashboard moet vastleggen

Elke override of exception die je maakt, hoort in een document. Schrijf per wijziging op:

• Datum en wie het deed
• Regel-ID en pad
• Reden (de klacht, het Ray ID, de test)
• Wanneer je de uitzondering opnieuw bekijkt

Zonder dit weet niemand over een jaar waarom een regel is uitgezet, en dan blijft hij voor altijd uit. Het is saai werk, maar het scheelt je een incident.

Managed rules en je Magento-updates

Magento-kwetsbaarheden worden regelmatig misbruikt in de dagen na publicatie. Een managed ruleset kan dan een gat tijdelijk dichten, maar alleen voor wat Cloudflare herkent. Reken er niet op dat een nieuwe kwetsbaarheid binnen een dag een regel heeft. Je updatebeleid blijft leidend. Hoe wij daarmee omgaan staat bij Magento beveiliging en op de security-pagina.

Een kleine proef die veel vertelt

Wil je weten hoe de WAF reageert, test dan met een onschuldig verzoek dat een bekend aanvalspatroon nabootst, op je eigen testomgeving of staging, en niet op productie van een ander. Voeg bijvoorbeeld een aanvalsachtige querystring toe aan een URL van je eigen site en kijk of Cloudflare een event logt. Doe dit alleen op je eigen domein, en bij voorkeur op een omgeving waar je het verkeer kunt missen. Zo zie je dat de set actief is, en welke actie hij uitvoert, zonder te wachten op een echte aanval.