คุณจะสร้าง runbook สำหรับการตอบสนองต่อ incident DDoS อย่างไร?

Question

Accepted Answer

DDoS runbook เปลี่ยนความตื่นตระหนกให้เป็น checklist หลักการสำคัญของมันคือ **เตรียมพร้อมก่อนการโจมตี ไม่ใช่ระหว่างการโจมตี** — บัญชีถูกจัดเตรียมไว้ รู้จักผู้ติดต่อ และสร้าง dashboard ไว้แล้ว เพื่อให้การตอบสนองเป็นการลงมือทำ ไม่ใช่การด้นสด

## เตรียมพร้อมล่วงหน้า

- มี **ผู้ให้บริการ CDN/scrubbing ที่ integrate ไว้แล้ว** (DNS ชี้ผ่านมัน, โหมด "under attack" ที่คุณพลิกเปิดได้)
- เก็บ **dashboard และ alert ที่เป็น baseline** สำหรับ traffic, error rate, และอัตรา cache-hit เพื่อให้ความผิดปกติปรากฏขึ้นอย่างรวดเร็ว
- เขียน **WAF rule และ rate-limit tier** ไว้ล่วงหน้าที่คุณกระชับได้ทันที
- รักษา **รายชื่อผู้ติดต่อ**: on-call, ฝ่ายสนับสนุน CDN/ISP, ผู้นำ, และเทมเพลต **status-page** ที่พร้อมใช้

## ขั้นตอนของ runbook

1. **ตรวจจับและประกาศ** — alert หรือความผิดปกติที่ correlate กัน (ดู DDoS detection) ทริกเกอร์ incident มอบหมาย incident commander ทันที
2. **ระบุประเภทและเป้าหมายของการโจมตี** — มันเป็น Layer 3/4 (volumetric) หรือ Layer 7 (HTTP flood)? endpoint, IP, หรือ region ใด? ประเภทกำหนดว่าจะใช้ control ใด
3. **เปิดใช้การป้องกัน** — เปิดโหมด "under attack" / scrubbing ของ CDN, **กระชับ WAF rule**, และ **ลด rate limit** เริ่มจาก control ที่ถูกที่สุดและกว้างที่สุด
4. **บล็อก / null-route แหล่งที่มา** — บล็อกช่วง IP หรือ geo ที่ก่อกวนที่ edge เป็นทางเลือกสุดท้าย ขอให้ ISP **null-route** IP ที่เป็นเป้าหมายเพื่อรักษาแพลตฟอร์มที่เหลือ
5. **สื่อสาร** — โพสต์ไปยัง **status page**, อัปเดต stakeholder, และเก็บ timeline การสื่อสารที่ชัดเจนป้องกันวิกฤตที่สองจากความสับสน
6. **Scale หากจำเป็น** — autoscale หรือ overprovision capacity ของ origin เพื่อซับ traffic ที่หลุดผ่านมาในขณะที่ filter กระชับขึ้น
7. **Post-incident review** — เมื่อเสถียรแล้ว รัน retro แบบ blameless: อะไรได้ผล, อะไรช้า, rule ใดควรทำให้ถาวร, และช่องว่างใดควรปิด

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

## ทำไมจึงสำคัญ

ภายใต้การโจมตีจริง ความหน่วงและอะดรีนาลีนทำให้คนข้ามขั้นตอนและทำให้สิ่งต่าง ๆ แย่ลง runbook ให้ลำดับที่รู้จัก เครื่องมือที่สร้างไว้ล่วงหน้า และบทบาทที่ชัดเจน เพื่อให้ทีม mitigate ได้ในไม่กี่นาทีแทนที่จะถกเถียงทางเลือกในขณะที่ไซต์ล่ม บรรทัดที่มีค่าที่สุดใน DDoS runbook ใด ๆ คือการเตรียมพร้อมที่ทำไว้ล่วงหน้า — คุณไม่สามารถ integrate ผู้ให้บริการ scrubbing หรือหาเบอร์ฉุกเฉินของ ISP ในขณะที่คุณกำลังถูกถล่ม