Bagaimana anda akan membina runbook tindak balas insiden DDoS?

Question

Accepted Answer

Sebuah runbook DDoS mengubah panik menjadi senarai semak. Prinsip terasnya: **bersedia sebelum serangan, bukan semasanya** — akaun telah disediakan, kenalan diketahui, dan papan pemuka telah dibina, supaya tindak balas adalah pelaksanaan, bukan improvisasi.

## Bersedia lebih awal

- Miliki **penyedia CDN/scrubbing yang telah diintegrasi** (DNS dihalakan melaluinya, satu mod "under attack" yang boleh anda hidupkan).
- Kekalkan **papan pemuka dan amaran garis dasar** untuk trafik, kadar ralat, dan cache-hit ratio supaya anomali muncul dengan cepat.
- Tulis terlebih dahulu **peraturan WAF dan tier rate-limit** yang boleh anda ketatkan serta-merta.
- Kekalkan **senarai kenalan**: on-call, sokongan CDN/ISP, kepimpinan, dan templat **halaman status (status-page)** yang sedia.

## Langkah-langkah runbook

1. **Kesan dan isytihar** — sebuah amaran atau anomali berkorelasi (lihat pengesanan DDoS) mencetuskan insiden. Lantik incident commander dengan segera.
2. **Kenal pasti jenis serangan dan sasaran** — adakah ia Layer 3/4 (volumetrik) atau Layer 7 (HTTP flood)? Endpoint, IP, atau wilayah yang mana? Jenisnya menentukan kawalan yang anda gunakan.
3. **Aktifkan pertahanan** — hidupkan mod "under attack" / scrubbing CDN, **ketatkan peraturan WAF**, dan **rendahkan rate limit**. Mulakan dengan kawalan yang paling murah dan paling luas.
4. **Sekat / null-route sumber** — sekat julat IP atau geo yang menyalahi di edge; sebagai langkah terakhir, minta ISP **null-route** IP yang disasarkan untuk menyelamatkan platform yang selebihnya.
5. **Berkomunikasi** — siarkan ke **halaman status**, kemas kini pihak berkepentingan, dan simpan satu garis masa. Komunikasi yang jelas mengelakkan krisis kedua iaitu kekeliruan.
6. **Skala jika perlu** — autoscale atau lebihkan peruntukan kapasiti origin untuk menyerap trafik yang menembusi sementara penapis diketatkan.
7. **Semakan pasca insiden** — apabila stabil, jalankan retro tanpa menyalahkan: apa yang berkesan, apa yang lambat, peraturan mana untuk dijadikan kekal, dan jurang mana untuk ditutup.

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

## Mengapa ia penting

Di bawah serangan sebenar, kelewatan dan adrenalina membuatkan orang melangkau langkah dan memburukkan keadaan. Sebuah runbook memberi urutan yang diketahui, alatan yang telah dibina, dan peranan yang jelas, supaya pasukan memitigasi dalam beberapa minit dan bukannya berdebat tentang pilihan sementara laman web tumbang. Baris paling bernilai dalam mana-mana runbook DDoS ialah persediaan yang dilakukan terlebih dahulu — anda tidak boleh mengintegrasi penyedia scrubbing atau mencari nombor kecemasan ISP sementara anda sedang dibanjiri.