← Všechny produkty

DDoS Protection

Cloudflare DDoS Protection automaticky detekuje a zmírňuje útoky typu denial of service na síťové i aplikační vrstvě u provozu, který prochází sítí Cloudflare. Tato stránka popisuje průběh mitigace, konfigurační objekty, omezení a dostupnost v jednotlivých plánech.

Řízení dokumentu

Dana
Technická redaktorka, Integrity Czech Republic s.r.o.

Přehled

Distribuovaný útok typu denial of service se snaží znepřístupnit službu tím, že vyčerpá některý zdroj: kapacitu linky, zpracování paketů, stav spojení nebo souběžnost aplikace. Útoky se obvykle dělí podle vrstvy. Útoky na síťové vrstvě (L3 a L4) míří na šířku pásma a zpracování paketů. Útoky na aplikační vrstvě (L7) posílají požadavky HTTP, které jsou jednotlivě v pořádku, a vyčerpávají výpočetní kapacitu origin serveru nebo jeho backendové závislosti.

Cloudflare zmírňuje útoky na provoz, který se dostane do jeho sítě: buď proto, že je hostname proxovaný přes Cloudflare, že jsou prefixy oznamované přes Magic Transit, nebo že aplikaci na TCP či UDP zastřešuje Spectrum. Provoz, který se k originu dostane jinou cestou, mitigaci nepodléhá.

Cloudflare uvádí, že mitigaci DDoS poskytuje ve všech plánech bez měření podle velikosti nebo četnosti útoku (https://developers.cloudflare.com/ddos-protection/, staženo 2026-08-28). Popisuje to účtování za zmírnění útoku, nikoli záruku dostupnosti při libovolné zátěži.

Cloudflare na své veřejné stránce o síti neuvádí kapacitu sítě v terabitech za sekundu (staženo 2026-08-28). Proto zde žádný údaj o kapacitě neuvádíme. Pokud potřebujete závazek ke kapacitě, sjednejte si ho ve smlouvě, nespoléhejte na dokumentaci.

Architektura

Cloudflare oznamuje stejné IP prefixy z několika svých datových center pomocí anycastu. Každý zdroj se směruje do nejbližší lokality, která prefix oznamuje, takže geograficky rozptýlený útok se rozdělí mezi mnoho lokalit místo toho, aby se sbíhal do jednoho čisticího centra. Mitigace tedy probíhá distribuovaně blízko zdrojů a mitigační kapacitu tvoří součet zapojených lokalit, nikoli kapacita jediného pracoviště.

V každé lokalitě porovnávají vzorkovací systémy vlastnosti paketů a požadavků s otisky útoků ve spravovaných sadách pravidel DDoS a s profily provozu. Při shodě se signaturou se na datovou cestu uplatní pravidlo zmírnění. Zmírnění na síťové vrstvě vynucují paketové filtry. Zmírnění na aplikační vrstvě vynucuje spravovaná sada pravidel HTTP DDoS Attack Protection, která odpovídající požadavky dokáže zablokovat nebo u nich zobrazit výzvu.

Zmírnění probíhá autonomně: platforma je uplatní bez zásahu zákazníka a bez žádosti o podporu. Cloudflare uvádí, že detekce i zmírnění začínají automaticky, garantovanou dobu do zmírnění ale nezveřejňuje, proto zde žádný časový údaj neuvádíme.

Existují tři modely doručování a mezi sebou se podstatně liší:

• Reverzní proxy. Provoz HTTP a HTTPS pro proxované hostname. Mitigace se uplatňuje na požadavky a adresa originu se v DNS neobjevuje.
• Spectrum. Libovolné aplikace TCP nebo UDP proxované přes Cloudflare, například pošta, herní protokoly nebo signalizace VoIP.
• Magic Transit. Zákaznické IP prefixy, které Cloudflare ohlašuje přes BGP; vyčištěný provoz se vrací do zákaznické sítě přes GRE, IPsec nebo CNI. Chráníte tak celé sítě včetně infrastruktury, která nepoužívá HTTP.

Možnosti

Model konfigurace

Cloudflare dodává ochranu před DDoS jako spravované sady pravidel v enginu sad pravidel, tedy ve stejném modelu, jaký používá WAF. Jednotlivá pravidla udržuje dodavatel a nelze je upravovat. Jejich chování se mění pomocí přepisů.

Existují dvě dimenze přepisů. Citlivost určuje, jak snadno se pravidlo spustí; úrovně se obvykle uvádějí jako default, medium, low a essentially off. Akce určuje, co se stane při shodě, například block, managed challenge nebo mírnější mitigace. Přepisy lze uplatnit na úrovni sady pravidel nebo jednotlivého pravidla, a pokud to plán podporuje, i s rozsahem daným výrazem.

Adaptive DDoS Protection se nastavuje samostatně a profiluje provoz podle dimenzí, například podle země klienta, ASN, user agenta nebo definované skupiny origin serverů. Nejprve se nasazuje v režimu monitorování a teprve poté se přepne na vynucování.

U Magic Transit zahrnuje konfigurace zavedení prefixů a řízení oznámení BGP, nastavení tunelů pro návrat čistého provozu a pravidla Magic Firewall pro filtrování na síťové vrstvě. U Spectrum zahrnuje konfigurace definici aplikace, adresu originu, protokol a port.

Všechny tyto objekty lze spravovat přes dashboard, API i poskytovatele Terraform.

Limity a omezení

Níže uvedené hodnoty a nároky vycházejí z dokumentace Cloudflare načtené 2026-08-28 a mohou se bez upozornění změnit.

• Zmírnění se uplatní jen na provoz, který prochází přes Cloudflare. Dostupná IP adresa origin serveru, hostname bez proxy nebo služba na portu, který zóna ani aplikace Spectrum nepokrývá, zůstávají vystavené přímo.
• Standardní ochrana zóny pokrývá HTTP a HTTPS. Pro protokoly mimo HTTP je potřeba Spectrum, pro ochranu celé sítě Magic Transit. Oba produkty jsou dostupné v tarifu Enterprise.
• Adaptive DDoS Protection vyžaduje plán Enterprise s předplatným Advanced DDoS Protection. Není součástí základního rozsahu žádného plánu.
• Podrobnost přepisů u spravované sady pravidel HTTP DDoS závisí na tarifu. Zóny s tarifem Free mají nejmenší možnosti řízení, což omezuje doladění falešně pozitivních detekcí.
• Pravidla DDoS pracují se vzorci provozu. Útoky na aplikační vrstvě, které se drží v běžných počtech požadavků, ale vyčerpávají náročný backend, pravidla DDoS zmírnit nemusí. Na ty jsou potřeba pravidla rate limiting, cachování nebo úpravy samotné aplikace.
• Cloudflare nezveřejňuje garantovanou dobu do zmírnění útoku ani údaj o kapacitě sítě. Závazky k dostupnosti vyplývají ze smlouvy a z příslušné smlouvy o úrovni služeb, nikoli z produktové dokumentace.
• Magic Transit vyžaduje minimální velikost prefixu pro oznámení přes BGP a také to, aby oznamovaný adresní prostor spravoval sám zákazník. Než začnete plánovat migraci adres, ověřte si u Cloudflare aktuální minimální velikost.
• Doba uchování dat v Analytics a dostupnost Logpush pro data o útocích se liší podle tarifu.

Dostupnost podle tarifu

Nasazení

Předpoklady.

• Vypište veřejné hostname, veřejné IP adresy, ohlašované prefixy, otevřené porty a služby mimo HTTP, tedy poštu, VPN endpointy a správcovská rozhraní.
• Poznamenejte si, které z nich lze vést přes proxy, které vyžadují Spectrum a které Magic Transit.
• Ověřte, zda IP adresa origin serveru někde neunikla: v protokolech Certificate Transparency, v historických záznamech DNS, v hlavičkách e-mailů odeslaných ze stejného hostitele, na chybových stránkách, které prozrazují název hostitele, a ve výchozích virtuálních hostitelích, kteří na dané IP adrese odpovídají.
• Zdokumentujte integrace, které musí fungovat během přepnutí i po něm: monitoring, platební callbacky, partnerská API a příchozí webhooky.
• Zaznamenejte si stávající konfiguraci DNS a hodnoty TTL, aby šlo změnu vrátit zpět.

Postupné ověřování. Nejdříve nasaďte reprezentativní neprodukční zónu nebo hostname. Ověřte, že proxování nemění chování aplikace, že se klientské IP adresy čtou ze správné hlavičky a že nastavení TLS odpovídá možnostem originu. Vygenerujte reprezentativní zátěž a potvrďte, že se u legitimního provozu nespouštějí výzvy typu challenge.

Konfigurace.

1. Zapněte proxy u dotčených hostname, oznamujte prefixy přes Magic Transit, případně definujte aplikace Spectrum pro služby mimo HTTP.
2. Vyměňte IP adresy origin serverů tak, aby dříve zveřejněné adresy aplikaci už neobsluhovaly.
3. Nastavte firewall na originu tak, aby přijímal provoz pouze z rozsahů IP adres Cloudflare (https://www.cloudflare.com/ips/), nebo vystavení příchozímu provozu zcela odstraňte tím, že origin server připojíte přes Cloudflare Tunnel.
4. Zapněte Authenticated Origin Pulls, aby origin odmítal spojení, která nepředloží klientský certifikát Cloudflare.
5. Zkontrolujte přepisy spravované sady pravidel HTTP DDoS. Výchozí citlivost ponechte beze změny, dokud nezaznamenáte konkrétní falešně pozitivní detekci.
6. Pokud máte licenci na Advanced DDoS Protection, nasaďte Adaptive DDoS Protection nejprve v monitorovacím režimu a teprve potom ji přepněte do vynucování.

Přepnutí provozu. Předem snižte TTL v DNS, provoz přepněte v dohodnutém okně a původní cestu k originu nechte dostupnou, ale zafiltrovanou na firewallu, dokud neproběhne ověření.

Ověření.

• Z externí sítě ověřte, že IP adresa origin serveru na portech 80 a 443 už na aplikaci neodpovídá.
• Podle vlastních protokolů ověřte, že monitoring, platební callbacky a integrace s partnery stále fungují.
• Spuštěním testovacího oznámení ověřte, že oznámení o útocích dorazí do zamýšleného kanálu.
• Ověřte, že protokoly origin serveru po proxování správně zaznamenávají IP adresu klienta.

Vrácení změn. Obnovte původní záznamy DNS nebo stáhněte ohlášení BGP, na firewallu originu znovu povolte předchozí zdrojové rozsahy a před uzavřením incidentu ověřte překlad i dostupnost. Rollback znovu odhalí adresu originu, berte ho proto jako dočasný stav a před dalším pokusem adresu znovu vyměňte.

Provozní hlediska

Upozornění na útoky směrujte do kanálu, který se sleduje i mimo pracovní dobu, a dohodněte si postup pro řešení incidentů, který určuje, kdo smí během útoku měnit přepisy sady pravidel. Přepisy provedené ve spěchu bývají častou příčinou dlouhotrvajících incidentů.

Během útoku rozlišujte mezi mitigovaným provozem a dopadem na origin. Vysoký počet mitigací při stabilní latenci originu znamená, že mitigace funguje. Pokud je naopak origin zasažený a počet mitigací nízký, jde obvykle buď o cestu, která ochranu obchází, nebo o útok podobný legitimnímu provozu, který se řeší spíš rate limitingem nebo cachováním než DDoS pravidly.

Omezení přístupu k originu průběžně aktualizujte. Rozsahy IP adres Cloudflare se mění, proto odebírejte publikované rozsahy a aktualizaci firewallu zautomatizujte. Závislost na seznamech adres odstraníte úplně, pokud nasadíte Cloudflare Tunnel.

Uchovávejte reporty po incidentech a porovnávejte je s metrikami z originu. Tam, kde je k dispozici Logpush, data exportujte a nespoléhejte na dobu uchování v dashboardu.

Počítejte s těmito způsoby selhání: adresa originu znovu odhalená z nově vydaného certifikátu, neproxovaná subdoména, kterou znovu založí automatizační skript, integrace třetí strany zablokovaná overridem citlivosti, který někdo nasadil během incidentu a nikdy nevrátil zpět, a poštovní infrastruktura ve stejném adresním prostoru jako webový origin.

Známá úskalí

• Samotné použití proxy adresu originu neutají. Adresy originu běžně unikají přes logy certificate transparency, historická data DNS, hlavičky odchozí pošty, špatně nastavené virtuální hosty a skenování IPv4. Cestu uzavře až změna adresy v kombinaci s firewallem na originu omezeným na rozsahy Cloudflare, případně Cloudflare Tunnel.
• Poštovní záznamy nesmí být proxovány. Pokud pošta a web sdílejí jednu adresu, samotná výměna adresy webového origin serveru nestačí: dokud neoddělíte poštovní infrastrukturu, zůstane adresa dohledatelná v hlavičkách e-mailů.
• Adaptivní ochrana není součástí základního produktu a vyžaduje předplatné Advanced DDoS Protection. Kdo s ní počítá jako se standardní funkcí, plánuje kapacity na chybném předpokladu.
• Útoky na aplikační vrstvě, které zůstávají pod prahovými hodnotami rychlosti, sada pravidel DDoS neřeší. Náročné vyhledávací endpointy, generování sestav bez ověření a necachované dynamické stránky vyžadují pravidla omezení rychlosti, cachování nebo kontrolní mechanismy na úrovni aplikace.
• Akce zmírnění mohou zasáhnout i legitimní automatizaci. Monitorovací sondy ani strojoví klienti nedokážou vyřešit akci challenge.
• Unmetered mitigation je údaj o účtování. Není to příslib, že útok jakékoli velikosti bude pohlcen bez dopadu na službu.

Interoperabilita

Spravované sady pravidel DDoS, pravidla WAF i pravidla rate limiting se vyhodnocují ve stejném enginu sad pravidel, a to v pořadí jednotlivých fází. Zmírnění DDoS řeší objemové záplavy s rozpoznatelným otiskem, WAF a rate limiting pak cílené zneužití konkrétních endpointů. Všechny tři se navzájem doplňují a obvykle se nastavují společně.

Na pole Bot Management se lze odkazovat v Custom rules a filtrovat tak automatizovaný provoz, který zůstává pod prahovými hodnotami DDoS.

Cloudflare Tunnel zcela odstraní vystavení originu příchozím spojením, a proto se dobře doplňuje s ochranou před DDoS u originů, které přímá spojení přijímat nepotřebují.

Magic Transit se doplňuje s Magic Firewall, který zajišťuje politiky na síťové vrstvě, a s Magic WAN pro propojení lokalit. Spectrum využívá pro protokoly mimo HTTP tytéž spravované sady pravidel DDoS.

Časté dotazy

Vztahuje se standardní tarif zóny i na jiné než HTTP služby? Ne. Plán zóny pokrývá HTTP a HTTPS pro proxované hostname. Služby na TCP a UDP vyžadují Spectrum, celé sítě pak Magic Transit.

Co musí být splněno, aby se zmírnění na službu použilo? Provoz musí procházet přes Cloudflare, tedy přes proxovaný záznam DNS, aplikaci Spectrum, ohlášení Magic Transit nebo Cloudflare Tunnel. Záznam v režimu DNS only žádnou mitigaci nedostane.

Jak se potvrdí podezření na obcházení ochrany? Porovnejte přístupové logy na originu s počty požadavků v Cloudflare za stejné období. Pokud se na originu objevují požadavky se zdrojovými adresami mimo rozsahy Cloudflare, vede k němu přímá cesta, kterou je nutné uzavřít na firewallu originu.

Zdroje

• https://developers.cloudflare.com/ddos-protection/, staženo 2026-08-28.
• https://developers.cloudflare.com/ddos-protection/managed-rulesets/, staženo 2026-08-28.
• https://developers.cloudflare.com/ddos-protection/managed-rulesets/adaptive-protection/, staženo 2026-08-28.
• https://developers.cloudflare.com/magic-transit/, staženo 2026-08-28.
• https://developers.cloudflare.com/spectrum/, staženo 2026-08-28.
• https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/, staženo 2026-08-31.
• https://www.cloudflare.com/ips/, staženo 2026-08-28.
• https://www.cloudflare.com/network/, staženo 2026-08-28.

Snímek obsahu: 2026-08-28.

Changelog