DDoS حملے: اقسام، علامات اور بچاؤ

17 فروری، 2026 • 8 min read

DDoS کوئی نیا فینامینن نہیں، مگر آج یہ کہیں زیادہ آسان، سستا اور اسکیل ایبل ہو چکا ہے۔ پہلے چند غلط کنفیگرڈ سرورز یا ایک چھوٹا سا botnet بھی کسی سروس کو متاثر کرنے کے لیے کافی ہوتا تھا۔ اب ہم اکثر ایسے حملے دیکھتے ہیں جو سیکنڈ کے حصّوں میں لنک کو سچوریٹ کر دیتے ہیں، firewall کو اوورلوڈ کر دیتے ہیں، یا بظاہر “نارمل” لگنے والی requests کے ذریعے ایپلیکیشن کو گرا دیتے ہیں۔

یہ مضمون خوف پھیلانے کے لیے نہیں۔ مقصد یہ ہے کہ DDoS کو سیاق و سباق میں سمجھا جائے: DDoS دراصل ہے کیا، عملی طور پر کون سی attack classes اہم ہیں، پروڈکشن میں انہیں کیسے پہچانا جائے، اور کون سی countermeasures واقعی وقت کے لائق ہیں۔

(D)DoS کیا ہے؟

Denial-of-Service (DoS) حملے میں حملہ آور کسی سروس کو ناکارہ بنانے کی کوشش کرتا ہے ڈیٹا چوری کر کے نہیں بلکہ اسے اوورلوڈ کر کے یا اس کے وسائل ختم کر کے۔ ہدف availability ہوتی ہے: ویب سائٹ لوڈ نہیں ہوتی، API timeout کرتی ہے، VPN gateway sessions لینا بند کر دیتا ہے، یا DNS resolvers بوجھ نہیں اٹھا پاتے۔

Distributed میں “D” کا مطلب ہے کہ ٹریفک ایک source سے نہیں بلکہ بہت سے sources سے آتا ہے۔ یہ compromised ڈیوائسز کا botnet ہو سکتا ہے، legitimate infrastructure (reflection/amplification) ہو سکتی ہے، یا دونوں کا mix۔ آپریٹر کے لیے نتیجہ ایک جیسا ہے: آپ کسی ایک attacker سے نہیں بلکہ ایک distributed flood سے نمٹ رہے ہوتے ہیں۔

Motivation: DDoS حملے کیوں کیے جاتے ہیں؟

وجوہات اکثر سادہ ہوتی ہیں، مگر مؤثر:

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 نہیں، مگر حقیقی: ایپ کی مہنگی logic جسے abuse کیا جا سکتا ہے۔

اہم نکتہ یہ ہے: Layer 3/4 پر مضبوط دفاع کے باوجود Layer 7 attacks نکل سکتے ہیں، کیونکہ requests legit لگتے ہیں اور اصل cost ایپ کے اندر جا کر بنتی ہے۔

Attack class 1: Volume اور amplification (اکثر UDP)

Volumetric attacks کا ہدف bandwidth یا packet processing (pps) کو overwhelm کرنا ہوتا ہے۔ ایک classic amplifier reflection/amplification ہے:

attacker 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 کو ٹریفک “normal” services سے آتا نظر آتا ہے جنہیں آپ بلاک نہیں کرنا چاہتے۔

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 کے بارے میں نہیں ہوتا۔ اکثر زیادہ مؤثر یہ ہے کہ target پر state بنایا جائے جب تک tables/resources بھر نہ جائیں۔

ایک classic example TCP پر SYN flood ہے:

عام طور پر 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 کافی ہو: session tracking بھرنے پر سروس “down” ہو جاتی ہے۔

Related category low and slow attacks ہیں: attacker حقیقی connections کھولتا ہے اور minimal traffic کے ساتھ انہیں open رکھتا ہے، جب تک web server یا load balancer connection limits ہٹ نہ کر دیں۔ یہ bandwidth spike کی طرح واضح نہیں ہوتا۔

Attack class 3: Layer 7 اور “Layer 8” (HTTP، APIs، 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 ہے۔ صحیح جگہ پر کم traffic بھی cached static GETs کی بڑی wave سے زیادہ مہنگی ثابت ہو سکتی ہے۔

Production میں DDoS کیسے detect کریں؟

اگر آپ صرف CPU اور RAM دیکھیں تو کچھ attacks دیر سے نظر آئیں گے۔ عملی طور پر baseline اور چند مضبوط 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 بڑھنا، 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: عملی طور پر کیا کام کرتا ہے؟

دو بنیادی راستے ہیں: make (خود بنانا) یا buy (سروس لینا)۔ زیادہ تر ٹیموں کے لیے “buy” زیادہ realistic ہے، کیونکہ DDoS mitigation جلد ہی ایک بڑا موضوع بن جاتا ہے۔

1) App کے سامنے کچھ رکھیں: CDN/WAF/DDoS provider

Websites اور APIs کے لیے یہ اکثر سب سے مؤثر قدم ہوتا ہے:

Anycast networks ٹریفک کو کئی locations میں تقسیم کرتے ہیں۔
WAF rules واضح Layer-7 patterns کو filter کر سکتی ہیں۔
Bot management، rate limits اور challenge/response “cheap” attacks کم کرتے ہیں۔

Important: ہر attack HTTP نہیں ہوتا۔ VPN، VoIP، game servers یا دیگر UDP-based services کے لیے setup کے مطابق مختلف protection layers درکار ہوں گے۔

2) Rate limiting اور timeouts درست رکھیں

سادہ مگر مؤثر:

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 کمپنی setups میں ایسے حصّے بہت ہوتے ہیں: login، search، PDF exports، reports، uploads، complex DB queries، external API calls۔

Typical example: customer portal میں export button (“invoice as PDF”، “generate report”، “download as ZIP”)۔ normal میں کوئی چند منٹ میں ایک بار click کرے۔ attack میں یہی endpoint فی منٹ سینکڑوں/ہزاروں بار hit ہوتا ہے۔ مسئلہ bandwidth نہیں؛ CPU (rendering)، DB (queries) اور worker pools (threads/connections) ہوتے ہیں۔ باہر سے “site slow” لگتی ہے۔ اندر timeouts اور queues نظر آتے ہیں۔

Good news: سب کچھ دوبارہ بنانے کی ضرورت نہیں۔ کچھ architectural فیصلے کافی ہوتے ہیں:

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/timeouts اور ضرورت ہو تو dedicated worker pools۔
“Degraded mode” switches (feature flags): deploy stress کے بغیر temporary disable۔

4) Upstream options: filtering، scrubbing، emergency plans

اگر scale بہت بڑا ہو جائے تو ٹریفک کو connection تک پہنچنے سے پہلے filter کرنا پڑتا ہے:

Provider-side filtering / scrubbing center
Temporary block rules (مثلا: “web server پر UDP کیوں آ رہا ہے؟”)
Emergency routing (مثلا: “protected” IP پر switch)

یہ صرف تب کام کرتا ہے جب provider کے ساتھ پہلے سے بات ہو۔ Incident کے بیچ “ad hoc” شروع کرنا مہنگا اور سست ہوتا ہے۔

Pragmatic checklist (DDoS specialists کے بغیر ٹیموں کے لیے)

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)۔

آخر میں: test کریں، مگر legal اور useful طریقے سے

DDoS testing حساس موضوع ہے۔ Public internet، third-party systems یا بغیر اجازت 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

اگلی بار تک، Joe