Egy DDoS elleni védekezés ismertetése

Egy konkrét támadás, illetve védekezés ismertetése segíthet jobban megérteni a DDoS támadások és a védekezés folyamatait. Ebben a bejegyzésben az egyik 2023. szeptemberi támadás esetét ismertetem. A leírásból utólag sok részt kellett kitörölnöm, hiszen nem mélyedhetek el a részletekben. Nem weboldalak üzemeltetőit szeretném nehezebb helyzetbe hozni azzal, hogy potenciálisan támadási lehetőségeket sorolok fel. Azért remélem, hogy így is olvasmányos lesz az írásom.

Egy kevéssé derűs hétvégi napon kissé kalandos úton került a kezeim közé egy WordPress alapú weboldal, melyet alaposan megviseltek a megelőző időszak támadásai, és azok szakszerűtlen kezelésének a következményei. A lap akkor már sok napja elérhetetlen volt, így a mielőbbi elérhetővé tétel volt a legsürgetőbb feladat. Emiatt kimaradt egy, a sikeres védekezés alapját jelentő lépés, a weblap gyenge pontjainak azonosítása és védelme. Mentségemre legyen mondva, hogy egy romokban lévő, sérült adatbázissal átadott lapból kellett mielőbb újra működőt alkotnom. A lapot alig valamivel az élesítése után már támadás érte. Lássuk, hogyan is zajlott a támadás és a védekezés!

Az első hullám

1. A weboldal beüzemelése után röviddel, körülbelül 1 óra múlva megérkeztek az első, már támadásként azonosítható kérések. A támadó elsőként az adminisztrátori felület bejelentkezési oldalát vették célba.
2. A másodpercenként 600-800 bejelentkezési kérés célja nem a jelszavak brute-force „kitalálása” volt, hiszen erős jelszavak esetén erre nincs esély. Sokkal fontosabb tényező, hogy az adatbázisokban a jelszavak általában titkosított formában vannak tárolva, így minden bejelentkezési próbálkozáskor a szervernek elő kell állítania az ún. jelszó hasht, hogy ezt összehasonlíthassa a tárolt változattal. A titkosítási algoritmusok pedig elég számításigényesek, és a támadók számára ez sokszor könnyű prédává teszi a weboldalakat.
3. Az első támadási kísérlet fennakadt egy korlátozáson, mely a bejelentkezési kísérleteket kérés/másodperc alapon limitálja. Azaz egy adott időintervallumon belül a webszerver csak adott kérést fogad el tényleges feldolgozásra, ha több kérés érkezik, azokat egyszerűen eldobja. A webszerverről emiatt néhány százalékos terheltség mellett pattant le az első próbálkozás.
4. A CDN szolgálató automatikus DDoS védelme még nem aktiválódott, mert a kérések száma az első körben nem érte el a kritikusnak minősített szintet. A védelmet kézzel sem aktiváltam, mert a terhelés ezt nem tette indokolttá.
5. Ha nem lett volna CDN/DDoS védelmi szolgáltatás a lap előtt, akkor az egy-egy IP címről érkező, túl sok sikertelen bejelentkezési kérésre reagálhattam volna automatikusan életbe lépő tűzfalszabályokkal is. Ezzel a szerver terheltségét tovább csökkenthettem volna, de erre az adott esetben nem volt szükség. Persze további lehetőségként az adminisztrátori felületek elérhetőségének egyéb korlátozása is lehetséges lett volna, hiszen ennek egyáltalán nem szükséges a teljes Internet felé elérhetőnek lenni.

A második hullám

1. A sikertelen első próbálkozás után 10-15 perccel a támadó a WordPress motor második, igencsak gyenge pontját vette célba. Másodpercenként több száz, véletlenszerű kereséssel bombázta a lapot. Ez okozott egy kis fejtörést, mert a weblapon több 10 ezer bejegyzés volt, amely a WP alap keresőjével párosítva rettenetesen rossz eredményt ad. Fel nem foghatom, hogy 2023-ban hogyan lehet ilyen gyenge programkód egy nyílt forráskódú blog-motorban. A szerver terhelése gyorsan és jelentős mértékűre emelkedett.
2. Az irányítást nem terveztem elveszíteni, így a helyzet megoldása érdekében rövid időre minden kérést blokkoltam, hogy a problémás minták szűrésére létrehozhassam a megfelelő szabályokat. 1-2 perc múlva a lap újra élt, csak a keresőjét tettem elérhetetlenné. A kereső működésének kiiktatása koránt sem akkora veszteség, mintha a teljes lap elérhetetlenné válna.
3. A támadás második hullámának maradéka ezután már fennakadt a CDN szolgáltató szűrési szabályain. A terhelés a támadás ellenére is normalizálódott, a weblap ismét megfelelően működött.
4. A weblap funkcionalitását természetesen nem akartam véglegesen korlátozni, így a WordPress motorhoz írtam egy kis kiegészítőt, amely a problémás funkciókat a szerver terheltségének megfelelően, automatikusan képes ki- és visszakapcsolni. Ilyen esetekben kapóra jön, ha a rendszer üzemeltetője rendelkezik fejlesztői tapasztalattal. A weblap ezután újra teljes funkcionalitásával elérhetővé vált, és már az eredetileg problémás funkcióin keresztül nem volt túlterhelhető. Ismét előrébb léptünk a stabilitás felé.

A harmadik hullám

1. A támadó növelte a keresési kérések számát, amely így már aktiválta a CDN szolgáltató automatikus DDoS védelmét is. Ezzel 10-15 perc nyugalom lett, majd jött a harmadik hullám egyik legmeglepőbb fordulata.
2. A CDN szolgáltató interaktív védelmén lassan-lassan elkezdtek átszivárogni a kérések, tehát a támadó forgalom egy része, körülbelül 10% átjutott a CDN szolgáltató védelmein. Ez egyáltalán nem megszokott. Azt kell mondjam, hogy ezzel meg is lepett a támadó. A saját védelem viszont aktiválódott, és a szerver kb. 20% terheltség mellett képes volt kezelni és részben blokkolni másodpercenként valamivel több, mint 4000 beérkező kérést.
3. A memória és diszk cache következtében a szerver válaszideje is az ideálisnak tekinthető érték közelében maradt. A támadónak esélyesen feltűnt, hogy a weblap elérhető, és még csak nem is lassult le igazából, így ismét módszert váltott. Hozzá kell tegyem, hogy az ilyesfajta, a változó körülményekre néhány perc alatt reagáló támadás egyáltalán nem megszokott.
4. A támadó a kéréseket úgy „fűszerezte meg”, hogy a webszerver addig kiválóan működő cache funkcionalitását ezzel sikerült kiiktatnia. Erre válaszul átkonfiguráltam a webszervert, hogy a fentiek hatását kiküszöböljem. A cache újra hatékonyan működött, a terhelés ismét normalizálódott, majd a támadás kb. egy óra múlva abba is maradt.

A negyedik hullám

1. Néhány óra után a támadó rendezte sorait, majd a kérésekben olyan metódusra váltott, amellyel a cache funkciót ismét kiütötte, azaz a WordPress motorra terhelte minden egyes kérés kiszolgálását. A WordPress viszont nem egy terhelésálló rendszer, így ismét kezdhettem vakarni a fejem.
2. A gyors elemzés után egyértelművé vált, hogy a támadásban megjelent kérések nem szükségesek egy WordPress oldal alap működéséhez, leginkább csak a felhasználói és az adminisztrátori, interaktív elemek használják azt. Első körben teljesen, majd a terheléstől függően blokkoltam a problémát okozó lehetőséget.
3. A terhelés a több ezer másodpercenkénti kérés ellenére ismét normalizálódott. A szűrőszabályok ki lettek egészítve, hogy a weblap adminisztrátorainak munkáját ezek a továbbiakban már ne korlátozzák.
4. A támadás 1-2 óra után alább hagyott, és ezt követően már csak néhány gyengébb, a weboldal működésére hatástalan, de még említést érdemlő próbálkozás volt. Vélhetően a támadónak nem érte meg még több munkát befektetni olyan megoldásokba, amelyek esélyesen az előzőekhez hasonlóan legfeljebb percekre hoznak számára eredményt.

A támadás befejeződése után elemeztem a támadásról keletkezett logokat, grafikonokat. Az elemzések alapján finomhangoltam a bevezetett szűrőszabályokat és a támadás elleni védekezés programkódjait. Ezekkel a rendszer az előző négy támadási hullámban használt támadási lehetőségekre nagyrészt már automatikusan is képes reagálni. Egy-két olyan gyenge pontra, támadási lehetőségre is fény derült, amelyet még nem próbáltak ki egyik hullámban sem, de a lapot elemezve szemet szúrt a lehetőségük. Természetesen ezekre is ki lett, illetve lesz dolgozva megfelelő megoldás.

Csak hogy számadatok is legyenek a bejegyzésben. A fenti kép a felügyeleti rendszer által a 3. hullámban mutatott, pillanatnyi szerverállapotot mutatja. Az adott pillanatban másodpercenként 4184 kérés jutott át a CDN szolgáltató DDoS védelmén, de a szűréseknek köszönhetően ez csupán 200 SQL lekérdezést váltott ki. A 4. hullámban ez csaknem megduplázódott, egyórás időintervallumban másodpercenként 7150 kérést regisztrált a rendszer. Erről sajnos nem készült képernyőmentésem, mert épp túlzottan lekötött a támadás.

Talán a bejegyzésemből érezhető, hogy a támadás és védekezés leginkább egy rapid sakkjátszmához hasonlít. Persze itt szó sincs kézfogásról sportszerűségről vagy szabályokról, és persze a támadó dönti el, hogy mikor kezdődik vagy éppen szünetel a játék. Ő világossal bármikor nyithat, és már a védekező oldal válaszlépése előtt is újra léphet. Itt vagy gyorsan reagálunk, vagy a vesztett játszma után már csak a tanulságokat vonhatjuk le.

A fenti esetben egy kisebb weblap volt a főszereplő, melyet egyetlen dedikált szerver szolgált ki. Egyre több megoldás védi, de ezek komplexitása meg sem közelíti azt a szintet, amit képesek volnánk létrehozni megfelelő források mellett. Remélem, hogy a támadások következő hulláma előtt már egy olyan rendszerünk lesz, amely sokkal komolyabb incidensek kezelésére is képes, és nem csak egy portált, hanem esetlegesen sok egyéb, társadalmilag hasznos lapot is védhet.