40. DoS and DDoS – Availability Attacks
40.9 Incident Response for Availability Attacks + CERT-In Awareness
IR for DDoS (short): Prepare → Detect → Mitigate → Communicate → Recover → Lessons.
Practical steps for Indian SME mindset:
- Confirm it is attack vs flash crowd vs broken deploy (metrics + CDN dashboard)
- Enable / escalate scrubbing; tighten WAF; contact ISP
- Status page / honest customer message (Rani's shop – don't pretend "maintenance" forever)
- Preserve traffic samples / logs if investigation needed
- After: hide origin IP, fix rate limits, postmortem
- Awareness: organisational IR plan; CERT-In directions and cybercrime.gov.in / 1930 themes for citizens and orgs (verify current obligations for your entity type – do not invent legal deadlines here)
| Red team (attacker) does | Blue team (defender) detects / stops |
|---|---|
| Extortion DDoS ("pay or we continue") – awareness | Do not pay casually; scrub + law-enforcement / counsel path per policy |
| Switches vector when one path blocked | Multi-layer playbook; CDN+ISP+origin |
| Times attack during sale / festival | Pre-scale; on-call; festival runbook for Raja-Rani |
Ravindra Bagale's Tip
In a panic, students keep rebooting the origin – but the root-cause traffic is still there. Mitigate upstream first. Interview: state the order clearly – detect, then mitigate, then communicate.
Ravindra Bagale's Tip – मराठी
Students panic मध्ये origin वारंवार reboot करतात – root cause traffic अजून आहे. आधी upstream mitigate करा. Interview: detect vs mitigate vs communicate हा order clear बोला.
Ravindra Bagale's Tip – हिंदी
Students panic में origin बार-बार reboot करते हैं – root cause traffic अभी भी है. पहले upstream mitigate करो. Interview: detect vs mitigate vs communicate का order clear बोलो.
Practice task
Scenario: Raja-Rani Traders order page 5xx spike; CDN shows huge RPS from many countries. Write 10-step IR checklist (confirm → scrub → WAF → status note → log keep → postmortem). No "hire botnet to revenge" jokes in professional notes.
Project: Build it, hack it, fix it
Build: On YOUR host-only lab VM (e.g. 192.168.56.40), install nginx (or Apache) for fictional Raja-Rani Traders "online order page". Deliberate weaknesses: (1) no limit_req / limit_conn, (2) tiny worker / connection limits that exhaust easily, (3) long timeouts, (4) firewall allows all TCP from Kali subnet only (still isolate from internet). Snapshot pre-weak-ddos. Hack (lab only): From Kali 192.168.56.10, carefully generate controlled load with ab or siege (example: modest -n/-c, short -t) only to http://192.168.56.40/. Show site becomes slow or returns errors; capture ab/siege output, nginx error/access logs, top. Never target public IPs or amplify. Fix: Add nginx limit_req_zone + limit_req; shorten timeouts; raise workers sensibly; optional firewalld rich rules / fail2ban-style HTTP jail against repeated floods from one lab IP; sudo nginx -t then sudo service nginx reload. Re-verify: Same Kali load – legitimate slow browsing from a second browser session should stay usable while aggressive lab client gets delayed/limited; document metrics for owner Rani. Purple note: Red proved availability risk; Blue proved controls without touching the internet.