Miről beszélünk, amikor DDoS védelemről beszélünk?

Azok, akik már túl vannak néhány DDoS támadáson, alighanem tudják a választ, de a többieknek is érdemes elgondolkodni a kérdésen: kell-e tartani az efféle incidensektől? A mi álláspontunk, hogy a legjobb, ha az ember ismeri a DDoS támadások természetét, és lehetőségeihez mérten felkészül az ebből adódó károk elkerülésére, a vészhelyzetek gyors és hatékony kezelésére.

A nagy sávszélességű (volumetrikus) támadások ellen lokálisan nem sokat tehetünk, ha kitömik az internetkapcsolatunkat. Sok ISP biztosít azonban DDoS védelmi szolgáltatást, vagy gyártói, cloud alapú védelmet is igénybe vehetünk, hogy kihúzzuk a méregfogát, tehát érdemes eleve többrétegű védelemben gondolkodni.

Bár a volumetrikus támadások jutnak el legkönnyebben az újságok címoldalára, éppilyen veszélyesek lehetnek a kapcsolattáblákat terhelő és alkalmazásszintű támadások is. Ezeket általában megfelelően kezelhetjük saját hatáskörben. Érdemes tudni, hogy gyorsan nő az olyan DDoS támadások aránya, melyekben egyszerre vagy váltogatva többféle támadástípust használnak.

Néhány kérdés és közkeletű félreértés, amikkel gyakran találkozunk:

• A határvédelem több pontján is vannak rate limitek beállítva, ez elég a DDoS védelemhez?

Nem, az ilyen limitek véletlenszerű csomagdobáshoz vezetnek, a valós kliensek emiatt még többet kérdeznek, ami további terhelést okoz. A rate limitek nagyszerűek ahhoz, hogy az infrastruktúra működőképes maradjon, de ha szolgáltatásban gondolkodunk, akkor az kell, hogy a rossz és valid forgalmat megkülönböztessük, a rosszból minél többet blokkoljunk, a jót pedig lehetőleg teljesen átengedjük. Valójában ez az, amit DDoS védelemnek nevezünk.

• Az internet- vagy hostingszolgáltató routing to blackhole (RTBH) védelmet biztosít.

Jó hír, hogy a szolgáltatónk képes megvédeni a saját hálózatát. A támadott IP címünk azonban eltűnik a térképről, tehát a támadás elérte célját. Ha lehet, használjunk szofisztikáltabb eszközöket.

• Ha a támadás nem produkál kiugró forgalmi értékeket, és a támadó kliensek viselkedése hasonlít a valid kliensekére, akkor nem használ a DDoS védelem.

A dedikált DDoS védelemnek az ilyen esetekre is vannak eszközei: például a kliensek autentikálása, a csomag tartalma alapján történő blokkolás, illetve szignatúrák használata a támadó botok és jellegzetes támadási mintázatok kiszűrésére. Való igaz, minél kifinomultabb a támadás, annál jobb, ha differenciált a védelem is: jól jöhet egy WAF, és az se baj, ha a különböző rendszereink működése (például API-n vagy TAXII feedekkel) összehangolható.

• Elegendő a publikus szolgáltatásokat védeni?

Attól függ, mit nevezünk publikus szolgáltatásnak. Lehet, hogy mi csak a webszerverünket tekintjük annak, de a támadó megszórhatja a szomszédos IP címeinket is, ez a szőnyegbombázásnak nevezett, mostanában reneszánszát élő támadástípus. Ráadásul a COVID miatti lezárások és a távmunka felfutása óta kifejezett kedveltek a VPN koncentrátorok elleni támadások. A támadó szemében tehát minden, internetkapcsolattal bíró erőforrásunk publikus szolgáltatásnak, potenciális célpontnak fog minősülni.

• Kapcsolattáblákat nem lehet túlterhelni UDP alapú támadásokkal.

Kétségtelen, hogy az ilyen támadások jellemzően TCP alapúak, illetve TCP alapú alkalmazások ellen irányulnak. De gondoljunk csak bele, mit csinál a tűzfalunk minden egyes új UDP flow hatására, ha nincs explicite arra utasítva, hogy dobja el az ilyen csomagokat – igen, bejegyzi a kapcsolattáblájába, és idő, rossz esetben percek kérdése, hogy telítődjön.

Összességében tehát fontos, hogy megértsük az egyes DDoS támadási módszerek működését, az ellenük való védekezés módszereit a hálózati infrastruktúra különböző rétegeiben – annak érdekében, hogy egy hatékony, komplex védelmi rendszert tudjunk felépíteni és működtetni.