Dvoudenní DDoS útok na britského ISP

Dvoudenní DDoS útok na britského ISP

Název

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

Situace

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.

 

Výzva

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íť.

    Řešení

    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.

    Výsledek

    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ě.

    Zdroje

    • Analýza NetFlow dat v Grafaně

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

    • Mitigace útoků pomocí BGP

    Závěr

    ISP, který byl 2 dny pod distribuovaným DDoS útokem, použil netflow data a FLOWCUTTER k tomu, aby:

    • identifikoval vektor útoku (způsob, cíle, rozsah),

    • pochopil, že jde o plně distribuovaný UDP útok bez konkrétního portu,

    • připravil si správnou mitigaci pomocí BGP communities u upstream providerů,

    • a tím eliminoval výpadky pro zákazníky.

    FLOWCUTTER v tomto scénáři:

    • dává síťaři data a kontext pro rozhodnutí,

    • umožňuje rychle odlišit „běžné přetížení“ od cíleného DDoS,

    • a pomáhá zvolit takovou mitigaci, která řeší problém ještě před vstupem provozu do sítě ISP.

    Jak jsme uživateli BitTorrentu zrychlili stahování a ulevili síti

    Jak jsme uživateli BitTorrentu zrychlili stahování a ulevili síti

    Název

    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ě.

    Situace

    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.

    Výzva

    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í

    Ř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.

    Výsledek

    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.

    Zdroje

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

    Závěr

    V tomto případě byla technická podpora zdrojem pozitivní změny:

    • zákazník dostal lepší a stabilnější internet,

    • síť se zklidnila a odlehčila,

    • operátor získal konkrétní příklad, proč se vyplatí mít kontext provozu až na úroveň uživatele.

    FLOWCUTTER v tom pomohl tím, že:

    • dává podporám kontext provozu konkrétního zákazníka,

    • nabízí uživatelsky přívětivé dashboardy, kterým rozumí i první linie podpory,

    • umožňuje při hovoru se zákazníkem vidět, co se v jeho provozu děje, a reagovat na základě dat, ne dojmů.

    Takto může ISP podpora místo „hasení požárů“ aktivně zlepšovat kvalitu služby – a zákazník to pozná.