Mostanában egyre több szó esik a különböző szolgáltatások ellen elkövetett túlterheléses támadásokról, melyeknek egyik célja az adott szolgáltatás megbénítása. Ezt szaknyelven DoS támadásnak nevezzük. Amikor a támadás nem egyetlen számítógépről érkezik, hanem többről, akkor a támadott rendszer ráadásul túlerővel szembesül, és szinte biztosra vehető, hogy térdre kényszerül.
Ez a támadás továbbfejlesztett változata, a DDoS támadás.
Hogy tisztába tegyük, a fogalmakat, a cikk első része mindenkihez szól. Hogy hogyan védekezzünk ellene, az főleg azoknak, akik publikus szolgáltatásokat tartanak fenn.
DoS és DDoS – mi is ez pontosan
Anno, a proxyról szóló cikkben írtam az IP címekről és a kommunikációs portokról, így ezeknek az ismertetésén most átugornék. A lényeg az, hogy azok a szolgáltatások, amelyeket az interneten keresztül igénybe veszünk, egy vagy több meghatározott IP cím egy vagy több portján érhetőek el. A digitális kommunikáció pontosan ugyanúgy zajlik, mint a verbális módszer:
Az egyik gép kérdez, a másik válaszol.
Példának nézzük az egyik legegyszerűbbet, a böngészőt. Mi beírjuk a webcímet, amit látni akarunk. A böngészőnk ebből a hivatkozásból generál egy IP címet, egy meghatározott TCP portot, és egy parancsot, amit az adott IP adott portján keresztül elküld. Ezt hívjuk kérésnek. A kiszolgáló, amely az adott kérést megkapja, a parancs alapján legenerál egy HTML oldalt, és az egészet visszaküldi, a böngészőnknek, amely aztán azt megjeleníti – ez a válasz.
Azért nem ilyen puritán a dolog, mert ha az adott oldal kódja hivatkozik megjelenítendő képekre, stíluslapokra, vagy külső java scriptekre, akkor a böngészőnk azokat is egy-egy kérés formájában elkéri a kiszolgálótól, és miután mindent megkapott, akkor rakja össze a megjelenítendő oldalt.
Azaz, a kérdés-válasz kombinációk száma elég sok lehet akkor is, ha csak egyetlen oldalt kérünk le.
Amikor egy linkre kattintunk, többnyire ugyanaz történik, mintha a linket begépelnénk a böngészőnk címsorába, és ütnénk egy entert.
A HTTP kommunikáció nagy vonalakban így működik.
Gondolhatjuk, hogy egy nagy forgalmú oldal milyen sok kérést kap, amelyekre válaszolnia kell. Főleg, ha az adott oldal valami plusz funkciót is ellát, mint pl. a Google keresője, ilyen esetekben elképzelhetetlen, hogy egyetlen kiszolgáló lássa el a feladatot. Ilyenkor valamilyen módon sok kiszolgáló egy logika szerint munkafolyamat alapján megosztva végzi a feladatot (az egyik pl. HTML kódot generál, a másik keres, a harmadik gyorsítótáraz, stb.), sőt, feladatcsoportonként lehet több kiszolgáló is, amelyek fürtözve vannak, hogy az egyik kérést az egyik, a másikat a másik hajtsa végre - evvel is csökkentve a terhelést, és javítva a szolgáltatás minőségét.
Ám ez soha nem elég. A felhasználói élmény fokozása mindig erőforrástöbbletet igényel, és egyes kérések sokkal több erőforrást igényelnek, mint mások.
Arról nem is beszélve, hogy a kiszolgálói rétegben lévő alkalmazásoknak is vannak gyenge pontjaik. A HTML kódot generáló Java, PHP vagy Perl scriptnyelveknek is vannak ismert hibái, és a kódot a böngésző felé közvetítő Apache, Nginx, Lighttpd vagy más kiszolgálóprogramoknak úgyszintén, és lehet, hogy a támadó olyan kérést küld, ami az adott kiszolgálói rétegben okoz olyan hibát, ami miatt egy adott kéréssel túl nagy terhelést lehet okozni a kiszolgáló memóriájában, processzorán vagy a háttértáron.
Ha az ilyen kérések száma túl magas, vagy egyszerre több helyről érkezik több hibás kérés, akkor hiába van az infrastruktúránk jól szervezve és erőforrásmegosztás szerint átgondolva - el fog esni.
Vagy megáll a szolgáltatás, és újra kell indítanunk, hogy ismét használni lehessen, vagy – és ez a rosszabb eset – a szolgáltatás elveszíti az adott TCP port kommunikációja felett a kontrollt, és a támadónak lehetősége nyílik arra, hogy a sérülést kihasználva bejusson a gépre, ott kódot futtasson, és evvel a hatalmába kerítse azt.
A nagyobb veszély ez.
Ugyanis, ha nem vesszük észre, hogy a kiszolgálónkat a hatalmukba kerítették, akkor a kiszolgálót felhasználhatják olyan célra, hogy feltörjenek ugyanígy más gépeket is – azaz a zombi hálózat tagjává válik a kiszolgálónk anélkül, hogy tudnánk.
Hogyan vehetjük észre?
Ha nem nézegetjük a gépünket, csak magára hagyjuk, akkor sehogy.
A DoS ugyanis lefülelhető, és mivel a DDoS támadás az sok kiszolgáló egy adott időben egyszerre történő DoS támadása, így a DDoS is lefülelhető.
A leggyorsabb módja a felismerésnek az, ha a kiszolgálónkat monitorozzuk – azaz valamilyen szoftver segítségével figyeljük. Utánanézünk a gyanús memóriahasználatnak, a túl magas CPU igénybevételeknek. Ezeket a legtöbb szolgáltatás esetében a rendszernaplók figyelésével és nézegetésével tudjuk megtenni.
Hogy a HTTP-nél maradjunk, vannak nagyon jól ismert hibák és technikák, amelyek vagy a kiszolgálói réteg gyengeségeit, vagy a telepítést végző szakember lustaságát, hanyagságát próbálják kihasználni.
Azt hihetnénk, hogy ezek az ócska trükkök manapság már nem számítanak. Épp ellenkezőleg. Egy komoly törési kísérlet összehangolt támadást, és emberi felügyeletet igényel, ezért nagyon ritka. Az esetek több, mint 90%-ában a próbálkozások banális módon történnek, és jutnak eredményre, mivel a folyamatot szoftver végzi, nem ember, így magára lehet hagyni, el lehet addig menni bulizni, mire kijózanodik a támadó, már van 100-200 kiszolgálóból álló zombihálózata, és tervezheti a nagyobb dobást, mert megfelelő erőforrásmennyiség van a kezében.
Ezeknek a próbálkozásoknak azonban a rendszernaplókban mindig nyoma marad, és ha odafigyelünk, akkor tudunk tenni ellenlépéseket.
Hogy továbbra is a HTTP kiszolgálói példánál maradjunk, a rendszernaplókban mindig nyoma van az olyan kéréseknek, amelyek az adott oldalon nem találhatóak – pl. a naplóban azt látjuk, hogy a 1.1.1.1 IP címről a kérés az adott kiszolgálótól a /admin/login.php oldalt kérte el, de mivel az nem található, a kiszolgáló a 404-es, azaz a nincs ilyen oldal választ adta. Véletlenek mindig vannak, nem kell azonnal gyanút fogni - ám, ha az adott címről rövid időn belül több ilyen hibás kérés is érkezik, biztosak lehetünk abban, hogy támadják az oldalunkat. Ha pedig több, különböző címről is hasonló próbálkozásokat látunk, akkor DDoS támadás van folyamatban.
Ilyenkor az a legcélszerűbb lépés, hogy az adott IP címektől nem fogadunk el többet kérést, kizárjuk őket a kommunikációból, pl. a kiszolgálónk tűzfalának egy egyszerű beállításával. De nem ülhetünk mindig a gépünk előtt, nem vehetjük észre azonnal ezeket, pedig erre azonnal kellene reagálni.
Mit tehetünk?
Van egy roppant egyszerű alkalmazás, amit fail2ban néven lehet elérni. Tulajdonképpen azt csinálja, amit az előzőekben leírtam, csak magától teszi, nem kell ott ülnünk a gép mellett.
A szolgáltatás figyeli azokat a naplófájlokat, amelyeket a beállításaiban megadunk, és ezekhez több, különböző szűrőt és feltételt rendelhetünk.
Máshogy reagálhatunk pl. arra, ha egy külső felhasználó rendszeresen elrontja a jelszót, vagy olyan néven próbál belépni, amilyen néven nincs is felhasználó a rendszerben, vagy - hogy a fenti példán haladjunk tovább - olyan weboldalt akar lekérni a kiszolgálóról, ami nem létezik. Beépített szűrőket és akciókészleteket eleve kapunk a szoftverrel, így a legáltalánosabb támadások ellen azonnal védekezhetünk, de a legjobb, ha testre szabjuk a beállításokat. Egy szabály leggyakrabban az alábbi összetevőkből épül fel:
- A szabály neve
Ez lesz a tűzfalszabály csoportneve is. - A szolgáltatás portja
Ezt egyszerűsíthetjük is, pl. http - A figyelt sorok időintervalluma
Azaz mekkora időintervallumban kell értelmezni a hibákat pl. 1 óra - A megengedett hibák száma
Azaz az adott időintervallumban hány hibát fogadunk el pl. 3 - A hibákat számláló szűrő
Egy külön konfigurációs fájl, ami az adott naplósorról eldönti, hogy hibás-e, vagy sem - A tiltást végző akció
Külön konfigurációs fájl, ami a tiltás esetén végrehajtja az adott IP címmel kapcsolatos szankciókat - A tiltás időtartama
Mennyi ideig legyen életben a tiltás. Ha ez letelik, a tiltás feloldódik. pl. 1 nap
A fail2ban alkalmas a HTTP kiszolgálók védelmén felül többek között ellátni az FTP, SSH, SMTP, POP3, IMAP, DNS valamint más szolgáltatások figyelését és a támadások szankcionálását. Ha az alapbeállításokat követően napi/heti néhány alkalommal ránézünk az alkalmazásra és finomítgatjuk a beállításokat, elég jól testre szabhatjuk a rendszereink védelmét, nagyban hozzájárulva nem csak ahhoz, hogy a támadók esélyei leszűkülnek, hanem annak is, hogy más rendszerek is védve maradnak, mert a mi kiszolgálónk kisebb eséllyel lesz tagja egy támadó hálózatnak.
Mindezt persze ingyen, hiszen a fail2ban is egy nyílt forráskódú, Python programnyelven készült alkalmazás, amely a legtöbb Linux disztribúció alapszoftverkészletének részét képezi.
