INTEGRITY Dokumentace

← Dokumentace WAF / rate-limiting-rules

Osvědčené postupy pro rate limiting

Následující části pokrývají typické konfigurace rate limitingu pro běžné případy použití. Uvedená ukázková pravidla můžete kombinovat a přizpůsobit vlastnímu scénáři.

Hlavní případy použití rate limitingu jsou následující:

Vynucování granulárního řízení přístupu

Omezení podle user agenta

Běžným případem užití je omezení frekvence požadavků prováděných jednotlivými user agenty. Následující ukázkové pravidlo povoluje mobilní aplikaci provést maximálně 100 požadavků za 10 minut. Můžete také vytvořit samostatné pravidlo omezující frekvenci pro desktopové prohlížeče.

Nastavení Hodnota
Kritéria shody User Agent se rovná MobileApp
Expression http.user_agent eq "MobileApp"
Charakteristiky počítání IP
Frekvence (požadavky / období) 100 požadavků / 10 minut
Akce Managed Challenge

Poté, co návštěvník úspěšně projde Managed Challenge, Cloudflare vydá cf_clearance cookie, která je identifikuje jako ověřené. Škodliví aktéři se však mohou pokusit opakovaně použít nebo sdílet jedinou platnou cf_clearance hodnotu napříč více požadavky nebo zařízeními k obejití dalších challenge.

Toto pravidlo rate limitingu pomáhá mitigovat takové zneužití omezením počtu požadavků se stejným cf_clearance hodnotu v definovaném období. Legitimní lidští uživatelé zůstanou nedotčeni, zatímco automatizované nebo přehrávané požadavky používající jediný clearance token budou po překročení prahu zablokovány.

Nastavení Hodnota
Kritéria shody URI Path se rovná /checkout
Expression http.request.uri.path eq "/checkout"
Charakteristiky počítání Cookie (cf_clearance)
Frekvence (požadavky / období) 100 požadavků / 10 minut
Akce Block

Povolení konkrétních IP adres nebo ASN

Dalším případem použití při řízení přístupu ke zdrojům je vyloučení IP adres nebo čísel autonomních systémů (ASN) z pravidla rate limitingu, případně jejich zahrnutí.

Následující ukázkové pravidlo povoluje až 10 požadavků za minutu ze stejné IP adresy provádějících GET požadavek na /status, pokud IP adresa návštěvníka není zahrnuta v partner_ips IP seznam.

Nastavení Hodnota
Kritéria shody URI Path se rovná /status a Request Method se rovná GET a zdrojová IP adresa není v seznamu partner_ips
Expression http.request.uri.path eq "/status" and http.request.method eq "GET" and not ip.src in $partner_ips
Charakteristiky počítání IP
Frekvence (požadavky / období) 10 požadavků / 1 minuta
Akce Managed Challenge

Omezení podle refereru

Některé aplikace přijímají požadavky pocházející z jiných zdrojů (například využívané reklamami odkazujícími na stránky třetích stran). Můžete chtít omezit počet požadavků generovaných jednotlivými odkazujícími stránkami kvůli správě kvót nebo prevenci nepřímých DDoS útoků.

Nastavení Hodnota
Kritéria shody URI Path se rovná /status a Request Method se rovná GET
Expression http.request.uri.path eq "/status" and http.request.method eq "GET"
Charakteristiky počítání Hlavička (Referer) 1
Frekvence (požadavky / období) 100 požadavků / 10 minut
Akce Block

Toto ukázkové pravidlo vyžaduje Advanced Rate Limiting.

Omezení podle cílového hostitele

SaaS aplikace nebo zákazníci používající Cloudflare SSL for SaaS mohou mít tisíce hostitelů v rámci jedné zóny, takže vytváření samostatných pravidel pro každého hostitele je nepraktické. To lze vyřešit vytvořením pravidla rate limitingu, které používá hostitele jako charakteristiku pro počítání.

Následující ukázkové pravidlo bude sledovat frekvenci požadavků na /login endpoint pro každý host:

Nastavení Hodnota
Kritéria shody URI Path se rovná /login a Request Method se rovná GET
Expression http.request.uri.path eq "/login" and http.request.method eq "GET"
Charakteristiky počítání IP a Host
Frekvence (požadavky / období) 10 požadavků / 10 minut
Akce Block

Toto ukázkové pravidlo vyžaduje Advanced Rate Limiting.

Ochrana proti credential stuffingu

Typickým případem užití rate limitingu je ochrana přihlašovacího endpointu proti útokům, jako je credential stuffing ↗. Následující příklad obsahuje tři různá pravidla rate limitingu s rostoucími postihy pro klienty odesílající příliš mnoho požadavků.

Pravidlo č. 1

Nastavení Hodnota
Kritéria shody Hostname equals example.com a URI Path equals /login a Request Method se rovná POST
Expression http.host eq "example.com" and http.request.uri.path eq "/login" and http.request.method eq "POST"
Charakteristiky počítání IP
Increment counter when URI Path se rovná /login a Method se rovná POST a Response code is in (401, 403)
Výraz pro počítání http.request.uri.path eq "/login" and http.request.method eq "POST" and http.response.code in {401 403}
Frekvence (požadavky / období) 4 požadavky / 1 minuta
Akce Managed Challenge

Pravidlo č. 2

Nastavení Hodnota
Kritéria shody Hostname equals example.com a URI Path equals /login a Request Method se rovná POST
Expression http.host eq "example.com" and http.request.uri.path eq "/login" and http.request.method eq "POST"
Charakteristiky počítání IP
Increment counter when URI Path se rovná /login a Request Method se rovná POST a Response Status Code je v (401, 403)
Výraz pro počítání http.request.uri.path eq "/login" and http.request.method eq "POST" and http.response.code in {401 403}
Frekvence (požadavky / období) 10 požadavků / 10 minut
Akce Managed Challenge

Pravidlo #3

Nastavení Hodnota
Kritéria shody Host equals example.com
Expression http.host eq "example.com"
Charakteristiky počítání IP
Increment counter when URI Path se rovná /login a Request Method se rovná POST a Response Status Code je v (401, 403)
Výraz pro počítání http.request.uri.path eq "/login" and http.request.method eq "POST" and http.response.code in {401 403}
Frekvence (požadavky / období) 20 požadavků / 1 hodina
Akce Blokace na 1 den

Tato ukázková pravidla vyžadují plán Business nebo vyšší.

Pravidlo č. 1 povoluje až čtyři požadavky za minutu, poté se spustí Managed Challenge. Tato konfigurace dává legitimním zákazníkům několik pokusů rozpomenout se na heslo. Pokud automatizovaný aktér provede několik požadavků, bude tento klient pravděpodobně zablokován nevyřešenou Managed Challenge. Naopak pokud člověk challenge při dosažení limitu pravidla č. 1 obdrží a projde jí, pravidlo č. 2 poskytne další úroveň ochrany a povolí až 10 požadavků během následujících 10 minut. Pro klienty překračující tento druhý práh se uplatní pravidlo č. 3 (nejpřísnější), které klienta zablokuje na jeden den.

Tato tři pravidla mají počítací výraz oddělený od výrazu pravidla (známého také jako mitigační výraz). Když nakonfigurujete samostatný počítací výraz, kritéria shody se použijí pouze při spuštění akce. Do počítacího výrazu můžete zahrnout podmínky založené na stavovém kódu HTTP odpovědi a hlavičkách HTTP odpovědi, a tím integrovat rate limiting s logikou vašeho backendu.

Můžete se také rozhodnout mít dva různé výrazy — počítací výraz a výraz pravidla/mitigace — a definovat tak:

  1. Požadavky použité k výpočtu frekvence.
  2. Požadavky, na které byla skutečně uplatněna akce.

Například pravidlo č. 3 počítá frekvenci na základě POST požadavky na /login které vrátily 401 nebo 403 HTTP stavový kód. Když je však rate limit překročen, Cloudflare blokuje každý požadavek na example.com hostitele generované stejnou IP adresou. Více informací o počítacích výrazech najdete v Výpočet frekvence požadavků.

Ochrana OTP a ověřovacích endpointů

Endpointy jednorázových hesel (OTP) a ověřování (jako /api/otp/validate nebo /account/verify) jsou častým cílem brute force útoků. Tyto endpointy jsou obzvlášť citlivé, protože útočníci zkoušejí velké objemy požadavků s různými kódy, aby uhodli platné OTP.

Při konfiguraci rate limitingu pro tyto endpointy se řiďte těmito pokyny:

Následující ukázkové pravidlo chrání endpoint pro validaci OTP počítáním pouze neúspěšných pokusů:

Nastavení Hodnota
Kritéria shody URI Path se rovná /api/otp/validate a Request Method se rovná POST
Expression http.request.uri.path eq "/api/otp/validate" and http.request.method eq "POST"
Charakteristiky počítání IP
Increment counter when URI Path se rovná /api/otp/validate a Request Method se rovná POST a Response Status Code je v (401, 403)
Výraz pro počítání http.request.uri.path eq "/api/otp/validate" and http.request.method eq "POST" and http.response.code in {401 403}
Frekvence (požadavky / období) 5 požadavků / 1 minuta
Akce Blokovat na 10 minut

Výše uvedené ukázkové pravidlo vyžaduje plán Business nebo vyšší.

Pokud váš OTP endpoint vrací 200 pro platné i neplatné kódy (s výsledkem v těle odpovědi), použijte místo toho počítání založené na požadavcích s nižším prahem:

Nastavení Hodnota
Kritéria shody URI Path se rovná /api/otp/validate a Request Method se rovná POST
Expression http.request.uri.path eq "/api/otp/validate" and http.request.method eq "POST"
Charakteristiky počítání IP
Frekvence (požadavky / období) 10 požadavků / 1 minuta
Akce Managed Challenge

Omezení počtu operací

Rate limiting můžete použít k omezení počtu operací prováděných klientem. Konkrétní pravidlo poskytující tuto ochranu bude záviset na vaší aplikaci. Následující příklady se věnují scraping obsahu ↗ přes query string parametry nebo JSON tělo.

Zabránění scrapingu obsahu (přes query string)

V tomto příkladu klienti provádějí operace (například vyhledávání cen a přidávání do košíku) na e-commerce webu pomocí různých parametrů query stringu. Typický požadavek odeslaný klientem by mohl vypadat například takto:

GET https://store.com/merchant?action=lookup_price&product_id=215
Cookie: session_id=12345

Váš bezpečnostní tým může zvážit nastavení limitu počtu vyhledání cen jedním klientem, aby boti — kteří mohli uniknout Cloudflare Bot Managementu — nescrapovali celý katalog obchodu.

Pravidlo č. 1

Nastavení Hodnota
Kritéria shody URI Path se rovná /merchant a URI Query String contains action=lookup_price
Expression http.request.uri.path eq "/merchant" and http.request.uri.query contains "action=lookup_price"
Charakteristiky počítání IP
Frekvence (požadavky / období) 10 požadavků / 2 minuty
Akce Managed Challenge

Pravidlo č. 2

Nastavení Hodnota
Kritéria shody URI Path se rovná /merchant a URI Query String contains action=lookup_price
Expression http.request.uri.path eq "/merchant" and http.request.uri.query contains "action=lookup_price"
Charakteristiky počítání IP
Frekvence (požadavky / období) 20 požadavků / 5 minut
Akce Block

Tato dvě pravidla rate limitingu odpovídají požadavkům provádějícím vybranou akci (v tomto příkladu vyhledání ceny) a používají IP jako počítací charakteristiku. Podobně jako u předchozí /login příklad, obě pravidla pomohou snížit falešně pozitivní detekce v případě vytrvalých (ale legitimních) návštěvníků.

Chcete-li omezit vyhledávání konkrétního product_id přes query string parametr, můžete tento konkrétní query parametr přidat jako počítací charakteristiku, takže se limit počítá ze všech požadavků bez ohledu na klienta. Následující ukázkové pravidlo omezuje počet vyhledávání pro každý product_id na 50 požadavků za 10 sekund.

Nastavení Hodnota
Kritéria shody URI Path se rovná /merchant
Expression http.request.uri.path eq "/merchant"
Charakteristiky počítání Query (product_id)
Frekvence (požadavky / období) 50 požadavků / 10 sekund
Akce Block

Toto ukázkové pravidlo vyžaduje Advanced Rate Limiting.

Stejný vzorec pravidel rate limitingu můžete použít k ochraně aplikací zpracovávajících rezervace a objednávky.

Zabránění scrapingu obsahu (přes tělo)

Představte si aplikaci, která zpracovává operaci a její parametry přes tělo požadavku ve formátu JSON. Například lookup_price operace může vypadat například takto:

POST https://api.store.com/merchant
Cookie: session_id=12345

Body:
{
  "action": "lookup_price",
  "product_id": 215
}

V tomto scénáři byste mohli napsat pravidlo omezující počet akcí z jednotlivých relací:

Nastavení Hodnota
Kritéria shody URI Path se rovná /merchant a JSON String action equals lookup_price
Expression http.request.uri.path eq "/merchant" and lookup_json_string(http.request.body.raw, "action") eq "lookup_price"
Charakteristiky počítání Cookie (session_id)
Frekvence (požadavky / období) 10 požadavků / 2 minuty
Akce Managed Challenge

Toto ukázkové pravidlo vyžaduje Advanced Rate Limiting a inspekci payloadů.

Mohli byste také omezit počet vyhledání každého product_id bez ohledu na klienta, který požadavky odesílá, nasazením pravidla jako je následující:

Nastavení Hodnota
Kritéria shody URI Path se rovná /merchant a JSON pole action equals lookup_price
Expression http.request.uri.path eq "/merchant" and lookup_json_string(http.request.body.raw, "action") eq "lookup_price"
Charakteristiky počítání Pole JSON (product_id)
Frekvence (požadavky / období) 50 požadavků / 10 sekund
Akce Block

Toto ukázkové pravidlo vyžaduje Advanced Rate Limiting a inspekci payloadů.

Omezení požadavků od botů

Obecným přístupem k identifikaci provozu botů je omezit pomocí rate limitingu požadavky, které vyvolávají velký objem 403 nebo 404 stavových kódů odpovědí z origin serveru. To obvykle značí automatizovanou aktivitu scrapovacích aplikací.

V takové situaci byste mohli nakonfigurovat pravidlo podobné následujícímu:

Nastavení Hodnota
Kritéria shody Hostname equals example.com
Expression http.host eq "example.com"
Charakteristiky počítání IP
Increment counter when Response Status Code is in (403, 404)
Výraz pro počítání http.response.code in {403 404}
Frekvence (požadavky / období) 5 požadavků / 3 minuty
Akce Managed Challenge

Toto ukázkové pravidlo vyžaduje plán Business nebo vyšší.

K řízení frekvence akcí prováděných automatizovanými zdroji zvažte použití pravidel rate limitingu společně s Bot Management. S Bot Managementem můžete použít bot score jako součást kritérií shody, aby se pravidlo uplatnilo pouze na automatizovaný nebo pravděpodobně automatizovaný provoz. Můžete například použít maximální skóre (neboli práh) 30 pro pravděpodobně automatizovaný provoz a 10 pro automatizovaný provoz.

Pokud vaše aplikace sleduje sessions pomocí cookie, můžete tuto cookie použít k nastavení kontextu rate limitingu (tedy jako počítací charakteristiku). Nastavením charakteristiky rate limitingu na Cookie pravidlo seskupí požadavky z různých IP adres, ale patřící ke stejné session, což je běžný scénář při distribuovaném útoku botnetu.

Pravidlo č. 1

Nastavení Hodnota
Kritéria shody Bot Score less than 30 and URI Query String contains action=delete
Expression cf.bot_management.score lt 30 and http.request.uri.query contains "action=delete"
Charakteristiky počítání Cookie (session_id)
Frekvence (požadavky / období) 10 požadavků / 1 minuta
Akce Managed Challenge

Pravidlo č. 2

Nastavení Hodnota
Kritéria shody Bot Score less than 10 and URI Query String contains action=delete
Expression cf.bot_management.score lt 10 and http.request.uri.query contains "action=delete"
Charakteristiky počítání Cookie (session_id)
Frekvence (požadavky / období) 20 požadavků / 5 minut
Akce Block

Tato ukázková pravidla vyžadují Advanced Rate Limiting a Bot Management.

Pokud aplikace nepoužívá session cookie, můžete použít JA3 fingerprinty k identifikaci jednotlivých klientů. JA3 fingerprint je unikátní identifikátor dostupný zákazníkům s Bot Management, který Cloudflare umožňuje identifikovat požadavky přicházející od stejného klienta. Všichni klienti mají přiřazený fingerprint bez ohledu na to, zda jsou automatizovaní, či nikoli.

Nastavení Hodnota
Kritéria shody URI Path se rovná /merchant a Bot Score nižší než 10
Expression http.request.uri.path eq "/merchant" and cf.bot_management.score lt 10
Charakteristiky počítání JA3 Fingerprint
Frekvence (požadavky / období) 10 požadavků / 1 minuta
Akce Managed Challenge

Toto ukázkové pravidlo vyžaduje Advanced Rate Limiting a Bot Management.

Ochrana REST API

API mohou výrazně zatěžovat backend aplikace, protože API požadavky mohou být výpočetně nebo obslužně nákladné. Tyto požadavky mohou také vyžadovat složité operace (jako zpracování dat a rozsáhlá vyhledávání v datech), které při zneužití mohou origin server nakonec položit.

Prevence volumetrických útoků

Advanced Rate Limiting dokáže mitigovat mnoho typů volumetrických útoků, jako jsou DDoS útoky, mass assignment a exfiltrace dat.

Častým požadavkem je omezit POST akce. Pro autentizovaný provoz můžete použít API Discovery k určení vhodné frekvence požadavků pro jednotlivé endpointy a poté vytvořte pravidlo rate limitingu podobné následujícímu:

Nastavení Hodnota
Kritéria shody URI Path se rovná /endpoint1 a Request Method se rovná POST
Expression http.request.uri.path eq "/endpoint1" and http.request.method eq "POST"
Charakteristiky počítání Hlavička (x-api-key)
Frekvence (požadavky / období) Dle návrhu API Discovery nebo dle posouzení analýzou minulého provozu.
Akce Block

Toto ukázkové pravidlo vyžaduje Advanced Rate Limiting. API Discovery vyžaduje dodatečnou licenci.

Počítací charakteristikou může být jakákoli hlavička, klíč, token, cookie, parametr query, nebo dokonce pole JSON těla, protože některá API zahrnují session ID nebo user ID jako součást JSON těla. Další informace najdete v následujících částech:

Ochrana zdrojů

GET požadavky mohou také nadměrně zatěžovat aplikaci nebo mít dopad na nákladné zdroje, jako je šířka pásma. Představte si například aplikaci s velkým množstvím uložených souborů (například obrázků), kde si klienti mohou stáhnout soubor přístupem na jeho konkrétní URL:

GET https://api.store.com/files/<FILE_ID>
Header: x-api-key=9375

Pravděpodobně chcete omezit počet stažení, abyste zabránili zneužití, ale vzhledem k velikosti datového úložiště nechcete psát samostatná pravidla pro každý soubor. V takovém případě můžete napsat pravidlo jako toto:

Nastavení Hodnota
Kritéria shody Hostname equals api.example.com a Request Method se rovná GET
Expression http.host eq "api.example.com" and http.request.method eq "GET"
Charakteristiky počítání Path
Frekvence (požadavky / období) Dle návrhu API Discovery nebo dle posouzení analýzou minulého provozu.
Akce Block

Toto ukázkové pravidlo vyžaduje Advanced Rate Limiting.

Pravidlo definuje limit 10 stažení za 10 minut pro každý soubor pod https://api.store.com/files/*. Použitím Path jako charakteristiky pravidla se vyhnete nutnosti psát nové pravidlo pokaždé, když se objeví nový nahraný soubor s jiným <FILE_ID>. S tímto pravidlem se limit počítá na každý požadavek bez ohledu na zdrojovou IP nebo identifikátor session.

Path můžete také zkombinovat s x-api-key hlavičku (nebo IP, pokud nemáte klíč ani token) k nastavení maximálního počtu stahování, která smí provést konkrétní klient identifikovaný pomocí x-api-key, může s daným souborem provést:

Nastavení Hodnota
Kritéria shody Hostname equals api.store.com a Request Method se rovná GET
Expression http.host eq "api.example.com" and http.request.method eq "GET"
Charakteristiky počítání Cesta a hlavička (x-api-key)
Frekvence (požadavky / období) Dle návrhu API Discovery nebo dle posouzení analýzou minulého provozu.
Akce Block

Toto ukázkové pravidlo vyžaduje Advanced Rate Limiting.

Ochrana GraphQL API

Prevence přetížení serveru u GraphQL API se může lišit od prevence přetížení u RESTful API. Jednou z největších výzev aplikací postavených na GraphQL je, že všechny dotazy na server obsluhuje jediná cesta a každý požadavek je obvykle POST operaci. To znemožňuje různé rate limity pro různé případy užití API podle HTTP metody a cesty URI.

Na rozdíl od RESTful API, kde se používá metoda a cesta, je účel požadavku obvykle vložen v jeho těle, které obsahuje informace o tom, jaká data chce klient načíst nebo změnit (podle Terminologie GraphQL ↗ pro úpravu dat na straně serveru), spolu s dalšími daty potřebnými k provedení akce.

Abyste předešli přetížení serveru, zvažte následující přístupy:

  1. Omezte, kolikrát může konkrétní uživatel volat stejný název GraphQL operace.
  2. Omezte celkovou složitost dotazů, kterou smí daný uživatel požadovat.
  3. Omezte složitost dotazu každého jednotlivého požadavku.

Následující příklady vycházejí z aplikace, která přijímá recenze filmů. GraphQL požadavek by mohl vypadat takto:

POST https://moviereviews.example.com/graphql
Cookie: session_id=12345

Body:
{
  "data": {
    "createReview": {
      "stars": 5,
      "commentary": "This is a great movie!"
    }
  }
}

Omezení počtu operací

K omezení frekvence akcí byste mohli použít následující pravidlo:

Nastavení Hodnota
Kritéria shody URI Path se rovná /graphql a Body contains createReview
Expression http.request.uri.path eq "/graphql" and http.request.body.raw contains "createReview"
Charakteristiky počítání Cookie (session_id)
Frekvence (požadavky / období) 5 požadavků / 1 hodina
Akce Block

Toto ukázkové pravidlo vyžaduje Advanced Rate Limiting a inspekci payloadů.

Omezení celkové složitosti dotazů

Složitost potřebná ke zpracování GraphQL požadavku se může výrazně lišit. Protože API používá jediný endpoint, je obtížné zjistit složitost každého požadavku dříve, než je obsloužen.

K ochraně origin serveru před vyčerpáním zdrojů nepotřebujete omezovat počet požadavků, ale množství složitosti nutné k obsluze jednoho klienta za určité období. Cloudflare Rate Limiting vám umožňuje vytvářet pravidla, která sledovat složitost v čase a blokovat další požadavky po dosažení rozpočtu nebo limitu složitosti.

Tento typ rate limitingu vyžaduje, aby server každý obsloužený požadavek oskóroval podle jeho komplexity. Server navíc musí toto skóre přidat do odpovědi jako HTTP hlavičku. Mechanismus rate limitingu pak tuto informaci použije k aktualizaci rozpočtu daného klienta.

Například následující pravidlo definuje celkový rozpočet složitosti 1 000 za hodinu:

Nastavení Hodnota
Kritéria shody URI Path contains /graphql
Expression http.request.uri.path eq "/graphql"
Charakteristiky počítání Cookie (session_id)
Skóre za období 1,000
Období 1 hodina
Response header name score
Akce Block

Toto ukázkové pravidlo vyžaduje Advanced Rate Limiting a inspekci payloadů.

Když origin server zpracuje požadavek, přidá score HTTP hlavičku do odpovědi s hodnotou vyjadřující, kolik práce origin s jejím zpracováním měl — například 100. V následující hodině může stejný klient provádět požadavky až do dodatečného rozpočtu 900. Jakmile je tento rozpočet překročen, další požadavky budou blokovány, dokud nevyprší timeout.

Omezení složitosti jednotlivého dotazu

Zákazníci API Shield mohou k ochraně svých GraphQL API použít ochranu proti škodlivým GraphQL dotazům. Ta skenuje váš GraphQL provoz a hledá dotazy, které by mohly přetížit váš origin a způsobit odepření služby. Můžete vytvářet pravidla omezující hloubku a velikost příchozích GraphQL dotazů, a blokovat tak podezřele velké nebo složité dotazy.

Viz Dokumentace API Shield ↗ s dalšími informacemi o ochraně proti škodlivým GraphQL dotazům.

Poznámky pod čarou

  1. Název HTTP hlavičky používá chybný pravopis slova "referrer". ↩