आप एक DDoS incident response runbook कैसे बनाएँगे?

Question

Accepted Answer

एक DDoS runbook घबराहट को एक checklist में बदल देता है। इसका मूल सिद्धांत: **attack के दौरान नहीं, बल्कि पहले से तैयारी करें** — accounts provisioned, contacts ज्ञात, और dashboards बने हुए, ताकि प्रतिक्रिया execution हो, सुधार-आविष्कार नहीं।

## पहले से तैयारी करें

- एक **CDN/scrubbing provider पहले से integrated** रखें (DNS उसके माध्यम से pointed, एक "under attack" mode जिसे आप flip कर सकें)।
- traffic, error rate, और cache-hit ratio के लिए **baseline dashboards और alerts** रखें ताकि anomalies जल्दी सामने आएँ।
- **WAF rules और rate-limit tiers** पहले से लिख रखें जिन्हें आप तुरंत कस सकें।
- एक **contact list** बनाए रखें: on-call, CDN/ISP support, leadership, और एक तैयार **status-page** template।

## runbook के चरण

1. **Detect and declare** — एक alert या correlated anomaly (DDoS detection देखें) एक incident trigger करता है। तुरंत एक incident commander नियुक्त करें।
2. **Identify attack type and target** — क्या यह Layer 3/4 (volumetric) है या Layer 7 (HTTP flood)? कौन-सा endpoint, IP, या region? type तय करता है कि आप कौन-से controls लगाते हैं।
3. **Engage defenses** — CDN "under attack" mode / scrubbing चालू करें, **WAF rules कसें**, और **rate limits घटाएँ**। सबसे सस्ते, सबसे व्यापक controls से शुरू करें।
4. **Block / null-route sources** — दोषी IP ranges या geos को edge पर block करें; अंतिम उपाय के रूप में, ISP से targeted IP को **null-route** करने को कहें ताकि बाकी platform बच जाए।
5. **Communicate** — **status page** पर post करें, stakeholders को update करें, और एक timeline रखें। स्पष्ट संवाद भ्रम के दूसरे संकट को रोकता है।
6. **Scale if needed** — autoscale करें या origin capacity को overprovision करें ताकि filters कसते समय जो traffic गुज़र जाता है उसे सोखा जा सके।
7. **Post-incident review** — स्थिर होने के बाद, एक blameless retro चलाएँ: क्या काम किया, क्या धीमा था, किन rules को स्थायी बनाना है, और किन gaps को बंद करना है।

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

## यह क्यों महत्वपूर्ण है

एक वास्तविक attack के दौरान, latency और adrenaline लोगों को कदम छोड़ने और चीज़ें बिगाड़ने पर मजबूर कर देते हैं। एक runbook एक ज्ञात क्रम, पहले से बने tooling, और स्पष्ट roles देता है, ताकि team site के down रहते हुए विकल्पों पर बहस करने के बजाय मिनटों में mitigate कर ले। किसी भी DDoS runbook में सबसे मूल्यवान पंक्ति वह तैयारी है जो पहले से की जाती है — जब आप पर flood हो रहा हो तब आप किसी scrubbing provider को integrate नहीं कर सकते या ISP का आपातकालीन नंबर नहीं खोज सकते।