DDoS védelem: mire készüljön fel

A túlterheléses támadás nem adatot lop, hanem elérhetetlenné tesz. Emiatt sokan alacsonyabb prioritásnak tekintik, pedig egy webshopnál vagy egy ügyfélportálnál a kiesés közvetlen bevételkiesés, és egyre gyakrabban zsarolással párosul.

Három típus

Volumetrikus. A sávszélesség telítése nagy mennyiségű forgalommal. Ez a leggyakoribb, és ez ellen a saját infrastruktúrán nem lehet védekezni: mire a forgalom odaér, már késő. Csak a szolgáltató vagy egy erre szakosodott szolgáltatás tudja megszűrni.

Protokoll-alapú. Nem a sávszélességet, hanem az állapottáblákat meríti ki: félig nyitott kapcsolatok, töredezett csomagok. A tűzfal vagy a terheléselosztó kapacitása fogy el.

Alkalmazás-szintű. Kis forgalommal terhel meg egy drága műveletet: keresés, riportgenerálás, bejelentkezés. Nehezen különböztethető meg a valós forgalomtól, mert technikailag helyes kérésekből áll.

Mit tud a szolgáltatója

Ez az első kérdés, amit tisztázni kell, és a legtöbb szervezet nem tudja a választ.

• Van-e egyáltalán DDoS-szűrés a szolgáltatói szerződésben?
• Automatikusan bekapcsol, vagy kérni kell?
• Mekkora forgalomig véd?
• Mennyi a reakcióidő, és van-e 24 órás elérhetőség?

Ha a válasz bármelyikre bizonytalan, azt támadás közben deríteni ki rossz ötlet.

Amit magának kell megoldania

Alkalmazás-szintű korlátozás. A drága műveletekre (keresés, export, bejelentkezés) sebesség-korlátozás felhasználónként és IP-címenként. Ez az egyetlen védelem az alkalmazás-szintű támadás ellen.

Gyorsítótárazás. Ami statikus, azt ne az alkalmazás szolgálja ki. Egy jól beállított CDN a volumetrikus támadás jelentős részét is elnyeli.

Erőforrás-korlátok. Kapcsolatszám, kérésméret, időtúllépés. Enélkül egyetlen lassú kliens is leköthet erőforrást.

Autoskálázás, ha van. Felhős környezetben a skálázás elnyeli a csúcsot, de vigyázni kell: a támadó így a számlát növeli, ha nincs felső korlát.

Amit előre elő kell készíteni

Kapcsolati lista. Kit hív a szolgáltatónál, milyen csatornán, mi a szerződésszám. Nyomtatva is.

Döntési pontok. Mikor kapcsolják be a szűrést, mikor korlátozzák a funkciókat, mikor kommunikálnak az ügyfelek felé.

Statikus tartalék-oldal. Ha az alkalmazás nem bírja, egy egyszerű, gyorsítótárazott oldal, ami tájékoztat, jobb, mint a hibaüzenet.

Kommunikációs sablon. Mit mondanak az ügyfeleknek, és hol. Ha a saját oldal elérhetetlen, kell egy másik csatorna.

Amit ne csináljon

Ne blokkoljon vakon IP-tartományokat. Támadás közben könnyű véletlenül kizárni valós ügyfeleket, és ezt utólag nehéz észrevenni.

Ne feltételezze, hogy a tűzfal megoldja. A volumetrikus támadásnál a tűzfal a szűk keresztmetszet, nem a védelem.

Ne hagyja ki a gyakorlást. A DDoS-terv is terv: ha soha nem próbálták végig, támadás közben derül ki, mi hiányzik. Erről az incidens első 24 órájáról szóló cikkünkben írtunk.

Az IT biztonsági szolgáltatásaink között a rendelkezésre állási architektúra felülvizsgálata is szerepel.