DDoS हमले: प्रकार, लक्षण और बचाव

17 फ़रवरी 2026 • 8 min read

DDoS कोई नया फिनॉमेनन नहीं है, लेकिन आज यह कहीं ज्यादा आसान, सस्ता और स्केलेबल हो गया है। पहले कुछ गलत-कॉन्फ़िगर किए हुए सर्वर या छोटा सा botnet किसी सर्विस को बाधित करने के लिए काफी होता था। आज हम अक्सर ऐसे हमले देखते हैं जो सेकंड के हिस्सों में लिंक सैचुरेट कर देते हैं, firewall को ओवरलोड कर देते हैं, या “नॉर्मल” दिखने वाले requests के जरिए एप्लिकेशन को घुटनों पर ला देते हैं।

यह लेख डर फैलाने के लिए नहीं है। इसका मकसद संदर्भ देना है: DDoS वास्तव में क्या है, प्रैक्टिस में कौन-सी attack classes मायने रखती हैं, प्रोडक्शन में इन्हें कैसे पहचाना जाए, और कौन-सी countermeasures वाकई समय के लायक हैं।

(D)DoS क्या है?

Denial-of-Service (DoS) अटैक में अटैकर किसी सर्विस को unusable बनाने की कोशिश करता है डेटा चुराकर नहीं, बल्कि उसे ओवरलोड करके या उसके resources खत्म करके। टार्गेट availability है: वेबसाइट लोड नहीं होती, API timeout करती है, VPN gateway sessions स्वीकार करना बंद कर देता है, या DNS resolvers साथ नहीं दे पाते।

Distributed में “D” का मतलब है कि ट्रैफिक एक source से नहीं, कई sources से आता है। यह compromised devices का botnet हो सकता है, legitimate infrastructure (reflection/amplification) हो सकती है, या दोनों का mix। ऑपरेटर के लिए परिणाम एक जैसा है: आप एक attacker से नहीं, distributed flood से जूझ रहे होते हैं।

Motivation: DDoS हमले क्यों किए जाते हैं?

मकसद अक्सर boring होते हैं, लेकिन असरदार:

Extortion: “पैसे दो, वरना फिर गिरा देंगे।”
Activism/politics: visibility, messaging, disruption.
Distraction: टीम DDoS में उलझ जाती है और साथ में कुछ और चल सकता है।
Competition/sabotage: critical moments (ticketing, releases, launches) में छोटा downtime भी नुकसान करता है।
Cost pressure: हर हमला full outage के लिए नहीं होता; कभी लक्ष्य cloud costs, support load या operational stress बढ़ाना भी होता है।

महत्वपूर्ण layers (और क्यों जरूरी हैं)

DDoS को layers में समझाया जाता है, क्योंकि layer बताती है कि कौन-से signals देखने हैं और कौन-सी defenses संभव हैं।

Layer 3 (IP): कहां से आया और कहां जाना है।
Layer 4 (TCP/UDP): ports, connections, handshakes, state.
Layer 7 (Application): HTTP(S) requests, APIs, business endpoints.
“Layer 8” (Business logic): official नहीं, लेकिन real: ऐप की expensive logic जिसे abuse किया जा सकता है।

Key takeaway: Layer 3/4 पर perfect defense होने के बाद भी Layer 7 attacks निकल सकते हैं, क्योंकि requests legitimate दिखते हैं और असल cost ऐप में पहुंचकर आती है।

Attack class 1: Volume और amplification (अक्सर UDP)

Volumetric attacks bandwidth या packet processing (pps) को overwhelm करने के लिए होते हैं। एक classic amplifier है reflection/amplification:

अटैकर publicly reachable servers (जैसे open DNS resolvers) को छोटे requests भेजता है।
वह source IP spoof करता है और victim IP को “source” बना देता है।
वे servers victim को बहुत बड़े responses भेजते हैं।

अगर 100-byte request से 1,000-byte response आता है, तो factor 10 मिल गया। Protocol और payload पर निर्भर करते हुए factor काफी बड़ा हो सकता है। समस्या: victim के perspective से ट्रैफिक “normal” services से आता है जिन्हें आप block नहीं करना चाहते।

Important point: amplification अक्सर source IP spoofing पर निर्भर करता है। इसलिए ingress filtering (BCP 38) इतना जरूरी है। अगर providers edge पर forged source addresses को block करें, तो यह vector काफी मुश्किल हो जाता है।

Attack class 2: Protocol और state exhaustion (TCP/Layer 4)

हर DDoS maximum bandwidth के बारे में नहीं है। अक्सर ज्यादा efficient होता है target पर state बनाते जाना, जब तक tables/resources भर न जाएं।

एक classic example है TCP पर SYN flood:

Normal रूप से TCP three-way handshake से connection बनाता है (SYN -> SYN/ACK -> ACK)।
SYN flood में attacker बहुत सारे SYN packets भेजता है, लेकिन final ACK नहीं आता।
Server बहुत सारी half-open connections (state) रखता है और timeouts तक retries करता है।

यह memory और CPU consume करता है और outbound bandwidth पर भी असर डाल सकता है। और भले ही bandwidth plenty हो: session tracking भरते ही service “down” हो जाती है।

Related category है low and slow attacks: attacker real connections खोलता है और minimal traffic के साथ उन्हें open रखता है, जब तक web server या load balancer connection limits हिट न कर दें। यह bandwidth spike जितना obvious नहीं होता।

Attack class 3: Layer 7 और “Layer 8” (HTTP, API, expensive endpoints)

Layer-7 attacks अक्सर सबसे annoying होते हैं, क्योंकि उन्हें legitimate traffic से अलग पहचानना मुश्किल होता है। उदाहरण:

HTTP floods: dynamic pages, search endpoints या login flows पर बहुत सारे requests।
Slowloris/slow headers: headers/bodies बहुत धीरे भेजकर connections open रखना।
“Expensive” business logic: endpoints जो DB queries, external API calls, PDF generation, cryptography या AI/agent workflows trigger करते हैं।

Trick अक्सर “more traffic” नहीं, बल्कि more work per request होता है। सही endpoints पर थोड़ी सी traffic भी cached static GETs की बड़ी wave से ज्यादा costly हो सकती है।

Production में DDoS कैसे detect करें?

अगर आप सिर्फ CPU और RAM देखें, तो कुछ attacks बहुत देर से पकड़ में आएंगे। प्रैक्टिस में baseline के साथ कुछ robust metrics मदद करती हैं:

Traffic: bps और pps edge पर (router, firewall, load balancer)।
Connection metrics: new connections/s, open sessions, SYN backlog, TLS handshakes/s।
HTTP metrics: RPS, latency (p95/p99), 4xx/5xx ratios, timeouts।
Upstream symptoms: packet loss, RTT increase, saturated links, BGP events।
Log/WAF signals: unusual paths, invalid headers, incomplete requests, suspicious user agents/patterns।

सबसे जरूरी बात: baseline चाहिए। baseline के बिना सब “ज्यादा” लगता है। baseline हो तो “small packets” या “incomplete requests” जैसी चीजें तुरंत abnormal दिखती हैं।

Mitigation: प्रैक्टिस में क्या काम करता है?

दो approach होते हैं: make (खुद बनाना) या buy (service लेना)। ज़्यादातर teams के लिए “buy” ज़्यादा realistic है, क्योंकि DDoS mitigation जल्दी ही एक बड़ा subject बन जाता है जिसे side project की तरह नहीं चलाया जा सकता।

1) App के सामने कुछ लगाओ: CDN/WAF/DDoS provider

Websites और APIs के लिए यह अक्सर सबसे effective है:

Anycast networks traffic को कई locations में distribute करते हैं।
WAF rules obvious Layer-7 patterns filter कर सकती हैं।
Bot management, rate limits और challenge/response “cheap” attacks reduce करते हैं।

Important: हर attack HTTP नहीं होता। अगर आप VPN, VoIP, game servers या UDP-based protocols expose करते हैं, तो setup के अनुसार अलग layers की protection चाहिए।

2) Rate limiting और timeouts सही सेट करें

Simple, लेकिन सही तरीके से करने पर effective:

ICMP/“ping”: limit करें, पूरी तरह ban न करें (troubleshooting के लिए जरूरी है)।
HTTP: IP/token/route के हिसाब से limit करें, खासकर expensive endpoints पर।
Slow requests: incomplete headers/bodies के लिए hard timeouts।

Example (Nginx, heavily simplified):

limit_req_zone $binary_remote_addr zone=api_per_ip:10m rate=10r/s;

location /api/ {
  limit_req zone=api_per_ip burst=40 nodelay;
}

यह silver bullet नहीं है, लेकिन economics बदल देता है: “cheap” attacks harder हो जाते हैं।

3) Architecture: expensive work को अलग करें

Layer-7 DDoS अक्सर bandwidth को नहीं, बल्कि उन हिस्सों को हिट करता है जहां एक request disproportionally expensive होता है। Normal company setups में ऐसे कई होते हैं: login, search, PDF export, reports, uploads, complex DB queries, external API calls।

Typical example: customer portal में export button (“invoice as PDF”, “generate report”, “download as ZIP”)। Normal में कोई हर कुछ मिनट में क्लिक करता है। Attack में वही endpoint प्रति मिनट सैकड़ों/हजारों बार hit होता है। Problem bandwidth नहीं; CPU (rendering), DB (queries) और worker pools (threads/connections) होते हैं। बाहर से बस “site slow” लगता है। अंदर timeouts, queueing और DB bottleneck दिखता है।

Good news: सब कुछ फिर से बनाने की जरूरत नहीं। कुछ architecture choices often enough होती हैं:

Caching (error pages सहित), sensible TTLs, edge caching।
Expensive jobs के लिए asynchronous processing (queues): “PDF now” की जगह job trigger करके बाद में deliver।
Strict input validation और early aborts: complexity limit, hard limits per request।
Login/search/upload/export के लिए separate protection: dedicated rate limits, dedicated timeouts, और जरूरत हो तो dedicated worker pools।
“Degraded mode” switches (feature flags): deploy stress के बिना temporary disable।

4) Upstream options: filtering, scrubbing, emergency plans

अगर scale बहुत बड़ा हो, तो traffic को connection तक पहुंचने से पहले filter करना होगा:

Provider-side filtering / scrubbing center
Temporary block rules (उदाहरण: “web server पर UDP क्यों आ रहा है?”)
Emergency routing (उदाहरण: “protected” IP पर switch)

यह तभी काम करता है जब provider के साथ पहले से चर्चा हो। Incident के बीच “ad hoc” शुरू करना slow और expensive होता है।

Pragmatic checklist (बिना DDoS specialists वाली teams के लिए)

Inventory: कौन-सी services public हैं? HTTP, DNS, VPN, mail, gaming, VoIP?
Single points of failure: DNS provider, reverse proxy, load balancer, single region?
Observability: bps/pps, RPS, latencies, errors, connection counts, baseline-based alerts।
Harden defaults: timeouts, limits, maximum header sizes, connection limits, backpressure।
Provider plan: कौन scrubs करेगा, कौन filter करेगा, escalation paths क्या हैं?
Runbook: “अगर X हो, तो Y”, contacts/thresholds/switches (feature flags) सहित।
Practice: controlled load tests और incident drills (legal और coordinated)।

अंत में: टेस्ट करें, लेकिन legal और useful तरीके से

DDoS testing sensitive है। Public internet, third-party systems या बिना permission वाली infra को छूना off limits है। जो आप कर सकते हैं:

अपनी staging पर load tests (खासकर expensive endpoints पर)।
Dependencies पर chaos tests (cache down, DB slow, tighter rate limits)।
Response process की practice: alerts, comms, provider escalation, emergency measures।

Sources and further reading

अगली बार तक जो