Rate limiting pe Cloudflare: praguri pe login, checkout și admin fără false positive

Rate limiting-ul e cea mai subestimată linie de apărare pe L7. Nu înlocuiește WAF-ul și nu oprește un volumetric clasic, dar oprește pattern-ul care îți topește CPU-ul: sute de POST-uri pe login, scraperi pe categorii, carding pe checkout. Pe hosting shared sau VPS „în familie”, un singur magazin fără rate limit poate strica vecinătatea.

Obiectivul nu e „cât mai puține requesturi”. E asimetrie: atacatorul plătește scump în timp, clientul legitim nu observă fricțiunea.

Unde pui rate limit întâi (ordinea contează)

1. Autentificare — /wp-login.php, /xmlrpc.php, /my-account, /admin, rute de SSO.
2. Checkout & plăți — /checkout, /cart, endpoint-uri de plată inițiată de browser (nu callback-urile server-to-server).
3. Căutare și filtre — ?s=, facet-uri Ajax care lovesc Elasticsearch/MySQL greu.
4. API publice — login API, reset password, upload.

Nu începe cu homepage-ul. Homepage-ul e zgomotos: campanii Ads, influenceri, un articol care explodează pe Facebook. Rate limit greșit pe / = falsă criză de „site picat”.

Cum alegi pragul (metodă, nu ghicit)

Ia 7 zile de analytics/access log pe path-ul țintă și notează percentila 95 și 99 de requesturi / IP / 5 minute în trafic „normal”. Pragul de rate limit trebuie să fie peste P99 legitim, dar sub platoul tipic de atac.

Exemple de start (ajustează după măsurători):

• Login POST: 5–8 req / minut / IP, apoi challenge; 20 / 10 min → block temporar.
• Checkout: 30–60 req / minut / IP pe pagini GET; POST-uri de plasare comandă mai stricte (ex. 10 / 5 min).
• Admin AJAX: 120 / minut poate fi normal pentru un editor; pe IP-uri noi, coboară.

Important: caracteristica de matching. „Pe IP” e standard. Pe magazine B2B din același NAT corporate, un IP reprezintă 50 de useri — acolo folosești cookie de sesiune / header autentificat ca dimensiune secundară, sau crești pragul pe ASN-ul respectiv.

Login: brute-force fără să încuie owner-ul

Owner-ul magazinului greșește parola de trei ori din telefon pe 4G, apoi pe Wi‑Fi de birou — două IP-uri. Dacă blochezi la a 3-a încercare pe 24h, generezi ticket de panică. Preferă:

• challenge după N eșecuri;
• block scurt (10–60 min), nu ban de o săptămână;
• allowlist pe IP-uri de agenție;
• încurajează 2FA pe WordPress/admin — rate limit-ul e plasă, nu MFA.

Xmlrpc merită un tratament special: dacă nu ai Jetpack/app mobil care depinde de el, îl poți închide mai agresiv decât login-ul clasic.

Checkout: protejezi venitul, nu doar serverul

Carding-ul arată ca „mulți clienți”. Semnale:

• POST repetate pe același endpoint de plată cu sesiuni noi;
• User-Agent rotit, fără referrer intern din /cart;
• viteză peste orice funnel real (adaugă în coș → pay în <2s, de mii de ori).

Rate limit pe checkout trebuie corelat cu excepții pe webhook. IP-urile procesatorului nu trebuie să intre în aceeași găleată cu browserul clientului. Separă regulile: browser paths vs server callbacks.

Admin și panouri: suprafața pe care atacatorii o iubesc

/wp-admin/ pe IPv4 public, fără Cloudflare, e invitație. Cu Cloudflare:

• rate limit + challenge pe IP-uri noi;
• opțional: regulă „block pe admin dacă țara ∉ {RO, …}” — doar dacă business-ul e local și echipa e locală;
• nu cache-ui adminul (bypass cache) — rate limit ≠ cache.

Pe panouri de hosting (cPanel, custom ops), același principiu: path predictibil + MFA + rate limit. Nu te baza doar pe „URL secret”.

False positive: cum le diagnostichezi în 15 minute

1. Firewall Events / Rate Limit events: IP, path, rule id.
2. Compară cu access log origin: același IP avea sesiune de client real?
3. Verifică dacă e NAT mobil/carrier (ASN mare, mulți useri).
4. Ridică temporar pragul pe ASN, nu dezactiva tot rate limit-ul global.

Documentează excepția. Excepțiile nedocumentate sunt datoria tehnică care explodează la următorul Black Friday.

Corelare cu origin (PHP-FPM, Nginx)

Edge rate limit reduce zgomotul. Originul tot are nevoie de:

• limite pe conexiuni per IP la Nginx;
• pm.max_children realist pe PHP-FPM;
• timeout-uri pe upstream ca un flood rămas să nu țină workerii ocupați la nesfârșit.

Fără asta, un atac care trece de edge (sau un bypass pe IP origin) tot îți umple coada.

Concluzie

Rate limiting bun e plictisitor: măsurători, praguri pe path, excepții pe plăți, review lunar. Rate limiting prost e spectaculos: site „protejat” care nu mai încasează.

Pe xServere.NET tratăm rate limit-ul ca pe o piesă dintr-un sistem — edge Cloudflare unde e cazul, plus origin și rețea de DC pregătite să nu cedeze când cineva țintește login-ul. Dacă rulezi magazine sau aplicații cu peaking real, alege un hosting care înțelege diferența dintre trafic și asediu.