Az idei év egyik sokat emlegetett fogalma a terheléses támadás: a koronavírus-járvány alatt a kormány több ízben hivatkozott erre, amikor összeomlott egy-egy járványügyi vagy közigazgatási honlap. Ilyen emlékezetes eset történt április 30-án, mikor a kabinet váratlanul oltási akciót hirdetett, viszont a regisztrációs honlap órákra elérhetetlenné és használhatatlanná vált. Szakértői vélemény szerint viszont nem támadás érte a rendszer, inkább arról lehetett szó, hogy az infrastruktúra nem bírta a vakcinára jelentkező felhasználók rohamát.

Kapcsolódó Nem valószínű, hogy valóban terheléses támadás érte a vakcinafoglalós oldalt A megkérdezett szakértő szerint nagyon kevés az esélye, hogy valóban DDoS támadás miatt vált elérhetetlenné a Pfizer-vakcina foglalása.

Közelmúltbeli példa a szeptember 18-án indult ellenzéki előválasztás és annak online rendszere, ami az első napon mondta fel a szolgálatot. Szeptember 27-én Frész Ferenc kiberbiztonsági szakértő vizsgálati eredménye is elérhetővé vált az incidenssel kapcsolatban, ami kétséget kizáróan bizonyítja, hogy ekkor tényleg támadássorozat érte az előválasztást is kiszolgáló infrastruktúrát.

Terheléses támadásnak, azaz DDoS-nek (Distributed Denial of Service) nevezzük, mikor a támadók szánt szándékkal elérhetetlenné tesznek egy weboldalt vagy szolgáltatást a felhasználók számára. Egy ilyen támadást kivitelezni nem bonyolult: annyi kérést (lényegében oldalbetöltést) kell küldeni a kiszemelt célpontnak, amennyit már nem tud kiszolgálni a weboldal mögötti infrastruktúra. Amennyiben ez bekövetkezik, megtörténik a szolgáltatás megtagadása, vagyis a Denial of Service ? ilyenkor használhatatlanná és elérhetetlenné válik az adott weboldal. Fontos, hogy az ilyen támadások lekéréseit nem felhasználók, hanem erre a célra összegyűjtött eszközök (vírussal fertőzött számítógépek és IoT kütyük) egész hálózata, úgynevezett botnetek végzik.

Egy weboldal vagy szolgáltatás elérhetetlenné válása azonban nem mindig jelenti azt, hogy terheléses támadás történt, a szakértők számára is időbe telik ennek igazolása. Akadnak hétköznapibb, rendeltetésszerű használatból eredő esetek is: például, amikor a Star Wars VII. rész ? Az ébredő Erő magyar premierje előtt megnyílt a jegyeladás, a Cinema City weblapja nem azért adta meg magát, mert DDoS támadás érte, hanem azért, mert az üzemeltetők nem voltak felkészülve az érdeklődésre. Vagy elég csak a novemberi Black Friday akciókra gondolni, amikor a webáruházak szintén akadoznak, akár meg is rogynak a megnövekedett forgalom miatt.

A felhasználók ilyenkor csak annyit tapasztalnak, hogy a weboldalak és rendszerek nem tudják betölteni a szerepüket, kiszámíthatatlanul viselkednek, a háttérben viszont többféle ok húzódhat. Kiberbiztonsági szakértővel vettük sorra a lehetséges forgatókönyveket.

Amikor tényleg támadnak

A vakcinaregisztrációval való összehasonlítás elég rossz, mert az egy ékegyszerű oldal százmilliókból, ez meg egy komplett választási rendszer önkéntesekkel. Ott a leállást tényleg a sima terhelés okozhatta, az előválasztási online felületet meg külföldi IP-k rohamozták meg egy Cloudflare-en kívüli útról. Igazi szavazó pedig a Cloudflare-en keresztül jöhetett csak

? mondta lapunknak Danka Miklós András, a Momentum technológiai igazgatója. Az előválasztás esetében az alulméretezés, a megfelelő források szűkössége, és mint kiderült, egy szándékos támadás nehezítette a problémamentes működést.

Farkas Norbert / 24.hu Pfizer vakcinára sorban állók a kórház előtt miután a kormány bejelentette a nyugati vakcinára regisztrálás lehetőségét 2021. április 30-án.

Frész Ferenc kiberbiztonsági szakértő jelentése szerint az előválasztás során a rendszer a nem tervezett hálózati terhelés miatt nem működött. A vizsgálat során kiderült, hogy támadási minták tapasztalhatók a forgalomban, de ezek egyike sem hálózati túlterhelés, sokkal inkább a kiszolgálók és az alkalmazás sérülékenységeit letapogató próbálkozások voltak. A megnövekedett forgalom, melynek 41 százaléka nem rendeltetésszerű volt, valamint a szerverek internetkapcsolatának alulméretezése és a belső szinkronizáció hiánya okozta a leállást.

A tűzoltás pedig nem egyszerű.

?Ahogy egyre több a felhasználó és a használtság, úgy derülnek ki fokozatosan a szűk keresztmetszetek. Hétfőn ezért volt még pár lassulás: kiderült egy-egy limitáció, amiről nem tudtunk, azokat módosítani kellett a kódban és kezelni. Ez normális része a fejlesztésnek, nem lehet mindent előre tudni még terheléses tesztekkel sem, mert minél több dolgot akarsz előre letesztelni, annál költségesebb. De vasárnap este pont ezért csináltunk élő tesztet, ahol egyszerre az összes sátorkoordinátort rácsatlakoztattuk a rendszerre, szimuláltuk, hogy választók jönnek, és láttuk, hogy minden teljesen oké? ? mesélte nekünk Danka.

?Ma már a felhőszolgáltatóknak köszönhetően világklasszis védelmet lehet kapni tök olcsón az infrastruktúra szintjén. Ha valaki saját szervereken üzemeltet valamit, akkor ő a felelős ugyanazon infrastruktúravédelmi munkáért, amit mondjuk az Amazon Web Services ezer profi szakértője csinál.?

Amikor csak sokan jönnek

Általánosságban elmondható, hogy minden szolgáltatásnak és weboldalnak van egy átlagos forgalma, amire az üzemeltetők méretezik az infrastruktúrát. Az átlagosnál forgalmasabb, előrelátható eseményeket pedig tervezni kell, mondjuk egy Black Friday-t. Ilyenkor azért áll le egy-egy oldal, mert az üzemeltetők alábecsülik a roham pillanatát. Persze készíthetők előzetes felmérések, de könnyen előfordulhat, hogy a becsült ezer felhasználóból tízezer lesz ? magyarázza lapunknak Szöllősi Gábor IT-infrastruktúra szakértő.

Az időszakos forgalomnövekedés mellé, ha úgy van, szükséges a hálózati sávszélességnek vagy a fizikai szervereknek a bővítése is. Ez a beruházás viszont nem feltétlenül éri meg, mert az év 365 napjából 333 napon nincs szükség annyi erőforrásra.

A jobbik eset, ha egy cégen belül sikerül átcsoportosítani erőforrásokat, akár egy hétre, pár napra, de erre nem mindig van lehetőség. A másik mód, hogy vagy bérlik az erőforrásokat (szervereket), vagy eleve felhőben fut a szolgáltatás. Utóbbi azért egyszerű, mert ha jól skálázható a weboldal vagy a webshop, akkor tíz helyett már száz szerveren bonyolítható le mondjuk egy Black Friday. A felhőben csak arra a pár napra kell kifizetni a költséget, ami elenyésző ahhoz képest, mintha fizikai beszerzésből kellene ugyanezt megvalósítani. Szöllősi szerint többek közt ezért is jó és rugalmas egy felhőtechnológia, mert gyorsan lehet reagálni a plusz terhelésekre.

?A leállás általában bevételkiesést jelent, mert nem tudnak vásárolni az emberek ? ez pedig sokszor nagyobb, mintha előre felkészültek volna az üzemeltetők. Az infrastruktúrától kezdve az alkalmazásig minden szinten fel kell készülni a terhelésre. Hogy legyen elég hálózati erőforrás, sávszélesség, kellő mennyiségű processzor és memória, továbbá a használt alkalmazások, a programozási oldal is rendben legyen. Bármelyik rétegen bármi elfogy vagy hibázik, borulhat az egész? ? mondja a szakértő.

Minden rendszernél van egy letörési pont, vagyis eléri azt a terhelést, amikor már nem tud kiszolgálni semmit, csak jönnek be a kérések. Addig is a monitorozás mindig kulcskérdés: fontos, hogy az üzemeltetők folyamatosan tisztában legyenek az erőforrásokkal, riasztásokat állítsanak be a monitorozó rendszerbe.

A beavatkozás jó kérdés: sok rosszat is lehet tenni. Ha elkezd lassulni egy oldal, sokan szokták újraindítani az alkalmazásokat és szervereket. Az a baj, hogy ez után a rendszer a sok kérést egyszerre akarja kiszolgálni, amivel még rosszabb lesz a helyzet. Mindig a rendszer ismeretében lehet beavatkozni egy lassuláskor, tudnunk kell, mely komponenst érdemes piszkálni, mivel okozunk kevesebb kárt. Nyilván az a legjobb, ha vannak kész tervek egy ilyen esetre

? magyarázza Szöllősi.

A kulcsszó: tesztelés

A szakértő szerint innen jutunk el a tesztelés fontosságáig, amelynek elvégzését külső felekre kell bízni. Egy teszt során lefuttatható például egy tízezer felhasználós forgalom, megnézhető, hogyan viselkedne ekkora terhelésnél egy weboldal. Azonban sokan ezt a lépést elmulasztják: Szöllősi szerint a vakcinaregisztrációs oldalt például nem tesztelték le kellő alapossággal.

A terheléses tesztnél csak gépi tesztelés jöhet szóba a több ezer felhasználó szimulálásához, mégis figyelni kell arra, hogy ne legyen teljesen szintetikus a folyamat, mivel az nem tükrözi a felhasználók valós viselkedését. Miután az emberek megnyitnak egy főoldalt, elkezdenek böngészni, keresni, a valós terhelés az életben másként működik. Szöllősi szerint egy webshop esetében is bele kell rakni az energiát a teljeskörű tesztelésbe, az általános vásárlói viselkedést kéne átlagolni.

Nem biztos, hogy az a teszt, amit összeraknak, tükrözi a valós forgalmat. így lehet az, hogy valamilyen szinten végig van tesztelve egy alkalmazás, de amikor a valós forgalom bejön, akkor nem ilyen működési mintán teszteltek. Ez az erőforrásokban eltérést okoz, és teljesen más terhelési görbéket alakít ki a rendszerben. Olyan helyeken lesz túlterhelés az éles üzemben, ami a teszteléskor nem jött ki. Nem véletlen, hogy a tesztelés is egy külön ágazat az informatikában, mert rendkívüli szaktudás kell a módszerek tökéletesítéséhez, hogy a valóságot megközelíthessük.

Hogy valós forgalom vagy szándékos túlterheléses támadás bénított meg egy oldalt, még a szakértőknek is nehéz rögtön megállapítani ? főleg nemzetközi oldal esetében, amit a világ minden tájáról felkereshetnek. Ám egy olyan felületen, ami mondjuk magyar közügyeket érint (előválasztás, vakcinaregisztráció), a túltengő amerikai, kínai, orosz forgalom indokolatlan és gyanús lehet. A forgalom forrását tekintve már lehet használni különféle hálózati szűrőket, akár országokra bontva, meg lehet tiltani azt is, hogy országon kívül elérhető legyen egy oldal. Gyanús lehet, ha a forgalom nagy része robotjellegű kéréssel bombázza a szolgáltatást, ami szintén szűrhető tűzfallal vagy valamilyen hálózatvédelmi eszközzel ? magyarázza Szöllősi.

Léteznek olyan szolgáltatók is, akik kifejezetten túlterheléses támadás elleni védelmet nyújtanak, a legismertebb a Cloudflare (ezt használták az előválasztási online rendszernél is). A szolgáltatás lényege, hogy egy weboldal (mondjuk valamilyen webshop) doménjére érkező kérések először a Cloudflare-re mennek, az ő szervereiken landolnak, így mindenféle ellenőrzést el tudnak rajtuk végezni. Többek közt azt, hogy a kérés milyen böngészőből, honnan érkezik, robot-e vagy valós forgalom. Amennyiben utóbbi, csak akkor továbbítják a kérést, tehát egyfajta tűzfalként védik ki a robotokat, amivel nagyobb eséllyel megakadályozhatók a túlterheléses támadások.

Marjai János / 24.hu

A túlterheléses támadások másik formája, amikor a támadók olyan volumenben generálnak forgalmat, ami már a hálózati erőforrásokat tömi be, mondjuk elfogyasztja a sávszélességet. Nem szükséges, hogy a megtámadott szerver erőforrásai elfogyjanak, előfordul, hogy csupán akkora forgalom jön a botnetekkel, hogy a támadó forgalmán túl a valós már nem jut be. Szöllősi szerint ez arra hasonlít, mint amikor van egy vízcső, amin csordogál valamennyi víz, ám a támadó odamegy egy magasnyomású rendszerrel, amit bedug a csőbe, és onnantól kezdve nyert. A botnetek által indított akár több száz gigabitnyi forgalom ellen tényleg csak hálózati eszközökkel lehet védekezni, az ügyfél szerverszinten nem sokat tud csinálni vele ? mondja a szakértő.

Hozzáteszi, a feketepiacon már szinte szolgáltatásként, készen bérelhető egy túlterheléses támadás kivitelezéséhez szükséges rendszer. A megrendelőnek elég akár egy sima kattintgatós, felhasználóbarát felületen beírni a támadni kívánt címet, nem kell semmilyen technikai dologgal foglalkoznia, ha kifizeti érte a pénzt. Bizonyos esetekben nagyon nehéz utólag rekonstruálni, hogy a támadást kivitelező szerverek mögött valójában kik álltak, főleg mert az anonimitást megkönnyítik a különféle offshore bankkártyák, számlák.

Dömös Zsuzsanna további cikkei Nem követemSzerzőim Egy alkalmazás miatt merülhetnek le gyorsabban az iPhone-okMinden oltásellenes videót tiltani fog a YouTubeVideón, ahogy kalapáccsal mennek neki egy iPhone 13 Prónak

The post Ha összeomlik egy rendszer, nem feltétlenül érte túlterheléses támadás first appeared on 24.hu.