Identifikace a mitigace DDoS útoku pomocí netflow analýzy ve FLOWCUTTERu.

ISP ve Velké Británii byl během dvou dnů terčem série DDoS útoků -
celkem 20 útoků během 48 hodin.

Každý útok:

• přetížil edge routery,

• způsobil výpadky internetu pro všechny zákazníky,

• trval zhruba 1 hodinu a více.

Hotline jela dvě hodiny v kuse na plné obrátky, zákazníci hlásili opakované výpadky.

Ráno třetího dne se technik rozhodl nasadit FLOWCUTTER, aby zjistil, co přesně se děje, a byl připraven na další vlnu.

Standardní monitoring (SNMP grafy) ukazoval, že je síť přetížená, ale:

• nebylo jasné, jaký typ útoku je použitý,

• kdo útočí,

• na jaký cíl je útok zaměřený.

Bez těchto informací je mitigace vždy jen napůl naslepo.

Cíl administrátora byl jasný:

1. Pochopit metodu útoku.

2. Identifikovat cílové IP adresy.

3. Najít způsob, jak útok odříznout dřív, než zasáhne celou síť.

V této situaci se nejvíc hodí netflow data - detailní pohled na provoz, který SNMP grafy nedají.

ISP proto:

1. nastavil netflow export z edge routerů do FLOWCUTTERu

2. začal analyzovat útok v reálném čase.

FLOWCUTTER jako nástroj pro netflow analýzu umožnil:

• vidět počet toků za sekundu (flows per second),

• rozlišit běžné a anomální chování,

• najít vektor útoku.

Podívejme se na zjištění z tohoto konkrétního případu distribuovaného DoS útoku.

Operátor si všiml anomálie v počtu příchozích spojení (flows per second). Hodnota vyskočila přibližně 25× oproti běžnému stavu před útokem.

Když operátor útok přiblížil v detailu, dokázal jasně rozpoznat vektor útoku. Nebyla to ale jednoduchá situace - útok byl plně distribuovaný. To znamená, že nešel jen z několika IP adres nebo ASN, ale z desítek tisíc zdrojů rozesetých po celém světě.

Příchozí pakety navíc používaly UDP a nebyly vázané na žádné konkrétní porty - ani na straně zdroje, ani cíle. V tomto konkrétním útoku ale mířily na několik vybraných cílových IP adres.

Celá přenosová kapacita byla zahlcená, takže operátor nemohl situaci jednoduše vyřešit tím, že by na firewallu nebo edge routeru zahazoval provoz na těchto několika cílových IP adresách.

Místo toho ISP útok mitigoval pomocí BGP komunit u upstream providerů - tak, aby se provoz na cílové IP adresy vůbec nedostal do jeho sítě.

• Analýza NetFlow dat v Grafaně

• Detekce (D)DoS útoků na základě flowů

• Mitigace útoků pomocí BGP

Pomoc intenzivnímu uživateli BitTorrentu tak, aby měl rychlejší a stabilnější stahování, a zároveň se ulevilo síti v celé lokalitě.

Při běžné analýze provozu si menší regionální ISP všiml nepravidelností v počtu aktivních spojení v jedné oblasti.

Ve většině domácností internet fungoval bez problémů.
V jednom konkrétním městě ale rádiové připojení nezvládalo špičky:

• krátké výpadky,

• zpoždění při DNS resolvu,

• obecně horší uživatelský zážitek.

Technická podpora často nemá nástroje, které:

• rychle ukážou kořen problému,

• a to v kontextu konkrétního zákazníka nebo části sítě.

Bez takového kontextu je jednodušší problém „nechat být“.
V tomto případě byla příčina několik zákazníků s velmi intenzivním používáním BitTorrentu.

Takové situace se časem nasčítají:

• zhoršují kvalitu služby,

• přidávají práci podpoře,

• a můžou přerůst v serióznější incident.

Řešení mělo dvě části:

1. Najít příčinu problému

Cílem bylo co nejrychleji získat přehled o provozu na úrovni zákazníků.

S FLOWCUTTERem má technik k dispozici přehledné analytické dashboardy, ve kterých:

• identifikoval konkrétní IP adresu s extrémním počtem spojení,

• viděl, že daný zákazník udržuje vysoký počet aktivních session,

• a že většina spojení běží na portu 6881 / UDP - typický vzor BitTorrentu.

Díky tomu nebylo potřeba odhadovat - stačilo se podívat na grafy a tabulky.

2. Rozumná mitigace místo zákazu 

Technická podpora zákazníka kontaktovala.
Místo „zakažte torrent nebo vás odpojíme“ se domluvili na:

• omezení počtu aktivních spojení v BitTorrent klientovi (cca na 20).

Zákazník zůstal spokojený - BitTorrent mohl používat dál, jen s rozumným nastavením.

Omezení počtu spojení:

• stabilizovalo síť v dané oblasti,

• zlepšilo zkušenost ostatních uživatelů,

• a překvapivě zrychlilo stahování i samotnému torrent uživateli - uvolněná spojení se lépe využila pro skutečný přenos dat.

Na grafech ve FLOWCUTTERu je vidět:

• výrazný pokles počtu aktivních spojení,

• a zároveň rychlejší a stabilnější download po zásahu podpory.

• Uživatelsky přívětivá analýza síťového provozu ve FLOWCUTTERu

Přidělování veřejných IP adres zákazníkům nese závažná rizika. Pokud je DNS port otevřený směrem do internetu, může vést k reflexnímu DDoS útoku, který následně zatěžuje síť poskytovatele.

Je deštivá neděle večer a většina domácností sleduje televizi nebo Netflix. Právě v tu chvíli začíná internetové připojení kolísat a nakonec zcela vypadne.

Zákaznická linka regionálního ISP je přetížená. Stovky zákazníků volají rozhořčeně operátorům a žádají okamžité vyřešení výpadku.

Síťový administrátor opouští večeři s rodinou a okamžitě začíná pracovat na nápravě.

Navzdory podrobné analýze SNMP telemetrie v Zabbixu se mu však nedaří najít příčinu problému.

Majitel firmy si uvědomuje, že pokud se něco podobného zopakuje o víkendu znovu, přijdou o zákazníky.

Síťový administrátor přechází na analýzu datového provozu pomocí NetFlow.

• ISP měl nasazený NetFlow export na všech core routerech

• Data byla průběžně odesílána do centrálního kolektoru se softwarem FLOWCUTTER

FLOWCUTTER se kromě jiného zaměřuje na detekci odchozích útoků, mezi nimi i DNS reflection útoků, které probíhají přes síť poskytovatele.

Právě ten byl identifikován – zdrojem byla zákaznická veřejná IP adresa. Zákazník omylem provedl tovární reset modemu s RouterOS, čímž se otevřel servisní port do internetu a zároveň zůstalo výchozí (slabé) heslo nezměněné.

Další analýza ukázala, že zařízení bylo kompromitováno a stalo se součástí botnetu, který byl použit k DNS reflexním DDoS útokům.

Administrátor následně IP adresu zablokoval a tím útok zastavil. Se zákazníkem se telefonicky spojil a problém společně vyřešili.

Zároveň nastavil denní skenování otevřených portů, aby byl podobný incident příště detekován včas. Příště už bude připraven.

Pojďme si projít NetFlow analýzu v době incidentu.

Útok byl jasně patrný při filtrování odchozího provozu ze zdrojového portu 53. Tento port je standardně vyhrazen pro DNS resolving a odpovědi by měly pocházet výhradně z DNS resolverů.

Přestože objem útoku byl jen 25 Mb/s, v kontextu agregovaného provozu ISP zůstal zcela neviditelný pro běžné monitorovací nástroje. Právě proto nebyl detekován ani zastaven dříve.

Útočící IP vykazovala známky DNS požadavků ze zahraničí – jednalo se o falešné dotazy využívané pro zesílení útoku.

Detailní rozbor potvrdil, že anomálie byla přímo spojená s DNS.

Díky pravidelnému skenování portů ve FLOWCUTTER bylo možné odhalit, že se problém odehrál na zákaznické síti.

V blízké budoucnosti bude navíc FLOWCUTTER umět detekovat DNS reflection útoky zcela automaticky, bez nutnosti zásahu síťového týmu.

• NetFlow analýza ve FLOWCUTTER
• Skenování otevřených portů
• SNMP vs. Flow telemetrie
• Detekce odchozích DNS reflection útoků

Kobercové bombardování mnoha ISP odhalilo rozdíly mezi reaktivním a proaktivním přístupem.

V květnu 2025 došlo k sérii DoS (Denial of Service) útoků, které byly zaměřeny na stovky evropských poskytovatelů internetu. Útoky měly podobu TCP SYN Flood a cílily na celé IP rozsahy operátorů – nikoli pouze na jednu IP adresu nebo jednu službu. Délka jednotlivých incidentů se pohybovala mezi 2 a 40 minutami. Útoky se však opakovaly několikrát denně po několik dní v řadě.

Během útoků byly páteřní (CORE) routery zahlceny množstvím příchozích pokusů o navázání spojení, což vedlo k výpadkům internetu pro celou zákaznickou základnu daného operátora.

Většina poskytovatelů internetu se rozhodla útok prostě „přečkat“ s nadějí, že si jejich zákazníci nebudou příliš stěžovat. Někteří se ale rozhodli útoku porozumět a být připraveni na příště.

Problém spočívá v tom, že běžné monitorovací nástroje používané v NOC (Network Operations Center), jako například Zabbix postavený na SNMP, neobsahují potřebné signály pro odhalení klíčových informací:

• Kdo je útočník
• Jaká metoda útoku byla použita
• A tím pádem chybí i „munice“ pro efektivní zmírnění útoku

Co s tím?

Právě v takových situacích přicházejí vhod data z NetFlow. Analýza NetFlow dat a detekce anomálií pomocí FLOWCUTTERu je ideálním řešením tohoto problému.

Zákazníci, kteří exportovali NetFlow data ze svých páteřních (CORE) routerů do FLOWCUTTERu, byli schopni útok zanalyzovat a snadno ho zmírnit.

Podívejte se na zjištění z tohoto konkrétního případu DoS útoku.

Operátor byl schopen zaznamenat anomálii v počtu pokusů o připojení (toků za sekundu).

Jejich počet během útoku vzrostl na desetinásobek běžného provozu před útokem.

Když operátor přiblížil časový úsek, ve kterém došlo k anomálii, byl schopen jasně rozpoznat vektor útoku.

Útok pocházel z AS 202425 se sídlem v Nizozemsku a za záplavu spojení byly zodpovědné čtyři IP adresy. Byl také odhalen způsob útoku: SYN Flood z několika málo zdrojových portů.

Poskytovatel internetu zmírnil následný útok buď odmítnutím veškerého provozu z daného AS, nebo zablokováním připojení z konkrétních IP adres.

Je však důležité poznamenat, že i když v tomto případě nebyla informace o zdrojových portech nezbytná pro mitigaci, v případě distribuovaného DDoS útoku by právě zdrojový port mohl být klíčovým prvkem pro mitigaci pomocí BGP Flowspec.

• Analýza NetFlow v Grafaně

• Obohacení o informace o zemi a ASN

• Detekce (D)DoS útoků na základě toků (Netflow)

Jak kompromitované routery ISP mohou odhalit útoky na OT sítě

Tato případová studie popisuje reálný kybernetický incident, který se může odehrát v moderních firemních sítích.

Jedna firma zaznamenala výpadky sítě a zhoršení výkonu, což mělo výrazný dopad na jejich výrobní síť typu OT (Operational Technology). Útočník pronikl do sítě skrze infrastrukturu poskytovatele internetu (ISP) a postupně se přiblížil k průmyslovým řídicím systémům a centrální databázi organizace.

• Fáze průzkumu: Útočník použil taktiku „spray and pray“ – náhodné skenování velkého počtu cílů za účelem nalezení zranitelností. Automatizované nástroje prohledávaly veřejné IP rozsahy a hledaly služby jako vzdálená správa (SSH, Winbox, Telnet), zastaralé webové aplikace a síťová zařízení.

  (Obrázek: MITRE ATT&CK® matice – vizualizace fází útoku)

Picture: MITRE ATT&CK® Matrix: visualization of attack phases

• Počáteční přístup: ISP provozoval zařízení založená na RouterOS. Jedno z těchto zařízení bylo kompromitováno kvůli zranitelnosti v zastaralém firmwaru. Útočník zneužil zranitelnost CVE-2022-45315, která umožňuje neoprávněné spuštění kódu pomocí speciálně vytvořených SNMP paketů. Tím získal přístup do jádra sítě ISP, mohl spouštět příkazy na dálku a vytvořit trvalý přístup.

• Eskalace práv a udržení přístupu: Útočník využil slabá hesla a chybně nastavená oprávnění, nasadil vlastní skripty, které zajistily přístup i po restartu systému.

• Postupné šíření: Infikovaný router ISP začal hrubou silou útočit na služby Telnet, SSH a Winbox v dalších zařízeních. Útočník mapoval vnitřní síť ISP a hledal routery, firewally a podniková hraniční zařízení vhodná k dalšímu zneužití.

(Obrázek: MITRE ATT&CK® matice – vizualizace fází útoku)

Picture: MITRE ATT&CK® Matrix: visualization of attack phases

• Kompromitace podnikové sítě: Útočník ovládl hraniční router firmy a navázal spojení se servery Command & Control (C2). K maskování aktivity používal DNS tunelování a šifrované HTTP požadavky, které běžné firewally nedokázaly detekovat.
• Vniknutí do OT sítě: Útočník se pokusil proniknout do výrobní OT sítě. Zahájil útoky hrubou silou na databázové servery a prováděl pomalé, cílené skenování OT segmentů. Vyhledával zranitelná zařízení.

  V tomto bodě byl útok detekován díky objemové analýze netflow dat. Došlo k zásahu dříve, než k úplnému průniku. Systémy detekce narušení (IDS) začaly generovat abnormální množství logů, což spustilo upozornění. Síťoví administrátoři útok zablokovali a dočasně izolovali napadenou síť, čímž zabránili větším škodám.

Útoky tohoto typu je obtížné detekovat, protože:

• Firewall monitoring selhal – útočník využíval důvěryhodnou infrastrukturu ISP k postupu v síti.
• Nepřítomnost EDR (Endpoint Detection and Response) na všech systémech omezila možnosti forenzní analýzy.
• Aktivita v OT síti zůstala téměř neodhalitelná, protože byla postupná a probíhala z důvěryhodných zařízení.

• Nasazení analýzy netflow dat na úrovni ISP pomohlo odhalit abnormální vzory v provozu.

• Klíčem k včasné detekci je korelace více datových zdrojů:

  • Netflow data
  • Výsledky skenování zranitelností
  • Logy z IDS systémů
  • Reputace IP adres a threat feedy
  • DNS telemetrie

Díky pokročilé síťové analýze, korelaci dat a proaktivnímu monitorování bezpečnostní týmy odhalily útok ještě před tím, než byly ohroženy kritické OT systémy.

Tato případová studie zdůrazňuje důležitost spolupráce mezi ISP a firmami při posilování kybernetické obrany.

✅ Monitoring firewallu nestačí – netflow data poskytují hlubší vhled do síťového provozu.

✅ Proaktivní bezpečnostní opatření na úrovni ISP mohou zastavit šíření útoků.

✅ Segmentace sítě a korelace více zdrojů logů zvyšuje šanci na detekci.

✅ Útoky často zneužívají nejslabší článek – v tomto případě zranitelnosti v infrastruktuře ISP.

Anomálie, kterou SNMP monitoring nezachytil, ale analýza provozního toků odhalila její příčinu a pomohla ISP udržet důležitého firemního zákazníka.

Důležitý firemní zákazník kontaktoval technickou podporu ISP s tím, že při používání Microsoft Teams dochází ke zpoždění (latencím). Správce sítě zkontroloval router, ke kterému byl tento zákazník připojen spolu s několika stovkami dalších klientů. Analyzoval data o latenci uložená v Prometheu.

Graf latence ukázal opakující se anomálii, která trvala 10 minut a opakovala se každou hodinu.

(Screenshot: latence v 30sekundových intervalech na routeru)

 Podobný trend byl vidět i u ztracených paketů a využití CPU.

Na základě SNMP telemetrie však správce nedokázal najít příčinu problému.

Co dál?

Správce sítě se rozhodl podívat na netflow data – tedy provozní telemetrii.

• ISP měl export netflow dat na všech CORE routerech.
• Toky byly průběžně odesílány do centrálního kolektoru se softwarem FLOWCUTTER.
• Díky FLOWCUTTERu mohl správce provést rychlou drill-down analýzu a najít příčinu problému.

Navíc bylo ve FLOWCUTTERu nastaveno pravidelné skenování otevřených portů. To pomohlo odhalit prvotní příčinu anomálie.

Na routeru, kde byl zákazník připojen, byla detekována anomálie – objem provozu klesal, ale počet komunikujících stoupal.

Drill-down analýza ukázala, že se jedná o DNS provoz.

Následně správce zkontroloval dashboard s výsledky nočního skenování otevřených portů. Ukázalo se, že jiný zákazník s veřejnou IP adresou otevřel DNS port veřejnosti. To vedlo k přetěžování routeru, které negativně ovlivnilo i ostatní zákazníky ve stejné oblasti.

Co lze během pár vteřin zjistit o zákazníkovi:

• Upload/download
• Porty a protokoly specifických služeb: FTP, Telnet, SSH
• IP adresa na blacklistu
• Komunikace s botnetem
• Otevřené porty a zranitelnosti přístupné zvenku

• Analýza netflow v Grafaně

• Skenování otevřených portů

• SNMP vs toková telemetrie

Mnoho příčin problémů nelze odhalit pouhým sledováním SNMP telemetrie. Zde pomáhají netflow data, která poskytují hlubší přehled o tom, kdo komunikuje s kým a jakým způsobem.

V tomto případě pomohlo i propojení netflow s dalšími daty – konkrétně skenem otevřených portů.

ISP problém snadno vyřešil:

• Zákazník, jehož zařízení způsobovalo potíže, byl kontaktován a upozorněn na chybnou konfiguraci.
• Port byl uzavřen a anomálie okamžitě ustaly.
• Pro klíčového firemního zákazníka se tím vyřešily problémy s latencí a vztah zůstal zachován.