Reguli WAF Cloudflare pe expresii: blochezi pattern-uri fără să blochezi clienții reali

Mulți operatori activează WAF-ul Cloudflare pe „block everything suspicious” și descoperă în aceeași zi că webhook-urile de plată, pluginurile de stoc și clienții corporate pe VPN dispar din analytics. Problema nu e WAF-ul — e lipsa unei discipline de expresie + excepție + observabilitate. Pe hosting, unde pe același edge stau zeci de tipare de site, greșeala se amplifică.

Acest ghid e evergreen: nu ține de un CVE de ieri, ci de cum proiectezi reguli custom care rămân valide când schimbi tema, adaugi un ERP sau muți checkout-ul pe un subdomeniu.

Ce înseamnă o regulă „pe expresii”

În Cloudflare, Custom Rules (fostul Firewall Rules) evaluează câmpuri din request: path, query, method, header, țară, ASN, scor de bot, etc. Tu compui o condiție booleană și alegi o acțiune: log, managed challenge, block, skip (bypass pe alte rulesets).

Diferența dintre o regulă utilă și una toxică e specificitatea. „Blochează tot ce conține select în query” e o catastrofă pe magazine (filtre, sortări). „Blochează UNION SELECT pe path-uri non-admin, cu excepția IP-urilor de birou” e operațional.

Modelul de lucru: log → challenge → block

1. Log only 24–72h pe regula nouă. Citești Firewall Events: câte hit-uri, ce path-uri, ce ASN-uri.
2. Challenge pe același matching. Măsori conversia pe login/checkout (nu doar „câte requesturi”).
3. Block abia când semnalul e stabil și excepțiile sunt documentate.

Sări peste pasul 1 și vei petrece weekendul cu rollback pe producție. Pe hosting managed, suportul vezi același pattern: clientul „a strâns șurubul” vineri seara.

Pattern-uri sigure pentru WordPress / WooCommerce

Login și xmlrpc

Țintește /wp-login.php și /xmlrpc.php cu rate limit + challenge, nu cu block global pe țară. Multe agenții administrează site-uri din IP-uri rezidențiale sau mobile. O allowlist pe $office_ips (listă IP/CIDR) + challenge pentru restul e un compromis bun.

(http.request.uri.path eq "/wp-login.php")
and not ip.src in $office_ips

Acțiune recomandată la început: Managed Challenge. Block-ul absolut pe login are sens doar după ce ai MFA/SSO pe admin și un canal alternativ de recovery.

REST API și admin-ajax

/wp-json/ și admin-ajax.php sunt folosite legitim de teme, mobile apps și page builders. Nu le bloca pe string-uri generice tip eval din body fără să verifici false positive pe editorul de conținut. Preferă:

• rate limit pe metodă POST spre aceste path-uri;
• block pe user-agent-uri goale + lipsă header-e tipice de browser doar pe endpoint-uri de autentificare;
• excepții pe IP-urile Jetpack / servicii pe care le folosești intenționat.

Checkout și callback-uri de plată

Gateway-urile trimit server-to-server pe path-uri predictibile. Adaugă skip (sau allow) pe acele URI-uri pentru ASN-urile/IP-urile documentate de procesator. Altfel, WAF-ul „câștigă” atacul și pierde comanda.

API-uri proprii (Laravel, headless, mobile)

Pe API, expresiile pe path + method sunt aur:

• POST /api/v1/auth/login — rate limit agresiv, challenge rar (clienții non-browser au nevoie de 429 clar, nu de JS challenge).
• GET /api/v1/catalog — poți fi mai permisiv, dar plafonează pe IP și pe API key header.
• Blochează metodele exotice (TRACE, DEBUG) la edge dacă originul nu le folosește.

Nu confunda „bot score mic” cu „atacator”. Crawler-ele de monitoring, uptime și parteneri pot avea scoruri ciudate. Folosește liste de excepție pe ASN și pe header de autentificare valid.

Header-e și body: putere mare, risc mare

Inspecția pe body e utilă pe upload-uri și pe endpoint-uri de contact, dar e costisitoare și ușor de greșit. Reguli de tip „block dacă body conține <script” vor rupe pagini de admin care salvează HTML. Limitează astfel de reguli la path-uri publice de formular, nu pe /wp-admin/.

Pe header, țintește anomaliile clare: lipsa Host, Host greșit față de zonă, sau header-e de debug lăsate din staging (X-Debug-Token) pe producție — pe astea poți bloca fără milă.

Cum eviți false positive pe scară de hosting

1. Reguli pe „tip de site”, nu o singură regulă globală pentru tot portofoliul: blog, magazin, API, landing.
2. Liste reutilizabile ($payment_ips, $agency_vpn, $monitoring) actualizate ca pe un inventar, nu ca pe un ticket uitat.
3. Skip pe managed rulesets doar pe path-ul problematic, nu pe tot domeniul.
4. Corelare cu origin: dacă PHP-FPM e OK dar Cloudflare blochează, e edge; dacă edge e clean dar 5xx pe origin, nu „strânge WAF-ul” inutil.

Checklist de acceptare înainte de block

• Ai cel puțin un eșantion de 24h în log fără hit-uri pe IP-uri de plată/ERP.
• Ai testat login admin, add-to-cart, plasare comandă, webhook de status.
• Ai un owner pe listă (cine actualizează $office_ips când se schimbă sediul).
• Ai rollback: duplicat regula pe disabled sau notezi ID-ul regulii în runbook.

Concluzie

WAF-ul pe expresii e un instrument de inginerie, nu un comutator de marketing. Pe un stack de hosting serios, edge-ul (Cloudflare) și originul (firewall hardware, PHP-FPM, rate limit local) trebuie să spună aceeași poveste: ce e permis, ce e suspect, ce e excepție documentată.

Dacă administrezi magazine sau flote de WordPress și vrei un origin care rezistă când edge-ul filtrează agresiv — IP stabil, uplink curat, izolare corectă — merită un hosting gândit pentru securitate operațională, nu doar pentru „spațiu pe disk”. Infrastructura pe care o folosim pentru clienții xServere.NET e proiectată exact în jurul acestui model: edge inteligent + origin disciplinat.