Worked examples — Network security — DDoS, man-in-the-middle, replay attacks, countermeasures

4.3.31 · D3 · Coding › Computer Networks › Network security — DDoS, man-in-the-middle, replay attacks,

Parent dekho: (Hinglish version).

---

The scenario matrix

Har row ek case class hai — ek alag tarah ki situation jo is topic ki maths tumhare saamne rakh sakti hai. Neeche har example us cell ke saath tagged hai jise wo cover karta hai.

#	Case class	Kya ise alag banata hai	Worked in
C1	DDoS below threshold	$\lambda <B/T$ — server survive karta hai	Ex 1
C2	DDoS at/above threshold	$\lambda \ge B/T$ — service collapse ho jaati hai	Ex 2
C3	Amplification factor	ratio $A=c_s/c_a$, reflection maths	Ex 3
C4	Degenerate input	$T=0$ (instant timeout) ya $B=\infty$	Ex 4
C5	Limiting behaviour	kya hota hai jab $\lambda \to \infty$ ya $T\to \infty$	Ex 4
C6	Replay caught	nonce already "seen" set mein hai	Ex 5
C7	Replay slips through	timestamp window $\Delta$ bahut wide hai	Ex 6
C8	MITM key mix-up	do DH keys $K_1\ne K_2$, auth se detect karo	Ex 7
C9	Real-world word problem	CDN sizing / proof-of-work ka cost	Ex 8
C10	Exam-style twist	combined defence, "which fix and why"	Ex 9

Shuru karne se pehle, ek symbol jo hum har jagah reuse karte hain:

---

Ex 1 — DDoS below threshold (Cell C1)

1. Steady-state occupancy compute karo Little's Law $L=\lambda T$ use karke. $L=20\times 30=600\text{ slots}.$ Ye step kyun? Little's Law (Little's Law) kehta hai ki kisi system mein baithe items ki average number arrival-rate $\times$ time-in-system ke barabar hoti hai. Yahan items = half-open connections. Hum ise isliye use karte hain kyunki hume care hai ki average mein kitne slots occupied hain, kisi ek connection ke baare mein nahi.

2. Capacity se compare karo $B=1024$. $L=600<1024=B.$ Ye step kyun? Parent se collapse condition hai $\lambda \ge B/T$. Equivalently $\lambda T\ge B$. Kyunki $600<1024$ hai, queue kabhi fill nahi hoti — ek real user ke liye hamesha ek free slot hota hai.

---

Ex 2 — DDoS at/above threshold (Cell C2)

1. Would-be occupancy nikalo $L=\lambda T=50\times 30=1500$ slots. Ye step kyun? Ye kitne slots flood hold karna chahta hai — ye $B$ se zyada ho sakta hai.

2. Use $B$ par cap lagao. Real occupancy $=\min (B,\lambda T)=\min (1024,1500)=1024$. Ye step kyun? Tum physically $B$ se zyada slots hold nahi kar sakte. Figure mein red line ko ceiling se takraate dekho.

3. Rejection fraction. Ek baar full hone ke baad, ek slot sirf $B/T=34.13$/s ki rate se free hota hai, lekin demand (attacker + legit) bahut zyada tezi se aati hai. Attacker SYNs ka fraction jo jagah paata hai $=(B/T)/\lambda =34.13/50=0.683$; baki, aur practically saare legit users jo full queue par aate hain, drop ho jaate hain. Legit rejection $\approx 1-(B/T)/\lambda$. $\text{reject frac}\approx 1-\frac{34.13}{50}=0.317\to \text{lagbhag }32\%\text{queue churn real users hain jo push out ho rahe hain.}$ Ye step kyun? Hum "queue full" ko ek number mein convert karte hain: server sirf $B/T$ new connections per second admit kar sakta hai, isliye koi bhi excess arrival rate lost ho jaati hai.

---

Ex 3 — Amplification factor (Cell C3)

1. Amplification factor $A=c_s/c_a$ jahan $c_s$ = bytes jo victim receive karta hai, $c_a$ = bytes jo attacker bhejta hai. $A=\frac{3072}{64}=48.$ Ye step kyun? Reflection attacks mein resolver outbound cost pay karta hai. $A$ measure karta hai ki reflected reply trigger se kitni badi hai — ANY choose karne ka yehi point hai.

2. Attacker ki apni outbound rate. $2000\times 10=20000$ queries/s $\times 64$ bytes $=1,280,000$ bytes/s $=1.28$ MB/s. Ye step kyun? Hume attacker ka cost chahiye taki phir $A$ se multiply kar sakein.

3. Victim-bound flood. $1.28\text{ MB/s}\times 48=61.44$ MB/s $=61.44\times 8=491.52$ Mbps. Ye step kyun? Har attacker byte $A$ victim bytes ban jaata hai. MB/s ko Mbps mein convert karne ke liye $8$ se multiply karo (bandwidth bits mein quote hoti hai).

---

Ex 4 — Degenerate & limiting inputs (Cells C4, C5)

1. (a) $T=0$ — instant timeout (yeh essentially SYN cookies hai). $L=\min (B,\lambda \cdot 0)=\min (B,0)=0$. Ye step kyun? Agar koi bhi state kabhi hold nahi hoti (instantly free / kabhi allocate nahi hoti), toh koi flood accumulate nahi ho sakta. Occupancy $\lambda$ chahe kuch bhi ho $0$ rehti hai. Immune. Yehi wajah hai ki SYN cookies kaam karte hain — woh $T$ ko effectively $0$ tak push kar dete hain.

2. (b) $B\to \infty$ — infinite queue. $L=\min (\infty ,\lambda T)=\lambda T$, finite $\lambda$ ke liye finite. Ye step kyun? Tum "kabhi reject nahi karte" — lekin memory bhi ek resource hai, isliye $\lambda T$ slots of RAM phir bhi consume hoti hai. Parent ki "bigger $B$" mistake yahan rehti hai: tumne ek full-queue failure ko out-of-memory failure se trade kar diya.

3. (c) $\lambda \to \infty$. $L=\min (B,\infty )=B$; queue instantly saturate hoti hai aur pinned rehti hai. Ye step kyun? Limit dikhata hai ki worst case $B$ se bounded hai — occupancy ceiling se zyada nahi ja sakti — lekin har legit user reject ho jaata hai. Doomed jab tak $T$ chota na ho.

4. (d) $T\to \infty$. Kisi bhi $\lambda >0$ ke liye $\lambda T\to \infty$, isliye $L=\min (B,\infty )=B$; queue kisi bhi attack rate par kaafi time dene par fill ho jaati hai. Ye step kyun? Ek server jo half-open connections ko kabhi timeout nahi karta woh even ek trickle se defeat ho jaata hai. Isliye timeout $T$ exist karta hai.

---

Ex 5 — Replay caught by a nonce (Cell C6)

1. Server seen-set check karta hai. $n=17\in \text{seen}$ → reject, MAC recompute karne se pehle bhi. Ye step kyun? Freshness pehla gate hai. Ek replayed nonce by definition fresh nahi hoti; tag kaise form hota hai dekhne ke liye Message Authentication Codes (MAC) & HMAC dekho.

2. Eve $n=18$ try karti hai (ek value jo abhi tak nahi dekhi gayi), purana $t$ rakhti hai. Ye step kyun? Woh freshness check par attack kar rahi hai ek "naya" nonce supply karke.

3. MAC verification fail hoti hai. Server ${\text{MAC}}_K(m\Vert 18)$ recompute karta hai aur Eve ke $t$ se compare karta hai, jo ${\text{MAC}}_K(m\Vert 17)$ tha. Kyunki $18\ne 17$ toh inputs differ karte hain, isliye tags differ karte hain (siwa negligible probability $2^{-\ell }$ ke ek $\ell$-bit MAC ke liye). Reject. Ye step kyun? MAC $n$ ko $m$ ke saath secret key $K$ ke under bind karta hai. Eve bina $K$ ke $n=18$ ke liye tag forge nahi kar sakti. Isliye nonce MAC ke andar hoti hai, uske beside nahi.

---

Ex 6 — Replay slips through a loose window (Cell C7)

1. Pehla replay $103.0$ s par. $|103.0-100.0|=3.0\le 5=\Delta$ → accepted (replay succeed karta hai!). Ye step kyun? Window ke andar, sirf timestamp ek fresh message aur replay mein distinguish nahi kar sakta — ye sirf age check karta hai, uniqueness nahi.

2. Doosra replay $108.5$ s par. $|108.5-100.0|=8.5>5$ → rejected (bahut purana). Ye step kyun? Window hi ek maatra defence hai; ek baar message $\Delta$ se age ho jaata hai toh expire ho jaata hai.

3. Fix. Window ke andar ek seen-set (nonce) add karo, ya $\Delta$ chota karo. Nonce ke saath, $103.0$ s wala replay bhi pakda jaata, jaise Ex 5 mein. Ye step kyun? Ye parent ka core lesson hai: ek timestamp attack window bound karta hai lekin ek nonce ise close karta hai. Wide $\Delta$ = wide replay window.

---

Ex 7 — MITM key mix-up in Diffie–Hellman (Cell C8)

1. Public values. $A=g^a\mathrm{mod}p=5^6\mathrm{mod}23$, $B=g^b\mathrm{mod}p=5^{15}\mathrm{mod}23$, Eve's $E=g^e\mathrm{mod}p=5^3\mathrm{mod}23=125\mathrm{mod}23=10$. Ye step kyun? DH $g^{\text{secret}}\mathrm{mod}p$ open mein exchange karta hai; secret exponent private rehta hai. Eve apna $E$ dono sides ke liye substitute karti hai — yehi hai man-in-the-middle.

2. Alice ki key (woh sochti hai Bob ke saath share kar rahi hai, actually Eve ke saath hai): $K_1=E^a\mathrm{mod}p=10^6\mathrm{mod}23$. Compute: $10^2=100\equiv 8$, $10^3\equiv 80\equiv 11$, $10^6=(10^3{)}^2\equiv 11^2=121\equiv 6$. Toh $K_1=6$. Ye step kyun? Alice jo value receive ki (Eve's $E$) use apne secret se raise karti hai — standard DH combine.

3. Bob ki key (Eve ke saath): $K_2=E^b\mathrm{mod}p=10^{15}\mathrm{mod}23$. $10^6\equiv 6$, $10^{12}\equiv 6^2=36\equiv 13$, $10^{15}=10^{12}\cdot 10^3\equiv 13\cdot 11=143\equiv 143-138=5$. Toh $K_2=5$. Ye step kyun? Same combine, Bob ka secret. Note karo $K_1=6\ne 5=K_2$: Eve har side ke saath ek key hold karti hai, exactly parent ki picture.

4. Fix — authentication. Agar Alice ne apna $A$ sign kiya hota (via Public Key Infrastructure & Certificates / TLS handshake), Eve $A$ ko $E$ se replace nahi kar sakti thi bina signature tode. Mismatch secrecy ke liye invisible hai lekin authenticity ke liye fatal hai. Ye step kyun? DH ek shared secret deta hai lekin kabhi prove nahi karta ki kiska secret hai. Public value sign karna identity ko key se bind karta hai.

---

Ex 8 — Real-world word problem: proof-of-work as a defence (Cell C9)

1. Har token ka work. $d$ leading zero bits dhundhne ke liye average mein $2^d=2^{20}=1,048,576$ hashes chahiye. Ye step kyun? Har hash output uniform hai, isliye $d$ leading zeros ki chance $2^{-d}$ hai; succeed hone ke liye expected trials $1/2^{-d}=2^d$ hai. Ye attacker ka naya $c_a$ hai — humne ise deliberately badhaaya.

2. Hashes needed per second. $R\times 2^d=1000\times 1,048,576=1.049\times 10^9$ hashes/s. Ye step kyun? $R$ tokens/s har ek $2^d$ hashes cost karta hai.

3. Cores required. $\frac{1.049\times 10^9}{10^7}=104.9\to 105$ cores. Ye step kyun? Total hash demand ko ek core ke throughput se divide karo; round up karo (tum ek core ka fraction rent nahi kar sakte).

4. $A$ par effect. PoW se pehle attacker ek cheap packet pay karta tha ($c_a$ chota, $A$ bada). Ab $c_a$ $2^{20}$ se jump kar gaya, isliye $A=c_s/c_a$ $1$ ya neeche collapse ho jaata hai — woh asymmetry jo DDoS ko worthwhile banati thi chali gayi. Ye step kyun? Yaad karo $A=c_s/c_a$: $c_a$ badhana $A$ par direct lever hai, exactly parent ka "CAPTCHA / proof-of-work" countermeasure.

---

Ex 9 — Exam-style twist: which single fix, and why? (Cell C10)

1. DDoS screen karo. $\lambda T=20\times 60=1200>B=512$? Haan — $1200\ge 512$, toh ye collapse kar dega. Ye step kyun? Pehle threshold test $\lambda T\ge B$ apply karo, kyunki agar server already down hai toh kuch bhi matter nahi karta.

2. Lekin dobara padho: flood hypothetical spoofed SYNs hai — immediate, guaranteed exploits hain constant MAC (trivially replayable, Cell C6/C7) aur plain HTTP (MITM + credential theft, Cell C8). SYN cookies sirf (iii) fix karta hai. Ye step kyun? Exploitability se ranking karo: ek constant auth tag ek guaranteed replay hai jo koi bhi attacker aaj perform kar sakta hai; DDoS ke liye botnet chahiye.

3. [B] TLS with certificates choose karo — ye server ko authenticate karta hai (HTTP par MITM kill karta hai) aur traffic wrap karta hai taki credential sniff na ho sake. Lekin TLS akela application layer par constant MAC fix nahi karta. Ye step kyun? TLS sabse wide hole close karta hai (eavesdrop + MITM + downgrade via HSTS). Ye yahan highest-value single control hai.

4. Kya exposed rehta hai: constant MAC (nonce chahiye — [C]) aur SYN flood (chahiye [A]). Ek control teen independent broken assumptions cover nahi kar sakta — yehi parent ke comparison table ka poora point hai. Ye step kyun? Har attack ek alag assumption todi hai (freshness / identity / resources), isliye koi single fix complete nahi hai.

---

Recall Self-test

Ek server ka $B=2048,T=40$s hai. Kis SYN rate se neeche ye safe hai? ::: $\lambda <B/T=2048/40=51.2$ SYN/s. Ek $50$-byte query se $2500$-byte reply milti hai. $A$ kya hai? ::: $A=2500/50=50$. Timestamp window $\Delta =5$s, message stamped $t=100$, replayed at $t=104$. Accept hua? ::: Haan — $|104-100|=4\le 5$ (yehi replay hole hai). SYN flood defend karne ke liye $B$ badhana — achha idea? ::: Nahi; attacker bas $\lambda$ badhata hai kyunki $\lambda \ge B/T$ phir bhi hold karta hai. SYN cookies use karo ($T\to 0$).