Hogyan építenél fel egy DDoS-incidenskezelési runbook-ot?

Question

Accepted Answer

A DDoS runbook a pánikot checklistává alakítja. Alapelve: **készülj fel az támadás előtt, nem alatt** — a fiókok már létrehozottak, az érintkezési személyek ismertek, és az irányítópultok felépítve vannak, így a válaszadás végrehajtás, nem improvizáció.

## Előzetes felkészülés

- Legyen már integrált **CDN/scrubbing provider** (DNS erre mutatva, egy "támadás alatt" mód amit azonnal aktiválhatsz).
- Tartsd meg az **alapvető irányítópultokat és riasztásokat** a forgalomhoz, hibaarányhoz és cache hit arányhoz, hogy az anomáliák gyorsan felszínre kerüljenek.
- Írj elő **WAF szabályokat és rate-limit szinteket** amit azonnal szigoríthat tudsz.
- Tarts fenn egy **kontakt listát**: ügyeletes mérnök, CDN/ISP támogatás, vezetés, és egy kész **status-page sablon**.

## A runbook lépései

1. **Detektálás és deklaráció** — egy riasztás vagy korreláció (lásd DDoS detektálás) incidenst vált ki. Azonnal rendelj ki egy incident commander-t.
2. **Támadás típusának és céljának azonosítása** — 3./4. réteg (volumetrikus) vagy 7. réteg (HTTP flood)? Melyik endpoint, IP vagy régió? A típus meghatározza mely kontrollokat aktiválod.
3. **Védelmi eszközök beindítása** — aktiváld a CDN "támadás alatt" módot / scrubbing-et, **szigoríts meg WAF szabályokat**, és **csökkentsd a rate limiteket**. Kezd a legolcsóbb, legszélesebb körű kontrollokkal.
4. **Forrásokat blokkolni / null-route** — blokkolj offending IP tartományokat vagy geoket az edge-nél; utolsó lehetőségként kérj meg az ISP-t a **null-route** beállítására a célzott IP-hez a platform többi része megmentéséhez.
5. **Kommunikáció** — posztolj a **status page**-re, frissítsd az érdekelteket, és tartsd a idősorozatot. Az átlátható kommunikáció megakadályoz egy második zavaros válságot.
6. **Szükség szerinti skálázás** — autoskálázz vagy túl-allokálj az origin kapacitást a forgalom felszívásához amely áthatol a szűrőkön azok szigorodása közben.
7. **Post-incident review** — ha stabil, futtass egy fault-tolerant retro-t: mi működött, mi volt lassú, mely szabályokat tegyük véglegessé, és mely hiányosságokat zárjuk be.

```text
DETECT -> IDENTIFY -> ENGAGE (CDN/WAF/rate-limit) -> BLOCK/null-route
       -> COMMUNICATE -> SCALE -> POST-INCIDENT REVIEW
```

## Miért számít

Egy valós támadás alatt a latencia és az adrenalin az embereket arra csábítja, hogy kihagyjanak lépéseket és rosszabbá tegyék a dolgokat. A runbook ismert sorozatot, előre felépített eszközöket és világos szerepeket ad, így a csapat percek alatt enyhít ahelyett, hogy az oldal nem működne közben vitázna az opciók felett. A legértékesebb sor bármely DDoS runbook-ban az előtte végzett felkészülés — nem integrálhatsz scrubbing provider-t vagy találhatsz meg az ISP vészhelyzeti számát, miközben elárasztottak.