Ravindra BagaleCourses & study guides मराठी Track your progress

40. DoS and DDoS – Availability Attacks

By Last updated:

Chala mitrano, Chapter 39 madhe malware baghitla – aata DoS / DDoS. CIA triad madhla A – availability (उपलब्धता). Server online aahe, pan traffic itka jast ki legitimate users la site slow / down distay. Red "band karun takto"; Blue "detect, scrub, rate-limit, survive". Ghabru naka – aapan internet host attack nahi karnaar. Lab = own host-only VMs only. He khup important aahe, lakshat theva!

What you will learn in this chapter

  • DoS vs DDoS: single source vs botnet; availability in CIA
  • Attack classes: volumetric, protocol, application-layer
  • Flood concepts (UDP / ICMP / HTTP) – defender view
  • SYN flood and TCP handshake abuse – SYN cookies, rate limits
  • Amplification / reflection (DNS, NTP, Memcached) – never on public internet
  • Application-layer DoS (slowloris-class) – nginx/Apache timeouts and limits
  • Botnets and IoT (Mirai-class lesson) – default passwords, egress filter
  • Defence stack: scrubbing, Anycast CDN, WAF, firewalld/ufw, monitoring
  • Lab-safe simulation on OWN VMs + ethics + IT Act awareness
  • IR for availability attacks + CERT-In themes; Project Build-Hack-Fix

Lab scope

Practice only against systems you own in host-only / isolated lab (Kali 192.168.56.10, Metasploitable 192.168.56.20, your own nginx/Apache lab VM). Never flood internet hosts, never run amplification against third-party DNS/NTP/Memcached, never build or rent a botnet. Controlled load tools (hping3, ab, siege) with strict limits and short duration only. IT Act sections such as 43 and 66 apply if you disrupt others' systems (verify current text). Lab = learn defence. Production = protect availability.

Concepts in this chapter

  1. 40.1What Is DoS vs DDoS – Availability First
  2. 40.2Volumetric and Flood Concepts – Defender View
  3. 40.3Protocol Attacks – SYN Flood and Handshake Abuse
  4. 40.4Amplification and Reflection – Closed Lab Only
  5. 40.5Application-Layer DoS – Slow and Heavy Requests
  6. 40.6Botnets and IoT – Mirai-Class Lesson
  7. 40.7Detection and Defence Stack
  8. 40.8Lab-Safe Simulation – Ethics First
  9. 40.9Incident Response for Availability Attacks + CERT-In Awareness
  10. 40.10Putting It Together – Purple Team Mindset

The chapter recap is at the end of the last concept page.

Chapter 40: DoS and DDoS — defence only — practice tasks

Open chapter lessons · Full guided lab: nginx rate limiting 429 small load test (not repeated here)

40.1 Add nginx rate limiting

MediumRetail

Why: Rate limits protect login and APIs.

What: Limit requests on your lab nginx only.

How:

  1. Add limit_req_zone and limit_req to nginx.
  2. Reload; then ab -n 100 -c 20 http://127.0.0.1/ on localhost.

Expected output: Some 503/429 responses under load.

Hint

See linked rate-limit lab. Never load-test sites you don't own.

Answer / how to check
  1. ab shows non-200 responses.

40.2 Distinguish volumetric vs app DoS (paper)

EasyIT

Why: Different attacks need different defences.

What: Match each row.

Data file: dos.csv

AttackLayer (fill)
SYN floodNetwork
SlowlorisApplication
DNS amplificationNetwork

About this file: Made-up matching. Each row is one attack type. Columns: Attack; Layer to fill.

How:

  1. Read the data file.

Expected output: SYN flood Network; Slowloris Application; DNS amp Network.

Hint

Cloudflare/WAF help at the edge.

Answer / how to check
  1. All three matched.

40.3 Uptime check script

EasyLogistics

Why: Detect outages early.

What: Poll your lab site every minute.

How:

  1. while true; do curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1/; sleep 60; done
  2. Stop nginx; watch codes change to 000.

Expected output: 200 then 000 when down.

Hint

Alerting tools do this better in prod.

Answer / how to check
  1. You saw the code change.

Extended teaching notes

Why this lesson matters

Availability attacks try to exhaust bandwidth, connections or app workers. Learning them is about detection and defence — never about stressing networks you do not own (that can be illegal and harmful).

  • Rate limits and WAF/CDN at the edge.
  • SYN cookies / tuning on servers.
  • Autoscaling with care (cost controls).
  • Keep IoT devices off default passwords (Mirai lesson).
  • Lab simulations only on isolated networks you own.

Mini case study

Suppose we are on a purple-team exercise for an Indian mid-size company (sample data). Red notes a technique from this lesson against a lab clone. Blue must show the control that stops it, the log that would have fired, and the ticket that hardens production. That is the standard this course trains you for.

Defender's worksheet (do this today)

  1. Write the lesson title, date and the exact lab target you are allowed to use.
  2. List three owned systems (VMs, apps, or cloud accounts) where this lesson applies.
  3. Run one safe check from the lesson on a lab system only. Paste the command and output.
  4. Write a two-sentence fix you would give a teammate.
  5. Name one related public advisory (CERT-In, CISA, NVD, or a vendor bulletin) with its date.

Indian workplace (sample data)

Suppose we are a junior analyst at Infosys, TCS, Wipro or a fintech SOC in Bengaluru/Pune. Turn this lesson into one checklist item with an owner, a due date and a place to store evidence (ticket + screenshot).

Global practice

Compare your notes with OWASP, CIS Benchmarks, NIST CSF/IR guidance or a cloud Well-Architected security question. Write five lines on what overlaps.

Everyday analogy

Explain the risk and the fix to a family member without jargon. If they can repeat the warning, you understand it well enough to teach juniors.

Key terms

  • Control: a safeguard (patch, config, process, detection).
  • Finding: a weakness backed by evidence.
  • Remediation: the fix plus how you verified it.
  • Scope: systems you have written permission to touch.
  • Least privilege: only the access the task needs.
  • Defence in depth: several layers so one failure does not end the story.

Common mistakes

  • Skipping written permission "just for a quick scan".
  • Practising on hostel, office or public targets without authorisation.
  • Collecting tool output without writing the fix.
  • Copying attack steps onto production to "verify". Defenders verify with versions, configs and patches.
  • Publishing screenshots that contain secrets, cookies or internal hostnames.

Recap

  • Evidence, fix, owner, date.
  • Own lab only.
  • Fix > spectacle.