Čo je DDoS

DDoS (Distributed Denial of Service) je útok, ktorého cieľom nie je ukradnúť dáta, ale znefunkčniť službu — zahltiť server, sieťové zariadenie alebo aplikáciu takým množstvom prevádzky alebo požiadaviek, že legitímni používatelia sa k nej nedostanú. Rozdiel oproti staršiemu pojmu DoS (Denial of Service) je v slove "Distributed": namiesto jedného útočiaceho zariadenia útok prichádza súčasne z tisícov až miliónov zdrojov — typicky botnetu, siete infikovaných zariadení (počítačov, IoT kamier, routerov), ktoré útočník ovláda bez vedomia ich majiteľov. Distribuovaná povaha útoku sťažuje obranu dvoma spôsobmi: prevádzka prichádza z legitímne vyzerajúcich IP adries po celom svete, takže jednoduché blokovanie jednej zdrojovej adresy nepomôže, a súhrnný objem prevádzky ľahko prekročí kapacitu jedného pripojenia či servera, aj keď každé jednotlivé infikované zariadenie posiela len malé množstvo dát.

Náš predchádzajúci článok o kybernetických útokoch DDoS spomína ako jednu z bežných hrozieb; tento článok ide výrazne hlbšie — priamo do mechaniky protokolov, ktoré DDoS útoky zneužívajú, a do konkrétnych techník, ktorými sa proti nim brániš odvetvie na produkčnej úrovni.

TCP/IP do hĺbky: prečo je internet zraniteľný voči DDoS z princípu

Aby dávalo zmysel, prečo DDoS funguje tak, ako funguje, treba sa vrátiť k základom, ktoré sme rozobrali v článku o TCP/IP — konkrétne k dvom vlastnostiam, ktoré boli v 70. a 80. rokoch navrhnuté pre spoľahlivosť a jednoduchosť, nie pre bezpečnosť: absencia overenia zdrojovej adresy a stavová povaha TCP handshake.

Prečo sa dá IP adresa odosielateľa jednoducho sfalšovať

Každý IP paket obsahuje v hlavičke pole source address — no protokol IP je navrhnutý tak, že toto pole nikto po ceste neoveruje. Smerovače pri preposielaní paketu kontrolujú len cieľovú adresu, aby vedeli, kam paket poslať ďalej; odosielateľ si teda môže do source address poľa napísať ľubovoľnú hodnotu a paket bude smerovaný rovnako, akoby bol autentický. Táto technika sa nazýva IP spoofing a je základným stavebným kameňom väčšiny volumetrických DDoS útokov opísaných nižšie — umožňuje útočníkovi buď skryť skutočný pôvod útoku, alebo (v prípade reflection útokov) nasmerovať odpovede tretej strany priamo na obeť.

Jediná efektívna obrana na úrovni internetovej infraštruktúry je BCP 38 (ingress filtering) — odporúčanie, aby poskytovatelia internetu na hranici svojej siete zahadzovali odchádzajúce pakety, ktorých zdrojová adresa nepatrí do rozsahu pridelených ich vlastným zákazníkom. Problém je, že BCP 38 je len odporúčanie, nie vynútená požiadavka, a jeho nasadenie závisí od dobrej vôle tisícok nezávislých sietí po celom svete — preto IP spoofing zostáva funkčný dodnes, tri desaťročia po tom, čo bol tento problém prvýkrát zdokumentovaný.

SYN flood: zneužitie TCP three-way handshake

TCP nadväzuje spojenie tromi krokmi: klient pošle paket s príznakom SYN, server odpovie paketom SYN-ACK a zároveň si do tzv. SYN queue (backlog) alokuje pamäť pre nové, zatiaľ "polovičné" spojenie (half-open connection) v stave SYN_RCVD, a napokon klient odpovie paketom ACK, čím sa spojenie prepne do stavu ESTABLISHED. Kľúčový detail je, že server alokuje pamäť už po prijatí prvého SYN paketu — skôr, než má akúkoľvek istotu, že klient na druhej strane skutočne existuje a odpovie.

Pri SYN flood útoku útočník posiela obrovské množstvo SYN paketov, spravidla so sfalšovanou (spoofnutou) zdrojovou IP adresou. Server na každý z nich odpovie SYN-ACK paketom a čaká na ACK — ktorý nikdy nepríde, pretože spoofnutá adresa buď neexistuje, alebo patrí zariadeniu, ktoré o požiadavke nič nevie a SYN-ACK jednoducho zahodí. SYN queue sa rýchlo zaplní polovičnými spojeniami čakajúcimi na odpoveď, ktorá nepríde, a keď sa fronta zaplní úplne, server začne odmietať aj legitímne nové spojenia — nie preto, že by mu chýbala výpočtová kapacita, ale preto, že mu chýba pamäť vo fronte pre ich stavovú evidenciu.

Normálny handshake Klient Server SYN SYN-ACK ACK ESTABLISHED Spoofnuté IP Server tisíce SYN paketov SYN-ACK → do prázdna SYN queue plná — žiadne ACK nikdy nepríde
Normálny TCP handshake (vľavo) verzus SYN flood (vpravo): útočník so spoofnutou IP zaplní frontu polovičných spojení, ktoré sa nikdy nedokončia — legitímni klienti sa už do fronty nezmestia.

Reflection a amplifikácia: keď server namiesto teba "kričí" na obeť

Zatiaľ čo SYN flood zneužíva stavovosť TCP, reflection a amplification útoky zneužívajú opačnú vlastnosť — connectionless charakter protokolu UDP. UDP nemá žiadny handshake: klient jednoducho pošle paket a server naň odpovie bez toho, aby si čokoľvek overoval. Útočník túto vlastnosť skombinuje s IP spoofingom nasledovne:

  1. Útočník nájde verejne dostupný server podporujúci UDP službu, ktorá na malý dotaz odpovedá výrazne väčšou odpoveďou (napr. otvorený DNS resolver, NTP server alebo nesprávne nakonfigurovaná memcached inštancia).
  2. Pošle tomuto serveru dotaz, v ktorom sfalšuje zdrojovú IP adresu na adresu obete namiesto svojej vlastnej.
  3. Server v dobrej viere odošle svoju (oveľa väčšiu) odpoveď priamo na IP adresu obete — tá napokon dostane násobne viac dát, než koľko útočník musel skutočne odoslať.

Pomer medzi veľkosťou pôvodného dotazu a veľkosťou odpovede sa nazýva amplification factor a určuje, koľkonásobne útočník znásobí svoju vlastnú šírku pásma:

Protokol / službaAmplification factorPoznámka
Memcachedaž ~51 000×Použité pri útoku na GitHub v roku 2018 (1,35 Tbps, vtedy rekordný)
NTP (monlist)~556×Historicky jeden z najzneužívanejších vektorov pred zavedením opráv
DNS~30–50×Použité pri útokoch na Spamhaus v roku 2013
SNMPv2~6,3×Nižší faktor, ale stále zneužiteľný pri veľkých botnetoch
STUN~2,3×Nízky amplifikačný pomer, zriedkavejšie zneužívaný
Útočník malý dotaz, spoofnutý zdroj 64 B dotaz Otvorený DNS / NTP / memcached reflektor odpoveď 3–51 000× väčšia Obeť zahltená prevádzkou reflektor si myslí, že odpovedá obeti — tá dotaz nikdy neposlala
Reflection + amplification: útočník sa skryje za spoofnutú IP obete a nechá otvorený server "odpovedať" priamo na ňu — odpoveďou násobne väčšou, než bol pôvodný dotaz.

Fragmentačné útoky

IP protokol umožňuje rozdeliť veľký paket na menšie fragmenty, ktoré sa na cieľovom zariadení opäť poskladajú (reassembly). Staršie útoky ako Ping of Death zneužívali chyby v implementácii reassembly logiky — odoslaním fragmentov, ktoré po zložení vytvorili paket väčší, než aký operačný systém dokázal správne spracovať, čo viedlo k pádu alebo zamrznutiu cieľového systému. Teardrop útok zase posielal prekrývajúce sa fragmenty so vzájomne nekonzistentnými offsetmi, čo mätúce reassembly algoritmy staršich TCP/IP stackov dokázalo úplne zablokovať. Moderné operačné systémy sú voči týmto konkrétnym technikám už dávno odolné, no fragmentácia zostáva používaná aj dnes ako spôsob, ako obísť jednoduchšie firewall pravidlá, ktoré kontrolujú len hlavičku prvého fragmentu.

Klasifikácia DDoS útokov podľa vrstvy

KategóriaVrstvaPríkladyMeria sa v
VolumetrickéL3/L4UDP flood, ICMP flood, DNS/NTP/memcached amplifikáciaGbps / Tbps
ProtokolovéL3/L4SYN flood, ACK flood, fragmentačné útokypps (paketov za sekundu)
Aplikačné (L7)L7HTTP GET/POST flood, Slowloris, slow POSTRPS (requestov za sekundu)

Aplikačné útoky ako Slowloris sú obzvlášť zákerné, pretože nepotrebujú vysoký objem — namiesto zahltenia šírky pásma udržujú otvorené tisíce pomalých, neúplných HTTP spojení naraz (odosielajú hlavičky požiadavky extrémne pomaly, po jednom byte), čím vyčerpajú limitovaný počet súbežných spojení, ktoré webový server dokáže obslúžiť, aj keď celková prenesená prevádzka je minimálna a ťažko odlíšiteľná od pomalého mobilného pripojenia.

Pre kontext rozsahu: podľa priemyselných reportov najväčší doteraz zaznamenaný útok dosiahol v decembri 2025 31,4 Tbps (botnet Aisuru), pričom trval len 35 sekúnd — v porovnaní s rekordom 3,8 Tbps z októbra 2024 ide o nárast o viac než 700 % za 14 mesiacov, čo ilustruje, ako rýchlo rastie kapacita útočných botnetov postavených čoraz viac na nezabezpečených IoT zariadeniach.

Mitigačné techniky do hĺbky

SYN cookies: stateless riešenie SYN floodu

SYN cookies riešia problém SYN flood útoku elegantným trikom: namiesto alokovania pamäte v SYN queue hneď po prijatí SYN paketu server zakóduje informácie o spojení (zdrojovú a cieľovú adresu, port, časovú pečiatku) do kryptografického hashu, ktorý použije ako Initial Sequence Number (ISN) v odpovedajúcom SYN-ACK pakete — a žiadny stav si neukladá. Ak klient odpovie legitímnym ACK paketom, server z prijatého potvrdzovacieho čísla dokáže hash spätne overiť a zrekonštruovať potrebné informácie o spojení až v tomto momente. Keďže útočník pri spoofovanej adrese nikdy neodpovie platným ACK, server sa vôbec nenamáha alokovať preň zdroje — SYN queue sa tak fyzicky nemôže zaplniť, pretože v skutočnosti sa už nepoužíva ako úložisko stavu.

Remote Triggered Black Hole (RTBH): rýchle, ale hrubé

RTBH je najstaršia a najjednoduchšia sieťová obrana — operátor cez BGP oznámi trasu, ktorá presmeruje všetku prevádzku smerujúcu na napadnutú IP adresu do null route (odkiaľ sa pakety jednoducho zahodia). Funguje to prakticky okamžite a dokáže to nasadiť ktokoľvek s BGP session na upstream poskytovateľa, no má zásadnú nevýhodu: je to úplne indiskriminatívne opatrenie — spolu s útočnou prevádzkou sa zahodí aj všetka legitímna prevádzka smerujúca na danú adresu. RTBH v praxi znamená, že namiesto útočníka dokonáte prácu za neho — server je nedostupný, len z iného dôvodu.

BGP Flowspec: chirurgická alternatíva k RTBH

BGP Flowspec (RFC 5575, rozšírený v RFC 8955) rieši práve tento problém — namiesto blokovania celej cieľovej IP adresy umožňuje cez BGP distribuovať oveľa granulárnejšie pravidlá filtrovania, ktoré kombinujú viacero atribútov naraz: zdrojovú a cieľovú adresu, port, protokol, dĺžku paketu, TCP flagy a ďalšie. Každý router v sieti podporujúci Flowspec sa tak efektívne mení na distribuovaný firewall, ktorý dokáže pravidlo aplikovať v priebehu sekúnd naprieč celou sieťou poskytovateľa. Vďaka tejto granularite je možné napríklad zahodiť len UDP pakety s konkrétnou veľkosťou charakteristickou pre konkrétny amplifikačný útok, zatiaľ čo ostatná prevádzka na tú istú IP adresu prechádza ďalej bez prerušenia.

Anycast: rozptýlenie útoku naprieč globálnou sieťou

Anycast smerovanie umožňuje, aby tá istá IP adresa bola inzerovaná súčasne z desiatok či stoviek geograficky rozptýlených dátových centier; smerovacie protokoly automaticky nasmerujú prevádzku každého klienta do najbližšieho z nich. Pri DDoS útoku to znamená, že objem útočnej prevádzky sa automaticky rozdelí naprieč celou globálnou sieťou namiesto toho, aby sa sústredil na jedno miesto — útok s objemom, ktorý by dokázal zahltiť jedno dátové centrum, sa po rozptýlení naprieč stovkami lokácií stane pre každú z nich len zlomkom jej kapacity.

Scrubbing centrá a challenge-response pre L7

Scrubbing centrá sú dedikované zariadenia, cez ktoré sa počas útoku presmeruje všetka prevádzka (typicky práve cez BGP anonce alebo DNS zmenu) — v nich sa útočná prevádzka od legitímnej odfiltruje pomocou kombinácie vyššie uvedených techník a kontroly proti threat intelligence databázam, a späť k pôvodnému serveru sa vracia už len čistá prevádzka, spravidla cez GRE tunel alebo vyhradené L2 pripojenie. Pre aplikačné (L7) útoky, kde sa útočná prevádzka javí ako legitímne HTTP požiadavky, sa navyše používa challenge-response — CAPTCHA, JavaScript výzva vyžadujúca vykonanie kódu v prehliadači (čo automatizované boty spravidla nedokážu) alebo proof-of-work výzva, ktorá klienta núti vykonať drobný výpočet pred tým, než mu je požiadavka vôbec spracovaná — pre bežného používateľa nepostrehnuteľné oneskorenie rádovo v milisekundách, pre útočníka snažiaceho sa o milióny požiadaviek za sekundu výrazná prekážka.

Behaviorálna detekcia a strojové učenie

Moderné anti-DDoS platformy dnes kombinujú všetky vyššie uvedené techniky s behaviorálnou analýzou — systém si priebežne vytvára základnú líniu (baseline) toho, ako vyzerá normálna prevádzka pre konkrétnu aplikáciu (objem, distribúcia protokolov, geografický pôvod, veľkosť paketov, entropia zdrojových adries), a akúkoľvek štatisticky výraznú odchýlku od tejto línie označí ako podozrivú bez toho, aby musela zodpovedať vopred definovanému vzoru útoku. Tento prístup je kľúčový najmä pre L7 útoky, ktoré objemovo často vyzerajú ako legitímna špička návštevnosti — rozdiel odhalí až kombinácia viacerých behaviorálnych signálov naraz.

Ako sa bránia poprední anti-DDoS výrobcovia

Nasledujúci prehľad mapuje konkrétne architektonické prístupy a techniky, ktoré v roku 2026 verejne popisujú najvýznamnejší hráči na trhu anti-DDoS ochrany.

Cloudflare — čisto Anycast, žiadne samostatné scrubbing centrá

Cloudflare sa architektonicky odlišuje od väčšiny konkurencie tým, že nemá samostatné scrubbing centrá — každé z jej vyše 335 dátových centier vo viac než 120 krajinách dokáže útočnú prevádzku filtrovať lokálne, priamo tam, kam ju Anycast smerovanie doručí. Vďaka tomu odpadá zákazka na presmerovanie do vzdialeného scrubbing centra, čo Cloudflare umožňuje dosahovať latenciu mitigácie rádovo 1–10 ms a automatickú detekciu útoku pod 3 sekundy. Celková kapacita siete presahuje 200 Tbps, ochrana pred DDoS je súčasťou všetkých plánov vrátane bezplatného, a nasadenie pre HTTP/HTTPS prevádzku spočíva jednoducho v presmerovaní DNS záznamov cez Cloudflare.

Akamai Prolexic — dedikované scrubbing centrá a ľudský SOCC

Akamai ide opačnou, tradičnejšou cestou: prevádzkuje 32 anycast scrubbing centier v metropolitných mestách po celom svete s celkovou dedikovanou kapacitou vyše 20 Tbps. Prevádzka je počas útoku smerovaná cez Anycast do najbližšieho scrubbing centra, kde tím Security Operations Command Center (SOCC) — viac než 225 bezpečnostných inžinierov — nasadzuje proaktívne aj útoku šité na mieru mitigačné pravidlá. Vyčistená prevádzka sa vracia k zákazníkovmu pôvodnému serveru cez GRE tunel, L2 VLAN pripojenie alebo priame mapovanie VIP-to-origin, s minimálnym vnímateľným oneskorením. Kombinácia strojovej inteligencie s ľudským dohľadom robí z Prolexicu voľbu pre organizácie, ktoré chcú pri veľkých alebo neobvyklých útokoch priamy prístup k expertom, nie len k automatizácii.

AWS Shield Advanced — automatická mitigácia integrovaná do WAF

AWS Shield Advanced poskytuje automatickú inline mitigáciu naprieč vrstvami L3, L4 aj L7, využívajúcu globálnu threat intelligence AWS. Od marca 2026 je štandardnou ochranou proti HTTP request floodom Anti-DDoS Managed Rule Group pre AWS WAF, ktorá nahradila staršiu funkciu Layer 7 Auto Mitigation a dokáže útok zachytiť a zmierniť v priebehu sekúnd namiesto minút — systém si automaticky vytvára baseline normálnej prevádzky a prispôsobuje detekčné prahy správaniu konkrétnej aplikácie. Súčasťou je aj nepretržitá podpora špecializovaného tímu AWS Shield Response Team (SRT) a tzv. cost protection — čiastočná refundácia nákladov na automatické škálovanie infraštruktúry vyvolané samotným útokom.

Google Cloud Armor — Adaptive Protection založená na strojovom učení

Kľúčovou funkciou Google Cloud Armor je Adaptive Protection, ktorá pomocou strojového učenia mimo hlavného dátového toku (out-of-band) priebežne sleduje prevádzku a vytvára si baseline pre každú aplikáciu či službu zvlášť. Pri odhalení anomálie systém nevygeneruje len alert, ale rovno navrhne konkrétne, úzko cielené pravidlo filtrovania šité na daný útok, ktoré operátor môže jedným klikom nasadiť. Funkcia granular models umožňuje nastaviť Adaptive Protection tak, aby analyzovala prevádzku po jednotlivých hostoch alebo URL cestách zvlášť, čím sa výrazne znižuje počet falošne pozitívnych zásahov. Cloud Armor sa historicky sústreďuje predovšetkým na L7 útoky (HTTP GET/POST floody), doplnené o samostatnú vrstvu pokročilej sieťovej DDoS ochrany pre L3/L4.

NETSCOUT Arbor — hybridná on-prem a cloudová obrana

NETSCOUT ponúka hybridný model: Arbor Edge Defense beží priamo v sieti zákazníka a rieši menšie útoky lokálne bez akéhokoľvek presmerovania, no keď objem útoku prekročí lokálnu kapacitu, prevádzka sa automaticky presmeruje do Arbor Cloud — siete 16 globálnych scrubbing centier s kapacitou nad 15 Tbps. Detekcia aj orchestrácia mitigácie je poháňaná strojovým učením a globálnou threat intelligenciou, ktorá podľa výrobcu skracuje čas do zmiernenia útoku z hodín na sekundy. Tento hybridný prístup je typicky voľbou pre veľké podniky a poskytovateľov internetu, ktorí chcú kontrolu nad prvou líniou obrany vo vlastnej infraštruktúre, ale zároveň potrebujú poistku pre extrémne objemné útoky presahujúce vlastnú kapacitu.

Radware — hĺbková behaviorálna analýza vrátane šifrovanej prevádzky

Radware stavia svoju ochranu na behaviorálnom analytickom engine, ktorý si buduje viacrozmerný model normálnej prevádzky — nielen objemové prahy, ale aj distribúciu protokolov, distribúciu veľkostí paketov, entropiu zdrojových adries, geografické vzory a charakteristiky na aplikačnej vrstve. Zvláštnosťou Radware je behaviorálny TLS fingerprinting, ktorý dokáže rozpoznať útočné vzory v šifrovanej (HTTPS) prevádzke bez toho, aby ju musel dešifrovať — analýzou charakteristík samotného TLS handshake namiesto obsahu spojenia, čo umožňuje odhaliť L7 "Web DDoS" útoky bez narušenia súkromia legitímnych používateľov alebo nutnosti spracovávať súkromné šifrovacie kľúče zákazníka.

VýrobcaArchitektúraKapacitaCharakteristická technika
CloudflareČistý Anycast, žiadne scrubbing centrá>200 TbpsLokálna filtrácia v každom z 335+ dátových centier
Akamai Prolexic32 dedikovaných scrubbing centier20+ TbpsĽudský SOCC tím (225+ inžinierov) + GRE návrat prevádzky
AWS Shield AdvancedIntegrácia s AWS WAFGlobálna sieť AWSAnti-DDoS Managed Rule Group, automatický baseline
Google Cloud ArmorOut-of-band ML analýzaGlobálna sieť GoogleAdaptive Protection s automatickým návrhom pravidiel
NETSCOUT ArborHybrid on-prem + 16 cloud scrubbing centier15+ Tbps (cloud)Lokálna obrana (Edge Defense) + cloudové odľahčenie
RadwareBehaviorálny analytický engineVariabilná (hardvér/cloud)TLS fingerprinting bez dešifrovania
Model scrubbing centier útočná prevádzka Scrubbing centrum GRE Origin Anycast model PoP PoP PoP útok filtrovaný lokálne v každom PoP
Dva architektonické prístupy: presmerovanie do dedikovaných scrubbing centier (Akamai, NETSCOUT) verzus rozptýlenie a lokálna filtrácia naprieč Anycast sieťou (Cloudflare).

Kde DDoS ochrana zapadá do širšej architektúry

DDoS mitigácia sa v praxi zriedka nasadzuje ako izolovaný nástroj — typicky je jednou vrstvou širšej SASE architektúry, kde sa kombinuje s ZTNA na kontrolu prístupu a WAF pravidlami na filtrovanie aplikačnej vrstvy. Signály z DDoS mitigácie (napr. neobvyklý nárast objemu z konkrétnej geografickej oblasti) sa čoraz častejšie zasielajú aj do SIEM platformy na koreláciu s inými bezpečnostnými udalosťami — masívny DDoS útok totiž niekedy slúži len ako zásterka (tzv. smokescreen), za ktorou sa skrýva paralelný pokus o exfiltráciu dát, ktorý by inak samostatne upútal pozornosť tímu monitorovaného cez EDR/XDR.

Kapacita sama osebe nestačí

Aj firma s obrovskou šírkou pásma môže byť ochromená L7 útokom s relatívne nízkym objemom dát, pretože limitujúcim faktorom nie je šírka pásma, ale výpočtový výkon potrebný na spracovanie miliónov jednotlivých HTTP požiadaviek. Preto sa moderná ochrana nehodnotí len podľa Tbps kapacity scrubbing siete, ale rovnako aj podľa kvality L7 behaviorálnej detekcie — dva parametre, ktoré je potrebné posudzovať oddelene.

Zhrnutie

DDoS útoky fungujú preto, lebo zneužívajú vlastnosti, ktoré boli do TCP/IP zabudované zámerne — absenciu overenia zdrojovej adresy umožňujúcu IP spoofing, stavovú povahu TCP handshake umožňujúcu vyčerpanie SYN queue, a dôverčivú, connectionless povahu UDP umožňujúcu reflection a amplifikáciu s faktorom až 51 000×. Obrana sa odvtedy vyvinula do viacvrstvového systému — od stateless SYN cookies cez granulárne BGP Flowspec pravidlá až po globálne rozptýlené Anycast siete a behaviorálnu detekciu poháňanú strojovým učením. Poprední výrobcovia sa v konkrétnej implementácii líšia — Cloudflare stavia na čistom Anycast rozptýlení, Akamai na dedikovaných scrubbing centrách s ľudským dohľadom, Radware na hĺbkovej behaviorálnej analýze — no všetci riešia ten istý základný problém: ako odlíšiť milión legitímnych požiadaviek od milióna škodlivých v čase, keď obe skupiny vyzerajú na prvý pohľad rovnako.