Gyakran hallani, hogy majd a dolgok internete (IoT) hozza el nekünk a digitális transzformáció – lásd még Ipar 4.0, precíziós mezőgazdaság stb. – aranykorát. Az IoT koncepciója nagyon egyszerű: hálózatba kapcsolt, azon forgalmat küldeni képes, olcsó, kis teljesítményű célszámítógépek adatokat gyártanak és továbbítanak egy elemzőközpont felé, amely ezekből finomhangol, döntéseket készít elő, döntéseket hoz, visszacsatol.
Az Internet of Things világa olyan futurisztikus téma, ami a szakmának kézzelfogható valóság (hovatovább konkrét piac), míg a kívülállók számára a Csillagok Háborúja sorozat A klónok támadása részében elénk tárt sci-fi. (Abba most ne menjünk bele, hogy analóg, visszacsatolt automatikák – hogy mást ne említsünk – az autóinkban is vannak már évtizedek óta.)
Az IoT hálózat kockázatai
Mostanában az egyik kedvenc IoT-s példám egy hazai eseményen tartott előadás a következő témában: „A szarvasmarha-tenyésztés optimalizálása a mikrokörnyezetük IoT-eszközökkel történő monitorozás segítségével”. Azért vannak még csodák ég és föld között…
De képzeljük csak el, hogy a rivális gazda (vagy ipari versenytárs) megirigyeli a digitálisan transzformált sikereinket. Tudomására jut, hogy milliós beruházással intelligens hálózatba kapcsoltuk, és illeszkedő IoT-eszközökkel vérteztük fel a termelésünket, és egyéb folyamatainkat is transzformáltuk. A rivális megkérdezi a témában pár barátját, ismerősét, akik hamiskás félmosollyal akár azt is mondhatják neki, hogy szerezzen valakit, aki ért a web sötét bugyraihoz, merthogy ott fillérekért juthat az irigyelt versenytárs tönkretételéhez szükséges eszközhöz és információhoz. Így is tesz, potom 8-10 dollárért olyan szolgáltatás-blokkoló eszközt (DoS vagy DDoS for hire) lehet bérelni, amely 100 másodpercre lebénítja a célhálózatot. Vagy kicsit több pénzért olyat, ami 30 ezer másodpercre, de bedobhatunk az ezzel foglalkozó webshop kosarába olyan kiegészítőt is, ami mindezt havonta, de akár hetente vagy naponta megismétli.
Ha „jó” periódusban támadják a szarvasmarhatelep IoT-hálózatát, akkor az adatkimaradások miatt drasztikusan visszaeshet a tejhozam, vagy ipari példát hozva, megnőhet a selejt, leállhat a gyártósor.
Biztos, hogy biztonságos az IoT hálózat?
Van egy másik vetülete is ennek a területnek: az IoT-eszközök – a fenti példáknál maradva a gázelemző szenzorok, ipari kamerák, esőérzékelők, vagy kicsit szélesebb optikával nézve az önvezető autók, vezérelt szívbillentyűk és társaik is – a legritkább esetben készültek a saját biztonságuk előtérbe helyezésével, sőt a gyártási költségek lefaragása végett, azaz gazdasági megfontolások miatt gyengítheti az eszköz gyártója a végleges gyártmány biztonsági kapacitását.
Képzeljük csak el, ha 512 bites titkosítás helyett csak 128-ast kell számolgatnia üzenetenként a célszámítógépnek: kisebb órajelű, olcsó, passzív hűtésű processzor is elég mindenhova, az pedig, hogy a gyenge titkosítás feltöréséhez szükséges számítási kapacitásnál nagyságrendekkel több van a zsebünkben, már senkit sem érdekel.
Az ilyen hálózatba kötött eszközök feltörésére szabadon hozzáférhető eszközök vannak a neten!
A Mirai sztori
2016-ban az online bűnözéssel foglalkozó Brian Krebs, amerikai oknyomozó újságíró elkezdett egy cikksorozatot egy bérelhető, elosztott szolgáltatás-megtagadásos támadásokkal (DDoS-támadásokkal) foglalkozó rosszfiúról, aki egy addig nem látott, elképzelhetetlenül erős fegyvert fejlesztett az ilyen támadásokhoz. A fegyvernek a Mirai nevet adta.
Krebs módszere a következő volt: teljesen publikusan elérhető, kifejezetten az internetre kötött eszközökre specializálódott keresőmotorral, a Shodannal feltérképezett olyan, gyenge titkosítással és/vagy széles körben ismert jelszóval ellátott eszközöket, melyeket a rabszolgájává tett, azaz a számítási kapacitásaikat a saját céljaira tudta fordítani. A több százezer kis kapacitású eszköz együttesen hatalmas tűzerőt tud zúdítani bármilyen célpontra. Az első Mirai-cikk után a fegyver megalkotója megtámadta Brian Krebs oldalát, és egy addig soha nem tapasztalt méretű, 623Gbps sávszélességű DDoS-támadással pár napra eltüntette őt a netről. (Az újságíró blogját utána befogadta a Google védelmi ernyője, és azóta újra olvasható.)
Bárki válhat céltáblává
Anna-Senpai2, a Mirai fejlesztője ezek után publikussá tette az IoT-eszközök megfertőzéséhez és vezérléséhez szükséges kódot. Csak idő kérdése volt, hogy újra lecsapjon egy mutáns vagy az eredeti fegyver más támadó kezében: 2016 októberében egy, az előzőnél is nagyobb támadás keretében „elgázolták” a Dyn nevű internetszolgáltatót, amely az USA keleti partján többek között az airBnB, a GitHub, a HBO, a PayPal és egyéb népszerű szolgáltatásokat biztosította a hálózatán. Közel fél napig akadoztak, de a teljes visszaálláshoz még hetek kellettek. A következő áldozat egy libériai telekom szolgáltató volt – a kiesés miatt Afrika majdnem teljesen eltűnt az online térképről. (A támadás mögött egy rivális telko szolgáltatót sejtenek.) A következő támadás hozzánk már egész közel, a Deutsche Telekom hálózatában okozott fennakadást: egy, valószínűleg rosszul megírt Mirai mutáció téglává változtatott a becslések szerint 900 ezer eszközt Németországban, főleg útválasztókat, de így nem sikerült rabszolgaigába hajtani őket.
Védekezési stratégiák
Kétféle védekezési stratégiát érdemes megfontolni az ilyen támadásokkal kapcsolatban. Az egyik azt a kockázatot célozza, hogy az üzemeltetett IoT-eszközeinket milyen módszerekkel, eszközökkel érdemes védeni, hogy a támadók ne tudják felhasználni a saját céljaikra. A másik kockázat pedig, hogy mi történik akkor, ha minket ér DDoS-támadás. Az első esetben ugyanúgy érdemes figyelembe vennünk az IoT-eszközöket, mintha alacsony kapacitásuk ellenére, teljes értékű hálózati végpontok lennének. Ugyanúgy (mikro) szegmensekbe kell őket szervezni, és erősen, alkalmazás szinten monitorozni a forgalmukat. A jó képességű újgenerációs tűzfalak, mint például a Palo Alto Networks megoldásai könnyedén meg kell, hogy birkózzanak a szükséges automatizálás, alkalmazásszintű szűrés és a mikroszegmentáció okozta többletterheléssel, az üzemeltetéshez szükséges erőforrások optimalizálásával együtt. A második kockázat ennél talán több mérlegelést igényel: tisztában kell lennünk az általunk mutatott támadási felület méretével, és az esetleg bekövetkező havária helyzet pénzügyi vonatkozásaival, hogy az optimális védelmi beruházás mellett dönthessünk. Nagyon fontos pontosan látnunk, hogy a hagyományosnak mondható határvédelemi megoldásaink nincsenek felkészítve – és nem is feladatuk, hogy fel legyenek készítve – az ilyen típusú támadásokra.
Van megoldás!
Amennyiben az adatvédelmi környezetünk lehetővé teszi, megfontolhatjuk egy felhős DDoS-szolgáltatás igénybevételét, de helyi mitigálásban is gondolkozhatunk. Előbbire az Imperva Incapsula vagy a Radware Cloud DDoS-szolgáltatását tudjuk javasolni, a helyi mitigáló rendszer felépítéséhez pedig Radware DefensePro komponenseket. A megfelelő szolgáltatás és eszköz kiválasztásánál kritikus lehet, hogy milyen hálózati rétegekre kínál megoldást, és mit tud tenni az alattomosan lassan csepegtetett, vagy eleve titkosított csomagokban érkező támadásokkal szemben. A két védelmi vonalat akár egy hibrid rendszerben is alkalmazhatjuk: a nagytömegű, volumetrikus támadásokra egy felhős, csak a támadás észlelésekor közbelépő alacsony költségű Radware szolgáltatást kombinálhatunk egy helyben telepített, saját viselkedéselemző motorral rendelkező, a titkosított forgalmakban érkező, úgynevezett „slow & low” típusú támadásokkal szemben is hatékony, akár a saját névszerver infrastruktúránkat is védő Radware DefensePro eszközzel.
Röviddel a cikk megírása után érkezett a hír: összehangolt rendőrségi akcióban lekapcsolták a világ éppen legnagyobb bérelhető DDoS-oldalának négy üzemeltetőjét Angliában, Horvátországban, Kanadában és Szerbiában, és leállították a Hollandiában és Németországban üzemeltetett infrastruktúrájukat is. Hatmillió támadásban segédkeztek, több mint 136 ezer megbízójuknak. Az összesített támadási idő 15,5 évet is kitesz, az átlagos támadási idő 20 perc, a leghosszabb támadás 10 óra volt. 19-49 euró között lehetett „tagságot” vásárolni az oldalon, ami az előfizetés méretétől függő támadásokat tett lehetővé.
A blogbejegyzés az IT Business 2018. május 14-i cikkének átdolgozott változata