Firewalls — stateless vs stateful packet filtering: Worked examples

4.3.29 · D3 · Coding › Computer Networks › Firewalls — stateless vs stateful packet filtering

Shuru karne se pehle, teen simple-bhasha reminders (koi bhi term isse pehle use nahi karenge):

Hum poori jagah parent ka chhota sa ruleset reuse karte hain:

#	Dir	Proto	Src	Dst	Dst Port	Flag	Action
1	out	TCP	10.0.0.0/24	any	80,443	—	ALLOW
2	in	TCP	any	10.0.0.0/24	>1023	ACK=1	ALLOW
3	`*`	`*`	any	any	any	—	DENY

Hamara internal network hai 10.0.0.0/24 (addresses 10.0.0.0–10.0.0.255).

Scenario matrix

Ek filter jo bhi packet dekhta hai woh in cells mein se kisi ek mein aata hai. Do axes jo matter karte hain woh hain direction (out / in) aur flags + state kya kehte hain. Hum degenerate inputs (empty table, port on boundary) aur limiting behaviour (table full) bhi fold in karte hain.

Cell	Direction	Flag pattern	Legit?	Stateless verdict	Stateful verdict	Covered by
A	out	SYN (ACK=0) new conn	✅	ALLOW (rule 1)	ALLOW + create entry	Ex 1
B	in	SYN-ACK, asli reply hai	✅	ALLOW (rule 2, ACK=1)	ALLOW via table	Ex 2
C	in	ACK=1, koi asli conn nahi (spoof)	❌	ALLOW (leak!)	DROP (not in table)	Ex 3
D	in	SYN (ACK=0), naya inbound conn	❌	DROP (rule 2 needs ACK=1)	DROP	Ex 4
E	in	dst port = 1023 vs 1024 (boundary)	—	rule 2 edge test	same	Ex 5
F	in	ESTABLISHED conn par data	✅	ALLOW (ACK=1)	ALLOW (fast path)	Ex 6
G	close	FIN vs RST tears down	—	ALLOW (if ACK=1)	ALLOW + delete entry	Ex 7
H	in	SYN flood, table full (limiting)	❌	shrugs (no table)	table exhaustion DoS	Ex 8
I	in	active-FTP 2nd channel (word problem)	✅	needs huge port hole	ALG opens 1 port	Ex 9
J	in	UDP DNS reply (no flags!) (exam twist)	✅	rule 2 fails (no ACK)	ALLOW via pseudo-state	Ex 10

Ab hum har cell ke liye ek example kaam karte hain. Directions aur states figures mein draw hain — words se zyada arrows dekho.

Intuition Figure s01 padhna (agar image load na ho)

Figure firewall ko beech mein ek lavender wall ke roop mein draw karta hai: internet left par, protected 10.0.0.0/24 network right par. Coloured boxes packets hain; arrows dikhate hain ki woh cross karne ki koshish kar rahe hain. Green arrows (Cells A, B) aasani se nikal jaate hain — legit browse aur uska reply. Coral boxes (Cell C forged ACK, Cell H SYN flood) danger cases hain: forged-ACK arrow wall par "?" ke saath ruk jaata hai kyunki stateless use leak karta hai jabki stateful drop karta hai, aur flood mein bahut saare coral arrows table bharne ke liye pile up hote dikhte hain. Butter box (Cell D new inbound SYN) dono firewalls block karte hain. Tasveer ka asli message: same-dikhe wale packets (B aur C) ko ulta treatment milta hai jab firewall ke paas memory ho.

Figure — Firewalls — stateless vs stateful packet filtering

Worked examples

Worked example Example 1 — Cell A: outbound SYN ek browse shuru karta hai

Laptop 10.0.0.5:50000 ek SYN (ACK=0) bhejta hai 93.184.216.34:443 ko.

Forecast: kya har firewall ise allow karta hai, aur kuch yaad rakha jaata hai kya? Pehle andaza lagao.

Header padho. Direction = out, proto = TCP, dst port = 443, flag = SYN. Yeh step kyun? Filtering header-first hoti hai; hum classify karte hain pehle, phir decide.
Stateless: rules top-down chalao. Rule 1 match karta hai (out, TCP, dst 443) → ALLOW. Yeh step kyun? Rules ordered hote hain; pehla match jeet jaata hai, toh hum rule 1 par ruk jaate hain.
Stateful: same match → ALLOW, aur woh ek row likhta hai $(10.0.0.5, 93.184.216.34, 50000, 443, TCP, SYN_SENT)$ . Yeh step kyun? "State" ka poora point yahi hai: conversation yaad rakho taaki reply free ho.

Verify: dst port $443 \leq 443$ aur woh allowed set ${80, 443}$ mein hai → rule 1 sach mein match karta hai. Dono firewalls agree karte hain: legit outbound allow hai. ✅

Worked example Example 2 — Cell B: honest reply waapas aata hai

Server answer karta hai 93.184.216.34:443 → 10.0.0.5:50000, ek SYN-ACK (SYN=1, ACK=1).

Forecast: kaun sa rule / table entry ise pakdta hai? Dono boxes par same verdict?

Classify karo. Direction = in, dst = 10.0.0.5 (10.0.0.0/24 ke andar), dst port = 50000, ACK=1. Yeh step kyun? Hume jaanna hai ki yeh inbound hai aur rule 2 ke liye iska destination port check karna hai.
Stateless: rule 1 outbound only hai → skip. Rule 2: in, dst inside net, port $50000 > 1023$ , ACK=1 → ALLOW. Yeh step kyun? ACK bit woh ek hi evidence hai jo ek stateless box ke paas hai ki yeh packet "kisi se belong karta hai" — parent ka ACK trick dekho.
Stateful: Example 1 ka reverse 5-tuple compute karo $(93.184.216.34, 10.0.0.5, 443, 50000, TCP)$ → mila → ALLOW, update to ESTABLISHED. Yeh step kyun? Return traffic outgoing 5-tuple ka mirror hota hai; us mirror ko match karna hi "stateful" ka matlab hai.

Verify: $50000 > 1023$ true, toh rule 2 ka port test pass; reversed tuple ka src port 443 original dst port 443 ke barabar hai, toh mirror line up karta hai. Dono allow karte hain. ✅

Worked example Example 3 — Cell C: attacker ka forged ACK (the leak)

Attacker 66.66.66.66:80 → 10.0.0.5:50000 ACK=1 ke saath, lekin koi handshake kabhi hua hi nahi.

Forecast: Yeh headline difference hai. Padhne se pehle dono verdicts predict karo.

Classify karo. Direction = in, dst inside net, port $50000 > 1023$ , ACK=1. Header akele se Example 2 se bilkul alag nahi dikta. Yeh step kyun? Khatre ki baat yahi hai ki headers sach aur jhooth mein fark nahi bata sakte.
Stateless: rule 2 match karta hai (in, port >1023, ACK=1) → ALLOW — BURA HAI. Yeh step kyun? Ek stateless box flag par trust karta hai; woh nahi pooch sakta "kya maine yeh shuru kiya?"
Stateful: $(66.66.66.66, 10.0.0.5, 80, 50000, TCP)$ lookup karo → absent → DROP — ACHA HAI. Yeh step kyun? Koi yaad rakha 5-tuple nahi ⇒ packet unsolicited hai, chahe koi bhi flag uthaye. Yahi woh ACK-scan probe hai jiske baare mein parent ne bataya tha.

Verify: Forged tuple ka src 66.66.66.66:80 hai; table mein koi row nahi hai jiska destination woh ho. Match ki absence ⇒ drop. Stateless box ke rule-2 conditions sab true hain, toh woh galat tarike se allow karta hai. Verdicts alag hain — bilkul topic ka point. ✅

Worked example Example 4 — Cell D: attacker fresh inbound SYN try karta hai

Attacker 66.66.66.66:40000 → 10.0.0.5:22 SYN (ACK=0) — SSH ke liye naya inbound connection.

Forecast: Kya ACK trick akele hi is case ko rokne ke liye kaafi hai?

Classify karo. Direction = in, ACK=0 (yeh pehla handshake packet hai). Yeh step kyun? SYN-with-ACK=0 bilkul naye connection ki fingerprint hai.
Stateless: rule 1 outbound hai → skip. Rule 2 ko ACK=1 chahiye, lekin yahan ACK=0 hai → no match → rule 3 par jaata hai → DENY. Yeh step kyun? ACK trick ka poora kaam yahi hai: ek naya inbound connection block karna.
Stateful: koi matching entry nahi, aur port 22 ke liye koi explicit inbound-allow rule nahi → DROP. Yeh step kyun? Deny-by-default plus empty table = drop.

Verify: ACK=0, rule 2 ki ACK=1 condition fail karta hai, toh rule 2 match nahi kar sakta; rule 3 sab pakad leta hai → DENY. Dono agree karte hain. Toh is attack ke liye humble ACK trick pehle se hi kaafi hai — Cell C wahan fail hua tha. ✅

Worked example Example 5 — Cell E: port-number boundary

10.0.0.5 ko ACK=1 ke saath do probes: ek dst port 1023 par, ek dst port 1024 par.

Forecast: Rule 2 kehta hai "dst port >1023". Inme se kaun door se nikal jaata hai?

Rule 2 ka test literally padho: dstPort > 1023 (strictly greater). Yeh step kyun? Off-by-one boundaries classic exam trap hain; comparison strict hai.
Port 1023: $1023 > 1023$ false hai → rule 2 fail → rule 3 → DENY.
Port 1024: $1024 > 1023$ true hai → rule 2 match → ALLOW. Yeh step kyun? Ports $\leq 1023$ "well-known" service ports hain; rule deliberately sirf high, ephemeral ports par trust karta hai jahan replies land hoti hain.

Verify: $1023 > 1023 = False$ , $1024 > 1023 = True$ . Exactly ek pass hota hai — boundary design ke according kaam karti hai. Degenerate/edge input handle ho gaya. ✅

Worked example Example 6 — Cell F: established connection par data

Example 2 continue karte hue, server ek HTTPS data segment bhejta hai 93.184.216.34:443 → 10.0.0.5:50000, ACK=1, payload ke saath.

Forecast: Kya stateful box poora rulebook re-run karta hai, ya shortcut leta hai?

Classify karo. In, dst inside net, port 50000, ACK=1, conn ka state = ESTABLISHED. Yeh step kyun? Established-state packets common case hain; speed yahan matter karta hai.
Stateless: rule 2 (ACK=1, port>1023) → ALLOW. Woh har packet par rules re-check karta hai. Yeh step kyun? Memory nahi toh shortcut nahi — har packet par constant kaam.
Stateful: table lookup ESTABLISHED row hit karta hai → fast path par ALLOW, poora rule scan nahi. Yeh step kyun? Ek baar trust ho gaya, table row match karna ek hash lookup hai — poora ACL walk karne se sasta.

Verify: ACK=1 aur $50000 > 1023$ ⇒ rule 2 true (stateless allows); reverse tuple pehle se table mein ⇒ stateful allows. Dono allow karte hain, lekin cost alag hai. ✅

Worked example Example 7 — Cell G: connection tear down karna (FIN vs RST)

Example-2 flow par do teardown scenarios, phir ek late straggler packet. (a) Laptop FIN bhejta hai (ek graceful "main ho gaya", ACK=1). (b) Iske badle, server ek RST bhejta hai (ek abrupt "reset — yeh connection ab nahi hai").

Forecast: Kya FIN aur RST state entry ko same tarike se band karte hain? Late packet ka kya?

FIN path (a): FIN ek polite close hai — TCP normally dono sides par FIN handshake karta hai, toh stateful box row ko CLOSED ki taraf le jaata hai aur final ACKs ke baad (ya ek chhoti timeout ke baad) use hataa deta hai. Yeh step kyun? Graceful close mein phir bhi packets exchange hote hain, toh firewall bhoolne se pehle handshake finish hone ka intezaar karta hai.
RST path (b): RST ek immediate kill hai — RST handshake hota hi nahi, aur RST ACK=0 le ja sakta hai. Stateful box valid RST dekhte hi row turant delete kar deta hai. Yeh step kyun? RST matlab "connection ab exist nahi karta," toh row rakhna galat hoga; RST-specific semantics = instant teardown, FIN ke negotiated close se alag.
Late straggler. Kisi bhi close ke baad, us tuple ke liye ek stray inbound packet aata hai. Stateful: lookup → absent → DROP. Stateless: agar ACK=1 aur port>1023 hai toh ab bhi rule 2 match karta hai → ALLOW — lekin ACK=0 wala akela RST rule 2 fail karega (ACK=1 chahiye) aur DENIED hoga. Yeh step kyun? Straggler ek saath do cheezein dikhata hai: stateful closed flows bhool jaata hai, aur flagless/ACK=0 RST ACK trick ke blind spots reveal karta hai.

Verify: RST-with-ACK=0 rule 2 ki ACK=1 requirement fail karta hai (toh stateless deny karta hai), jabki ACK=1 wala data/FIN packet rule 2 pass karta hai. Stateful koi bhi post-close straggler drop karta hai kyunki row gone hai. FIN = negotiated close, RST = immediate close — alag semantics. ✅

Worked example Example 8 — Cell H (limiting): SYN flood table bhar deta hai

Ek attacker random source IPs se $N = 1, 000, 000$ spoofed SYN packets bhejta hai. State table mein zyada se zyada $C = 500, 000$ half-open entries aa sakti hain.

Forecast: Load mein kaun sa firewall toot ta hai — "smart" wala ya "forgetful" wala?

Har naya SYN ek half-open entry create karta hai (state SYN_SENT) stateful box par. Yeh step kyun? Yaad rakhne ki ek cost hai: memory. Har connection start ek row consume karta hai.
Rows needed vs capacity: $N = 1 0^{6} > C = 5 \times 1 0^{5}$ . Jab $500, 00 1^{va}$ SYN aata hai, table bhar jaati hai → legitimate naye connections record nahi ho sakte → DoS. Yeh step kyun? Finite memory ek hard wall hai; "limiting behaviour" exhaustion hai.
Stateless box: kuch store nahi karta, toh bas har packet par rules apply karta hai aur shrug karta hai. Yeh step kyun? Koi table nahi ⇒ exhaust karne ko kuch nahi; Cell C ki weakness yahan strength ban jaati hai.

Verify: Overflow amount $= N - C = 1, 000, 000 - 500, 000 = 500, 000$ rows jo fit nahi hote ⇒ table full ⇒ stateful vulnerable hai, stateless nahi. Mitigation: SYN cookies / rate limits. ✅ (Denial of Service Attacks dekho.)

Worked example Example 9 — Cell I (word problem): active-mode FTP ka doosra channel

Ek user 203.0.113.9 par active FTP run karta hai. Control channel port 21 par hai; server phir client ke saath ek naya data connection wapas dynamically negotiated port par kholta hai, maan lo 52000.

Forecast: Har firewall data channel ko barn door khulaaye bagair kaise andar aane deta hai?

Problem: data port advance mein pata nahi hota — woh mid-conversation choose hota hai. Yeh step kyun? Static rules traffic se pehle likhe jaate hain; ek dynamic port unhe defeat karta hai.
Stateless: safe rehne ke liye use permanently sab ports $> 1023$ par inbound ALLOW karna hoga — ek bada saara hole (woh basically rule 2 hai, aur Cell C dikhata hai yeh kaise leak karta hai). Yeh step kyun? Memory ke bina, "advance mein port range guess karo" ek hi option hai.
Stateful with an ALG: ek Application-Layer Gateway FTP control channel padhta hai, PORT 52000 command dekha, aur port 52000 ke liye exactly ek temporary inbound pinhole kholta hai, transfer khatam hone par band kar deta hai. Yeh step kyun? State firewall ko react karne deta hai jo protocol karta hai uske according, ~64000 ki jagah 1 port kholta hai.

Verify: Ports khule — stateless: $65535 - 1023 = 64512$ ; stateful-ALG: 1. Ratio $64512 : 1$ security win hai. ✅

Worked example Example 10 — Cell J (exam twist): ek UDP DNS reply mein koi flags nahi hote

Laptop 10.0.0.5:51000 ek DNS query (UDP) 8.8.8.8:53 ko bhejta hai. Reply waapas aata hai 8.8.8.8:53 → 10.0.0.5:51000. UDP mein koi SYN/ACK flags bilkul nahi hote.

Forecast: Rule 2 ka trick ACK=1 par rely karta hai. Kya hota hai jab protocol mein flags hi nahi hain?

UDP connectionless hai — koi handshake nahi, toh "ACK=1" undefined hai. Yeh step kyun? Poora ACK trick TCP assume karta hai; exam twist woh assumption hataa deta hai.
Stateless: rule 2 TCP aur ACK=1 dono chahiye. Ek UDP reply TCP nahi hai aur iske paas ACK bit nahi hai, toh rule 2 match nahi kar sakta → rule 3 par jaata hai → DENY. Legit DNS toot jaata hai! Stateless box par DNS kaam karwane ke liye tumhe ek permanent rule add karna hoga jo inbound UDP src-port 53 ko high ports par allow kare — ek standing hole jo attacker abuse kar sakta hai (spoofed src-port-53 packets). Yeh step kyun? Flag-based tricks simply flagless protocols ke liye exist nahi karti, toh stateless box ko "DNS todho" ya "permanent hole chhodo" mein se ek choose karna padta hai.
Stateful: outbound query par woh ek pseudo-connection row store karta hai $(10.0.0.5, 8.8.8.8, 51000, 53, UDP)$ ek chhoti timeout ke saath; reply ka reverse tuple $(8.8.8.8, 10.0.0.5, 53, 51000, UDP)$ match karta hai → ALLOW, phir row expire ho jaata hai. Koi permanent hole nahi, koi forgery loophole nahi. Yeh step kyun? State flags ke bina bhi kaam karta hai: woh tuple yaad rakhta hai, bit nahi — toh UDP utni hi cleanly handle hota hai jitna TCP.

Verify: UDP reply mein ACK undefined hai aur proto ≠ TCP ⇒ rule 2 (TCP + ACK=1 chahiye) match nahi kar sakta ⇒ stateless deny karta hai (ya permanent hole chahiye). Reverse UDP tuple pseudo-state table mein present hai ⇒ stateful allow karta hai. Yahi wajah hai ki real stateless rulesets mein ugly permanent UDP holes hote hain jabki stateful firewalls UDP ko cleanly handle karte hain. ✅

Recall Cover check — har cell ke liye ek line

Cell C: forged ACK=1 packet par stateless ka verdict? ::: ALLOW (the leak) — stateful DROP karta hai. Cell E: kya dst port 1023 rule 2 ka >1023 test pass karta hai? ::: Nahi — strictly greater, toh DENY. Cell G: RST teardown FIN se kaise alag hota hai? ::: RST turant band karta hai (koi handshake nahi, ACK=0 ho sakta hai); FIN negotiated close hai. Cell H: SYN flood kaun sa firewall exhaust karta hai? ::: Stateful wala (uski table bhar jaati hai); stateless shrug karta hai. Cell J: rule 2 UDP DNS reply ke liye kyun fail karta hai? ::: UDP mein ACK flag nahi hota (aur woh TCP bhi nahi hai), toh ACK trick match nahi kar sakti.