Egyre több részlet derül ki az előválasztási rendszer leállásával kapcsolatban. A sok találgatás után végre megszólalt az aHang is, akik a rendszer építéséért és üzemeltetésért felelnek.

A Nemzeti Nyomozó Iroda Kiberbűnözés Elleni Főosztályára tett feljelentésük után egy kiberbiztonsági céget is megbíztak a támadás elemzésével. Ennek a vizsgálatnak jelenleg még nincs eredménye, így az eddig kiszivárgott, szakértők által publikus adatokból elemzett, illetve a nyilatkozatok alapján vonhatunk le következtetéseket.

Mit vonhatunk? Mi csak ugatjuk a témát.

Szerencsére itt van nekünk is a neve elhallgatását nyomatékosan kérő Szöllősi Gábor - alias Szögi,- a szakértők szakértője, infrastruktúra expert, a Hundub réme, a tiszteletes két pej csikajának jókedvű abrakolója.

A Kiberblog tehát nagy tisztelettel kéri meg a szakértők szakértőjét, tegye tisztába az előválasztási rendszerrel kapcsolatos félreértéseket és segítsen értelmezni a helyzetet!

- Mi a fene van ezzel, hogy 1 gigabites terheléses támadás mert nem látszik más a BIX-en? Egyáltalán, hogy épül fel egy ilyen támadás adatkarakterisztikája?

Szögi elemzése:

Az már a Kiberblog elemzéséből is kiderült, hogy az előválasztási rendszer egyes részeit a Cloudflare védte, de úgy tűnik, hogy egy másik, választásban részt vevő szerver kívülről is elérhető volt, ezt terhelhették túl, ami magával rántotta az alaprendszereket (ez jelenleg még mindig feltételezés – egészen addig, amíg nem lehet a naplókba belelátni).

Az aHang által közzétett, előzetes, szűkszavú incidens-idővonal szerint már a szombati teljes leállást megelőző nap is tapasztaltak anomáliákat, azonban ezek kritikus mértéket nem öltöttek.

Szombaton ezek után a tervezett terhelés többszörösét kapta a rendszer, bár konkrét számokat nem tudunk, de ezt már kezelni nem tudta, és elérhetetlenné vált.

(forrás: Netscout)

A rendszerleállást tárgyaló cikkek hatására megszólalt az eredeti infrastruktúra szolgáltató, az EZIT Kft, aki megerősítette, hogy valóban az ő szervertermében futottak az előválasztást lebonyolító informatikai rendszer szerverei, azonban erről őket előzetesen nem értesítette senki, így ők semmilyen plusz védelemmel vagy fokozott monitorozással nem készültek, illetve nem segítették a választást. Egy ilyen horderejű feladatnál szerintem érdemes lett volna előzetesen egyeztetni a szolgáltatóval, esetleg külön kiemelt figyelmet kérni az érintett szerverek hálózati forgalmára.

A Telex cikkében is megszólal egy névtelen szakértő, aki nem tartja különösebben nagy támadásnak azt a volument, ami rendszert érte, azonban ezt a helyén kezelném addig, amíg nem publikál valaki tényleges hálózati forgalmi adatokat.

Szintén ebben a cikkben esik szó a Pestisrácok által megkérdezett, szintén névtelen „szakértő” által megállapított tényekre, miszerint a támadásnak látszania kellene még a Budapest Internet Exchange (BIX) teljes forgalmában, illetve az EZIT publikus BIX forgalmi grafikonjain is.

A BIX teljes forgalma az érintett időszakban (forrás: BIX)

Ezt az állítást nézzük meg kicsit közelebbről.

BIX vagy nem BIX?

Az internet sosem volt egy centralizált rendszer. Már nagyon régen elmúlt az az állapot, hogy egy darab „kanóc” jött be az országba, és azon ment minden internet forgalom.

Ebben mutatkozik meg az internet ereje, hogy viszonylag nehéz globálisan kárt tenni benne, valamint ellenőrzés alá vonni (kivételek persze vannak, például Kínában).

Ezért butaság számonkérni két, központi mérési pont hálózati grafikonjait abból a szempontból, hogy egy szolgáltatónál elhelyezett szerver mennyi hálózati forgalmat kaphatott, és ez alapján eldönteni, volt-e avagy nem volt támadás.

BIX VH épület (forrás: BIX)

A Budapest Internet Exchange (budapesti adatcserélő központ) 1997-es, alapításkori célja az volt, hogy az akkor szegényes hazai infrastruktúrában biztosítsa, hogy a Magyarországon belül keletkező és Magyarországot célzó forgalom ne egy másik (külföldi) országon keresztül érjen célba – tehát kvázi országon belül maradjon a hazai hálózati forgalom.

Ennek elsődlegesen (a késleltetésen kívül) financiális okai voltak, hiszen a külföldi sávszélesség akkor nagyon drága volt. Ugyan ez a költség arányaiban az elmúlt közel 30 évben jelentősen csökkent, azonban még mindig nagyságrendi különbségek vannak egy hazai, illetve egy külföldi adattovábbítás között.

Az elmúlt években a BIX szerepe folyamatosan csökken, mivel az internet szolgáltatók is decentralizálták a hazai adatcseréjüket is, így a nagyobb szolgáltatók BIX-en kívül, közvetlenül cserélnek adatokat, hiszen ez minden, az adatcserében érintett szolgáltatónak közös érdeke, kvázi külső, költségmentes megoldás.

Míg régen sokat mondó volt a BIX teljes forgalmi grafikonja, illetve a BIX tagok saját routereinek publikus forgalma, manapság ez csak a teljes forgalmi kép egy szelete.

Egy nagyobb internet szolgáltatónak ugyanis akár több tíz kapcsolata lehet más internet szolgáltatókkal (ezt nevezzük (privát)peeringnek), amelyek forgalmára csak maguknak a szolgáltatóknak van rálátásuk, nem publikus információk. A belföldi forgalmon kívül általában legalább egy külföldi szolgáltatóval is kapcsolódnak a szolgáltatók, sőt a redundancia miatt adott esetben több cégtől is vesznek nemzetközi sávszélességet.

Az előválasztási rendszer internet szolgáltatója, az EZIT Kft például a RETN cégtől (is) vesz külföldi elérést, utóbbi cégnek egész kontinensünkre kiterjedt saját hálózata van (és további transzatlanti vonalakkal is rendelkezik), amit az alábbi ábrán is láthatunk.

(forrás: RETN)

Az eddigiekből belátható, hogy egy esetleges támadás hálózati volumenét legfeljebb az adott szolgáltatók tudják megadni, erre publikus adatokból csak tippelni tudunk.

EZIT BIX forgalma az érintett időszakban (forrás: BIX)

Kijelenteni, hogy „nem lehetett támadás, mert nem látszik jelentős és kiugró terhelés a BIX grafikonjában” tehát elhamarkodott következtetés, mivel az EZIT nemzetközi forgalma nem a BIX-en, hanem például a RETN (vagy éppenséggel a Cogent, Hurricane, stb) szolgáltatótól vásárolt sávszélességen keresztül is közlekedik, ezek a forgalmak tehát nem is jelenhetnek meg a BIX forgalmi adataiban.

EZIT IP tartományainak kapcsolatai  (Forrás: ASRank)

(Természetesen felmerülhet annak a lehetősége is, hogy bizonyos nemzetközi forgalmakat a szolgáltató nem a RETN vagy másik, nemzetközi partnerén keresztül fogad. Ennek több oka is lehet, például előfordulhatnak olyan forgalmak, amelyeket olcsóbb mégis inkább a BIX-en kicserélni, mint a nemzetközi partnerrel kiépített peeren keresztül. Ezt viszont már tényleg csak a szolgáltató tudja megerősíteni, erre kívülről nincsen rálátásunk.)

DDoS-olódni CloudFlare mögül?

Az előválasztási rendszer építője is elismerte, hogy egy szerver kilógott a Cloudflare védernyője alól – amelyet így közvetlenül, a Cloudflare védelmét kikerülve is meg lehetett szólítani és meg lehetett támadni. Felmerülhet azonban a kérdés, hogy akár az is megeshet, hogy egy szolgáltatást a Cloudflare megfelelően véd, mégis le lehet ültetni egy terheléses támadással?

Természetesen igen!

Egy rosszul megtervezett vagy kiviteletett infrastruktúra, vagy programkód esetében a nagy mennyiségű valós (azaz nem támadó szándékú) forgalom is „DDoS hatást” válthat ki egy rendszerben.

Hiába szűri ki a Cloudflare a gonosz gépi támadókat, egy teszteletlen, alulméretezett rendszerben a nagyobb, jóindulatú forgalom is megtalálhatja a rendszer szűk keresztmetszetét. Fontos, hogy a rendszer tesztelése ne szintetikus legyen, hanem tükrözze azokat az életszerű, a felhasználók által indított kéréseket, a megfelelő volumenben.

(forrás: Cloudflare)

A méret a lényeg?

Azt, hogy egy szerver ki tud-e szolgálni egy szolgáltatást több összetevőn is múlik.

Első körben lennie kell szabad hálózati sávszélességnek. Előfordulhat olyan eset, hogy a jóindulatú forgalom is például 1 Gb/s felett terhelné a szerver hálózati csatolóját, ami viszont csak ekkora sebességgel kapcsolódik a szolgáltató hálózatára. Ezért egy teszteléskor a komplett oldal letöltéseket vizsgálni kell, amik tartalmazzák a nagyobb sávszélességet igénylő médiaelemeket is (képek, videók, stb).

Amennyiben van elérhető sávszélesség, úgy a következő mérési pontnak a kérések számosságát tekinthetjük, amit RPS-ben (request per second, azaz másodpercenkénti kérésszám) adunk meg.

Még ezen belül is meg kell különböztetnünk azokat a kéréseket, amik statikusan kiszolgálhatók, tehát csupán minimális számítási erőforrást igényelnek, ezért inkább csak a hálózati sávszélességet fogyasszák.

Ezek a nem változó tartalmak, például egy oldal grafikai elemei, stíluslapjai, médiaelemei stb. A többi kérést már dinamikus kéréseknek nevezzük, amik kiszolgálásához valamiféle intelligencia szükséges. Ezek jöhetnek például adatbázisból, amik újabb lekérdezési erőforrásokat igényelnek, így ezek mindenképpen „költségesebbek” (azaz leterhelőbbek).

Egy rendszer sajátja, hogy mennyi statikus és dinamikus kérést képes kiszolgálni, ezeket a terheléses tesztekből tudjuk megállapítani. Ilyen tesztelések alkalmával az infrastruktúránk teljes karakterisztikáját érdemes felvenni, tehát a kérések számához társítani a válaszidőket, hogy az adott kiszolgálási volumenhez milyen felhasználói élmény tartozik (például gyorsak, vagy esetleg már lassulóak az oldalbetöltések).

Minden rendszernek lesz tehát egy letörési pontja (amennyiben nem a végtelenbe skálázzuk), ahol a kérések hatására az először belassul, majd „beborul”, elérhetetlenné válik. Ezen adatok ismeretében tudjuk méretezni a kiszolgáló erőforrásokat a hálózati sávszélesség/kapacitástól kezdve a processzor/memóriáig, amely egy bérelt vagy felhő alapú infrastruktúrát használva általában jobban, dinamikusabban skálázható.

(forrás: Guru99)

Önmagában tehát a Pestisrácok által feltételezett 1 gigabit terhelés sem mond semmit, mert nem csak a forgalom mennyisége, hanem a forgalom minősége, azaz összetétele (például statikus vagy dinamikus tartalmat kell kiszolgálnia a szervernek) és a kérések sebessége (RPS) is számít, illetve jelenleg egyáltalán nem kijelenthető, hogy a terhelésnek meg kellett volna jelennie a BIX terhelési grafikonjában.