Az információbiztonság területén az egyik legmeghatározóbb élményem néhány évvel ezelőtt történt, amikor IT fejlesztési projektvezetőként, az egyik, akkor már átadott és élesített rendszerünk elérhetetlensége miatt csörgött a telefonom, egy napsütéses szombat reggelen. Mivel az üzemeltetést nem mi végeztük, ezért – amikor a főnököm tájékoztatott arról, hogy azonnal lássak munkához a probléma megoldása érdekében – első lépésként csak annyit láttam a telefonomon, hogy valóban elérhetetlen az oldal. Elsőre persze DDoS-ra gondoltam. Amíg a kapcsolatot felvettem az üzemeltetést végző kollégákkal sikerült információt szereznem az aktuális látogatók analitikájáról, mert jó lakmuszpapírnak gondoltam. Valóban, egyszerre több tízezer felhasználó látogatta, az addig általában csak napi néhány száz érdeklődőt fogadó weboldalt. Csakhogy a felhasználók nem külföldről érkeztek: valójában az összes magyar hírportálról, egyszerre özönlöttek a látogatók.
Nagyjából ez az a pont, ahol billentyűzetet ragad az egyszeri újságíró, amatőr, inkompetens informatikát, emberi mulasztásokat és hibákat sejtve az ilyen jelenség mögé. Ebben – adott esetben – lehet részigazság, a valódi helyzet azonban általában ennél jóval összetettebb, erről szeretnék most írni egy kicsit bővebben. Teszem ezt persze úgy, hogy a konkrét esetről nem is szeretnék ennél többet írni, pusztán felvezetőnek szántam, és a továbbiakban leírt gondolatok már nem ehhez az esethez köthető véleményemet tükrözik.
Az is kérdés persze, hogy vajon az esetek hány százalékában derül ki az igazság, hogy egy weboldal organikus DDoS támadás áldozatává vált? Az organikus DDoS egyébként – leegyszerűsítve – úgy alakul ki, ha egy webalkalmazás, weboldal iránt valamilyen oknál fogva megnövekedik az érdeklődés, ám ezt a megnövekedett érdeklődést a szerver a véges erőforrásai, vagy a lefejlesztett webalkalmazás a felépítésénél fogva lassan vagy egyáltalán nem szolgálja ki. A „hagyományos” DDoS támadás lényegében ugyanezt a jelenséget mesterségesen hozza létre, automatizált eszközökkel, nem pedig a weboldal iránt érdeklődő, valódi emberekkel. De visszatérve a kérdésemhez: a következő bejegyzésemben egy olyan esetet mutatok majd be, melynek nyomán megvizsgálható lesz, hogy mi a következménye annak, ha egy incidenst nem jelez a felhasználói felé egy nagyvállalat, összevetve egy másikkal, amelyik ezt – igaz a média kényszerétől – megtette.
A definíciómból következik, hogy az organikus DDoS nem kívánt jelensége egy olyan állapot, amit a szükséges erőforrások előzetes biztosításával – általában – valóban meg lehetett volna előzni. Ide összpontosulnak a leggyakoribb, külső kritikák is: például, miért nem volt felkészült az üzemeltető a nagyobb forgalomra? Ennek több oka is lehet. A saját példámhoz visszatérve: a fejlesztés során, előzetesen definiált konkurens felhasználói szám emlékeim szerint százas nagyságrendű volt, ami így is sokszorosa volt – sokéves vetületben is – a korábbi csúcsoknak. Kellett volna nagyobb, több tízezres forgalomra számítani?
Az üzemeltetésnek ugyanis költségvonzata is van. Vajon jó megoldás-e évekig a szükséges erőforrások sokszorosát allokálni a rendszerünkhöz, és fenntartani, csak azért, hogy ha egyetlen alkalommal megnő az érdeklődés, akkor azt azonnal, üzembiztosan kiszolgálja? A válasz attól (is) függ persze, hogy milyen kritikus rendszerről van szó. Ha piaci szereplők vagyunk és a jelenség elkerülése valamiért minden pénzt megér, megtehetjük, de általában aligha ez az üzletileg racionális döntés. Megint más kérdés, ha állami megrendelőről beszélünk. Akkor a véleményem szerint igencsak meg kellene indokolni, hogy valaki miért szeretne szászas nagyságrend helyett tízezres látogatószámra erőforrást igényelni az állami infokommunikációs szolgáltatótól.
A jelenség piaci környezetben felhőszolgáltató igénybevételével persze jól kezelhető, de bizonyos rendszerek esetében nem opció az adatok külföldre továbbítása, a technológiai megvalósítás pedig számos adatvédelmi kérdést feszeget. Állami szegmensben a piaci felhő igénybevétele általában eleve kizárt, illetve mindkét esetben kérdés az is, hogy van-e egyébként nem pusztán az IT erőforrások végességéből, hanem például a fejlesztésből, implementált technológiából származó akadálya a beérkező látogatók egyidejű kiszolgálásának (és továbbgondolva: ha vannak biztonsági, logelemző rendszerek, akkor annak a kapacitásait is figyelembe véve). Ha az információbiztonságot nézem, akkor a felhő feletti kontroll problémakörét is érdemes lenne vizsgálni.
De azt sem gondolom mindezzel együtt, hogy hátradőlve kell állni a jelenség előtt, és megvárni, amíg az érdeklődés „organikusan” lecsökken, ha másért nem, akkor azért, mert az oldal eleve elérhetetlen. Viszont a megoldás korántsem biztos, hogy az, hogy a megrendelő írjon elő átvételi kritériumként 10 millió egyidejű felhasználó kezelésére vonatkozó sikeres performancia tesztet, majd ezt a környezetet fizesse meg éveken keresztül, akkor is, ha egyébként a látogatóinak a száma valójában a százat sem közelíti, naponta. Természetesen léteznek olyan rendszerek, ahol az extrém magas szintű rendelkezésre állás elvárás, de a médiában – szerencsére – általában olyan esetek kerülnek reflektorfénybe, melyeknél egy kiesés okozhat ugyan kellemetlenséget, járhat politikai kockázatokkal, de nem emberéleteket veszélyeztet.
De mi akkor a megoldás szerintem?
1. A probléma kezelésének ne legyenek fejlesztésből eredő korlátai
Ha beüt az organikus DDoS, akkor a megoldást ne hátráltassa az, hogy a rendszer fejlesztési okból adódóan nem képes a látogatókat megfelelően kiszolgálni. Vagyis ne kelljen a fejlesztőt előrángatni, a rendszert módosítani, tesztelni, újratelepíteni egy ilyen probléma felmerülése esetén. Itt is törekedve természetesen az ésszerű elvárások megfogalmazására. Másik oldalról, már rendszer tervezésekor születhet erről üzleti jellegű döntés, ha a fejlesztési költség emiatt jelentősen megnőne. Valójában, ésszerű korlátok között – már a tervezéskor odafigyelve – az esetek jelentős részében ez nem költségnövelő tényező, ellenben a problémaként való megjelenése jelentősen hátráltathatja a helyzet megoldását.
2. Legyen terv
A megrendelő DRP és BCP tervei terjedjenek ki arra az esetre is, amikor organikus DDoS esete merül fel. Márcsak azért is, mert a „hagyományos” DDoS támadással szemben eshetőlegesen alkalmazható megoldások némelyike (forrásoldali országok, régiók letiltása) ebben az esetben nem lesz alkalmazható. Adott esetben ne csak nekünk, a megrendelőnek, hanem az üzemeltetésnek is legyen terve ilyen esetekre, ha az üzemeltetés tőlünk független.
3. Legyen kapcsolat az üzemeltetéssel
Ha bekövetkezik az elkerülni kívánt helyzet, akkor legyen élő kapcsolatunk az üzemeltetéssel (szükség esetén távközlési szolgáltatóval), még jobb esetben velük együtt az eredeti fejlesztőgárdával is (pl. valamilyen rendszertámogatási szerződés keretei között), és mindig tudjuk, hogy egy adott probléma kapcsán kit vagy kiket kell, illetve lehet felhívni.
4. Ha van terv és kielégítő kapcsolat, akkor teszteljük is azokat
Nem elég a megfelelőnek tűnő szabályokat kialakítani és a partnerekkel szorosan együttműködve kapcsolatot tartani: ténylegesen, szimulációs körülmények között le is kell tesztelni azokat. Hogy ez milyen mélységű és milyen gyakoriságú, azt a rendszer jellegéből, a rendelkezésre állásának fontosságából kell meghatározni. A partnerek esetében természetesen külső auditot is kezdeményezhetünk, de ennek eredményessége és a szolgáltató oldali nyitottság az változatos.
5. Amennyire lehetséges, legyen skálázható a megoldásunk üzemeltetési környezete
Nyilván triviális (sokak szerint a legfontosabb), hogy az IT rendszer bizonyos keretek között, újabb erőforrások felhasználásával megtámogatható legyen arra az időszakra, amíg a fokozott érdeklődés fennáll. Ennek azonban rengeteg akadálya lehet, aminek ugyanúgy alapja lehet egy eleve rosszul megtervezett rendszer, de lehetnek rugalmatlan normatív előírások, szabályzatok, mint ahogy az üzemeltető véges kapacitása is.
6. A tartalomgazda szerepe és az organikus DDoS pszichológiája
Az organikus DDoS fogalmából kiindulva látható, hogy a probléma azért következik be, mert az érdeklődés hirtelen, jelentős mértékben megugrik egy adott webalkalmazás, valójában pedig általában annak egy konkrét funkciója, tartalma tekintetében. Ebből az is következik, hogy az organikus DDoS-t előidéző érdeklődést – általában – a megrendelői, tartalomgazdai oldal előre látja, láthatja, vagy látnia kellett volna.
Amennyiben ez így van, és még ha a fenti pontok teljesülnek is, akkor is: a megrendelőnek, tartalomgazdának minden esetben fel kellene mérnie, hogy egy adott digitális adattartalom, amit hozzáférhetővé tesz vagy tett, valamilyen okból esetleg nagyobb érdeklődésre tart számot, mint a korábbiak. Ilyen esetekben előzetesen értesíteni kellene az üzemeltetést (kétség esetén konzultálni a fejlesztővel), különben az nem tud felkészülni a megszokottól eltérő erőforrásigényre, és még akkor is késedelmet szenvedhet a beavatkozás, ha a rendszerek erőforrásai a szükséges mértékben skálázhatóak.
Egy konkrét, de teljesen fiktív példával élve, egy tömegszerencsétlenséget jelentő légiközlekedési katasztrófa történt, melynek kivizsgálása hónapokig elhúzótott. A légiközlekedési balesetek kivizsgálásáért felelő szervezet – melynek weboldalát napi néhány száz felhasználóra tervezték – végül lezárta a baleset kivizsgálását és publikálni akarja az ezzel kapcsolatos jelentését. A média nyilvánvalóan minden releváns cikkben linkelni fogja a jelentést, ami az organikus DDoS-hoz vezethet.
A hatóság nem okozhatna nagyobb problémát, mintsem, hogy a jelentést publikáló cikkét péntek délután négykor szombat reggel 8 órára időzíti a rendszerben, egyidejű MTI híradás aktiválásával úgy, hogy nem vesz tudomást a webalkalmazásának ismert korlátairól, az eredeti specifikációs követelményekről és nem egyeztet sem az üzemeltetővel, sem a fejlesztővel, egyszerűen azért, mert nem is gondol arra, hogy ez milyen problémákat okozhat.
Az eset fiktív, a probléma nem, úgyhogy ezt szerettem volna egy kicsit más szemszögből megvilágítani. Hátha gondol majd rá egyszer valaki.
