INTEGRITY Dokumentace

Rate Limiting (předchozí verze)

Cloudflare Rate Limiting automaticky identifikuje a mitiguje nadměrné frekvence požadavků na konkrétní URL nebo na celou doménu.

Frekvence požadavků se počítají lokálně pro jednotlivá datová centra Cloudflare. Nejběžnější použití Rate Limitingu jsou:

Jakmile jednotlivá IPv4 adresa nebo IPv6 /64 IP rozsah překročí práh pravidla, další požadavky na origin server jsou blokovány s HTTP 429 stavový kód odpovědi. Odpověď obsahuje Retry-After hlavičku, která označuje, kdy může klient pokračovat v odesílání požadavků.

Rate limiting a SEO

Zdroje v cache a známí crawleři vyhledávačů jsou z vašich pravidel rate limitingu vyňati (pouze předchozí verze). Neovlivňují tedy u vašeho webu SEO hodnocení.


Dostupnost

Počet povolených pravidel rate limitingu závisí na plánu domény:

Plán Pravidla Pravidla porovnávající hlavičky odpovědí Akce Doba trvání akce Období požadavků
Free 1 1 Block 1 minuta nebo 1 hodina 10 sekund nebo 1 minuta
Pro 10 1 Block, Non-Interactive Challenge, Managed Challenge, Interactive Challenge nebo Log 1 minuta nebo 1 hodina 10 sekund nebo 1 minuta
Business 15 10 Block, Non-Interactive Challenge, Managed Challenge, Interactive Challenge nebo Log 1 minuta, 1 hodina nebo 24 hodin 10 sekund, 1 minuta nebo 10 minut
Enterprise 100 10 Block, Non-Interactive Challenge, Managed Challenge, Interactive Challenge nebo Log Libovolná doba trvání mezi 10 sekundami a 86 400 sekundami (24 hodin) Jakákoli hodnota mezi 10 sekundami a 3 600 sekundami (1 hodina)

Cloudflare Rate Limiting podporuje více úrovní kontroly konfigurace v závislosti na Cloudflare plánu domény. Tabulka níže shrnuje, co můžete dělat podle svého plánu:

Pořadí Úloha Dostupné v
1 Konfigurace základního pravidla rate limitingu Všechny plány
2 Konfigurace Advanced Criteria Plány Business a Enterprise
3 Konfigurace Advanced Response Plány Business a Enterprise
4 Konfigurace možnosti Bypass Plán Enterprise

Součásti pravidla rate limitingu

Pravidlo rate limitingu se skládá ze tří samostatných komponent:

Kritéria porovnávání požadavků

Příchozí požadavky se porovnávají podle cesty požadavku, schématu, metody a (volitelně) návratového kódu originu.

Cesta požadavku

Například:

Cesta požadavku nerozlišuje velikost písmen. Vzory nemohou odpovídat obsahu za query stringem (?) nebo kotvy (#). Hvězdička (*) odpovídá libovolné posloupnosti znaků, včetně prázdné. Například:

Požadavek na example.com/path není totéž co example.com/path/. Jedinou výjimkou z tohoto pravidla je domovská stránka: example.com odpovídá example.com/.

Schéma požadavku

HTTP nebo HTTPS. Pokud není žádný uveden, odpovídají oba a pravidlo zobrazí __ALL__.

Metoda požadavku

POST nebo GET. Pokud není žádná uvedena, odpovídají všechny metody a pravidlo zobrazí __ALL__.

(Volitelné) Kód odpovědi originu

Například nechte pravidlo rate limitingu odpovídat jen tehdy, když origin server vrátí HTTP 401 nebo 403 (stavový kód). Spuštěné pravidlo odpovídající kritériím kódu odpovědi blokuje následné požadavky od daného klienta bez ohledu na návratový kód originu.

Kritéria porovnávání frekvence

Pravidlo může porovnávat počet a časové období všech požadavků přicházejících od stejného klienta.

Počet požadavků

Zadejte minimálně dva požadavky. Pro blokování jediného požadavku cestu znepřístupněte — například nakonfigurujte svůj origin server, aby vracel HTTP 403 (stavový kód).

Období požadavků

Pravidlo se spustí, jakmile požadavky klienta překročí práh za stanovené období.

Mitigace pravidla

Mitigace pravidla se skládají z mitigační akce a doby trvání zákazu.

Mitigační akce

Akce rate limitingu závisejí na plánu domény, jak je uvedeno v Dostupnost:

Více informací o challenge akcích najdete v Challenge.

Doba trvání blokace

Nastavení timeoutu kratšího než práh způsobí, že API timeout automaticky zvýší na hodnotu prahu.

Návštěvníci, kteří narazí na rate limit, obdrží výchozí HTML stránku, pokud vlastní chybová stránka není zadáno. Zákazníci Business a Enterprise navíc mohou odpověď určit přímo v pravidle. Viz Konfigurace Advanced Response s podrobnostmi.


Identifikace prahů rate limitu

K určení obecného prahu pro Cloudflare Rate Limiting vydělte počet nekešovaných požadavků na web za 24 hodin počtem unikátních návštěvníků za stejných 24 hodin. Poté vydělte odhadovanou průměrnou délkou návštěvy v minutách. Nakonec vynásobte 4 (nebo více), abyste získali odhadovaný práh za minutu pro svůj web. Hodnota vyšší než 4 je v pořádku, protože většina útoků je řádově nad běžnou frekvencí provozu.

K určení rate limitů pro konkrétní URL použijte 24 hodin nekešovaných požadavků a unikátních návštěvníků pro danou URL. Prahy upravujte podle hlášení uživatelů a vlastního monitoringu.


Úloha 1: Konfigurace základního pravidla rate limitingu

Následující části pokrývají dva běžné typy pravidel rate limitingu.

Zapnutí Protect your login

Rate Limiting nabízí na jedno kliknutí Ochrana přihlášení nástroj, který vytvoří pravidlo blokující klienta na 15 minut, pokud odešle více než 5 požadavků POST během 5 minut. To stačí k zablokování většiny brute-force pokusů.

  1. Přihlaste se do Dashboard Cloudflare, a vyberte svůj účet a doménu.
  2. Přejděte na Security > WAF > Pravidla rate limitingu.
  3. V části Rate Limiting, vyberte Ochrana přihlášení.
  4. Zadejte Název pravidla a Zadejte URL své přihlašovací stránky v Ochrana přihlášení v dialogu, který se zobrazí.
  5. Vyberte Save.
  6. The Název pravidla se zobrazí v Rate Limiting seznamu pravidel.

Vytvoření vlastního pravidla rate limitingu

  1. Přihlaste se do Dashboard Cloudflare, a vyberte svůj účet a doménu.

  2. Přejděte na Security > WAF > Pravidla rate limitingu.

  3. Vyberte Create rate limiting rule. Otevře se dialog, kde zadáte podrobnosti nového pravidla.

    Dialog Create rate limiting rule s příkladem konfigurace pravidla. Pravidlo bude na jednu hodinu blokovat požadavky z IP adres, které překročí 150 požadavků za minutu.
  4. Zadejte popisný název pravidla do Název pravidla.

  5. Pro If Traffic Matching the URL, vyberte HTTP schéma z rozbalovací nabídky a zadejte URL.

  6. V ze stejné IP adresy překročí, zadejte celé číslo větší než 1 představující počet požadavků ve vzorkovacím období.

  7. Pro požadavků za, vyberte vzorkovací období (období, během kterého se požadavky počítají). Domény na plánech Enterprise mohou ručně zadat libovolnou dobu mezi 10 sekundami a 3 600 sekundami (jednou hodinou).

  8. Pro Poté, vyberte jednu z dostupných akcí podle svého plánu. Projděte si Mitigace pravidla sekci.

  9. Pokud jste vybrali Block nebo Log, pro odpovídající provoz od tohoto návštěvníka po dobu, vyberte, jak dlouho se má možnost uplatňovat po překročení prahu. Domény na plánech Enterprise mohou zadat libovolnou hodnotu mezi 10 sekundami a 86 400 sekundami (24 hodin).

  10. K aktivaci nového pravidla vyberte Save and Deploy.

Nové pravidlo se objeví v seznamu pravidel rate limitingu.

Obecně platí, že při nastavení nižšího prahu:

  1. Ponechte existující pravidla na místě a přidejte nové pravidlo s nižším prahem.
  2. Jakmile je nové pravidlo na místě, počkejte, než uplyne doba akce starého pravidla, a teprve poté staré pravidlo smažte.

Při nastavování vyššího prahu (kvůli blokování legitimních klientů) zvyšte práh v rámci existujícího pravidla.


Úloha 2: Konfigurace pokročilých kritérií (pouze plány Business a Enterprise)

The Advanced Criteria určuje, které HTTP metody, hlavičky odpovědí a stavové kódy odpovědi originu se mají pro vaše pravidlo rate limitingu vyhodnocovat.

Konfigurace pokročilých kritérií pro nové nebo existující pravidlo:

  1. Rozbalte Advanced Criteria.

    Dostupná pole při konfiguraci Advanced Criteria pro pravidlo rate limitingu.
  2. Vyberte hodnotu z Metody. Výchozí hodnota je ANY, což odpovídá všem HTTP metodám.

  3. Filtrujte podle HTTP hlavičky odpovědi. Vyberte Add header response field pro zahrnutí hlaviček vracených vaším origin webovým serverem.

    The CF-Cache-Status hlavička se zobrazuje ve výchozím nastavení, aby Cloudflare kešované zdroje obsluhoval, místo aby na ně uplatňoval rate limiting. Chcete-li rate limiting uplatnit i na kešované zdroje, odeberte tuto hlavičku výběrem X nebo povolte Also apply rate limit to cached assets.

    Pokud máte více než jednu hlavičku v HTTP hlavičky odpovědi, AND se uplatňuje booleovská logika. Chcete-li hlavičku vyloučit, použijte Not Equals možnosti. U hlaviček se nerozlišuje velikost písmen.

  4. V části Origin Response code(s), zadejte číselnou hodnotu každého HTTP kódu odpovědi, který má odpovídat. Dva a více HTTP kódů oddělte čárkou (například: 401, 403).

  5. (Volitelné) Nakonfigurujte další funkce rate limitingu podle svého plánu.

  6. Vyberte Save and Deploy.


Úkol 3: Konfigurace Advanced Response (pouze plány Business a Enterprise)

The Advanced Response možnost konfiguruje formát informací vracených Cloudflare při překročení prahu pravidla. Použijte Advanced Response pokud chcete vracet statický prostý text nebo obsah JSON.

Konfigurace textové nebo JSON odpovědi:

  1. Rozbalte Advanced Response.

    Dostupná pole při konfiguraci Advance Response pro pravidlo rate limitingu.
  2. Vyberte Typ odpovědi formát jiný než výchozí: Custom JSON nebo Custom TEXT.

  3. Zadejte odpověď v prostém textu nebo JSON, kterou chcete vracet. Maximální velikost odpovědi je 32 KB.

  4. (Volitelné) Nakonfigurujte další funkce rate limitingu podle svého plánu.

  5. Vyberte Save and Deploy.

Použití vlastní HTML stránky nebo přesměrování

Pokud chcete zobrazit vlastní HTML stránku, nakonfigurujte vlastní stránku pro HTTP 429 chyby (Too many requests) v dashboardu. Cloudflare tuto stránku zobrazí, když vyberete Výchozí stránka Cloudflare Rate Limiting v Typ odpovědi (výchozí hodnota pole).

K přesměrování rate-limitovaného klienta na konkrétní URL můžete použít následující metodu:

  1. Vytvořte na svém serveru HTML stránku, která přesměruje na konečnou URL stránky, kterou chcete zobrazit. Vložte meta refresh tag v obsahu stránky, jako v následujícím příkladu:

    <!doctype html>
    <html>
    	<head>
    		<meta charset="utf-8" />
    		<title>Custom RL page</title>
    		<meta
    			http-equiv="refresh"
    			content="0; url='https://yourzonename/block'"
    		/>
    	</head>
    
    	<body></body>
    </html>

    Poznamenejte si veřejnou URL stránky, kterou jste vytvořili.

  2. V Cloudflare dashboardu přejděte na Settings stránku.

    Přejděte na Konfigurace ↗
  3. Přejděte na Error Pages.

  4. Vedle Blokace rate limitingem, vyberte tři tečky > Edit.

  5. Vyberte Vlastní stránka.

  6. V Adresa vlastní stránky, zadejte URL stránky, kterou jste vytvořili na svém serveru — stránky obsahující meta refresh tagem.

  7. Vyberte Save.

Stejný postup použijte, pokud chcete vracet prostý text nebo obsah JSON, ale odpověď je větší než 32 KB. V takovém případě by URL přesměrování byla URL textového nebo JSON zdroje, který chcete zobrazit.


Úkol 4: Konfigurace možnosti Bypass (pouze plány Enterprise)

Bypass vytváří allowlist nebo výjimku, takže se na konkrétní sadu URL neaplikují žádné akce, i když je rate limit dosažen.

Chcete-li nakonfigurovat Bypass:

  1. Rozbalte Bypass.

  2. V Pravidlo bypass pro tyto URL, zadejte URL, které mají být z pravidla rate limitingu vyňaty. Každou URL zadejte na samostatný řádek. HTTP nebo HTTPS uvedené v URL se při uložení pravidla automaticky odstraní a pravidlo se pak vztahuje na HTTP i HTTPS.

    Konfigurace dvou URL pro bypass pravidla rate limitingu (jedna na řádek).
  3. (Volitelné) Nakonfigurujte další funkce rate limitingu podle svého plánu.

  4. Vyberte Save and Deploy.


Analytics

Analytiku rate limitingu pro svou zónu zobrazíte v Analytika a logy > Security. Analytika Rate Limitingu používá plné čáry pro provoz odpovídající simulovaným požadavkům a tečkované čáry pro skutečně zablokované požadavky. Logy generované pravidlem rate limitingu jsou viditelné pouze pro zákazníky Enterprise prostřednictvím Cloudflare Logs.

Cloudflare vrací HTTP 429 chybu pro blokované požadavky. Podrobnosti o blokovaných požadavcích podle lokality jsou zákazníkům Enterprise k dispozici v Stavové kódy v analytickém dashboardu dostupném na Analytics > Provoz.


Pořadí vykonávání pravidel

Pravidla rate limitingu se vyhodnocují od naposledy vytvořeného pravidla po nejstarší.

Například pokud požadavek odpovídá následujícím dvěma pravidlům:

Pak se jako první spustí pravidlo č. 2, protože bylo vytvořeno jako poslední.

Navíc, když dojde ke shodě a WAF aplikuje Log, pokračuje ve vyhodnocování dalších pravidel rate limitingu, protože Log je neterminující akce. Pokud WAF uplatní jakoukoli jinou akci, žádná další pravidla se nevyhodnotí.


Omezení

Rate Limiting je navržen k omezení nárazů provozu překračujících uživatelem definovanou frekvenci. Systém není navržen tak, aby na origin server propustil přesný počet požadavků. Mezi detekcí požadavku a aktualizací interního čítače může vzniknout zpoždění. Kvůli tomuto zpoždění, které může činit až několik sekund, se nadlimitní požadavky mohou na origin dostat ještě předtím, než je vynucena akce jako blokování nebo challenge.