Firewalls — stateless vs stateful packet filtering: Visual walkthrough

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

Step 1 — Packet kya hota hai, aur firewall asliyat mein kya dekhta hai?

KYA. Ek packet data ka ek chota sa envelope hota hai jo network ke across travel karta hai. Ek asli envelope ki tarah, iske bahar kuch likha hota hai (header) aur andar ek message hota hai (payload). Ek packet-filtering firewall sirf bahar ki likhavat padhta hai.

KYU. Bahar padhna fast aur sasta hota hai — firewall ko kabhi letter kholna nahi padta. Likhavat ke woh chaar tukde jo ise important lagte hain bilkul wohi hain jo parent note ki table mein the: do addresses (kisne bheja, kiske liye hai), protocol, do ports, aur — TCP ke liye — flags.

PICTURE. Envelope dekho. Burnt-orange band woh header hai jo firewall padhta hai; andar ka pale hissa woh payload hai jise woh ignore karta hai.

Figure — Firewalls — stateless vs stateful packet filtering

Step 2 — 5-tuple: ek connection ka fingerprint

KYA. Header se paanch fields uthao aur unhe saath staple karo. Woh bundle hi 5-tuple hai — ek single label jo ek specific conversation ko naam deta hai:

$who sent it (srcIP, who it’s for dstIP, sender’s apartment srcPort, receiver’s apartment dstPort, TCP or UDP proto)$

Har symbol ke neeche ka label batata hai ki woh symbol kya kar raha hai: do IPs buildings hain, do ports apartments hain, protocol language hai.

KYU. Humhe ek aisa handle chahiye jo matlab ho "yahi browsing session aur koi nahi." Agar tumhara laptop same server par do tabs kholta hai, toh srcPort alag hoga, isliye do 5-tuples alag honge — firewall unhe alag kar sakta hai. Yahi woh atom hai jis par baaki sab kuch bana hai.

PICTURE. Do machines, unke beech ek arrow, aur paanch fields uthaye hue aur fingerprint ke roop mein box mein rakhe hue.

Step 3 — Stateless decision: ek packet, koi memory nahi

KYA. Ek stateless filter har packet ko rules ki ek ordered list mein se chalata hai aur pehla match lene wala result leta hai. Ek decision ke roop mein likha gaya:

$decision (p) = firstMatch (p . header, ruleList)$

Yahan $p$ yeh packet hai, $p . header$ Step 1 ki likhavat hai, aur $firstMatch$ ka matlab hai "list ko upar se neeche chalo, pehle rule par ruko jiska saari conditions fit hoti hain." Dhyan do kya absent hai: past packets ke liye koi term nahi. Woh absence hi "stateless" ka poora matlab hai.

KYU. Simplicity aur speed. Koi memory store nahi karni, kuch look up nahi karna — bas header fields ko constants se compare karo. Yahi woh hai jo routers par Access Control Lists (ACLs) itne fast banata hai.

PICTURE. Ek packet rules ki ek stack mein girta hai; pehla matching rung fire hota hai aur neeche ka sab kuch skip ho jata hai.

Formula Parent ka ruleset, dobara bataya gaya

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

Rule 3 deny-by-default hai: agar upar kuch match nahi hua, toh drop karo.

Step 4 — Return-traffic ki problem, aur ACK trick

KYA. Tum ek request bahar bhejte ho; reply andar aata hai. Stateless filter ko koi memory nahi ki tumne chat start ki thi, isliye use inbound reply ke baare mein sirf header se decide karna hota hai. Trick: inbound TCP tabhi allow karo jab $ACK = 1$ ho.

KYU. TCP Three-Way Handshake yaad karo. Kisi bhi nayi connection ka sabse pehla packet ek akela SYN hota hai jisme $ACK = 0$ hota hai. Uske baad ka har packet $ACK = 1$ carry karta hai. Toh:

$ACK = 1 \Rightarrow "yeh kisi nayi conversation ka pehla packet nahi hai"$

Arrow padhta hai: agar ACK bit set hai, toh (umeed hai) yeh kisi already-going cheez se belong karta hai. "Inbound allow karo sirf agar $ACK = 1$ hai" isliye replies ko pass hone deta hai jabki attacker ke opening SYN ko block karta hai.

PICTURE. Do timelines side by side: ek asli reply (ACK=1, pass ho jata hai) aur ek stranger ka opening SYN (ACK=0, ACK=1 ki zaroorat se block).

Step 5 — Woh edge case jo trick tod deta hai: spoofed ACK

KYA. Ek attacker haath se ek packet banata hai jisme $ACK = 1$ hota hai lekin jo kisi asli connection se belong nahi karta — usne kabhi handshake nahi kiya. Yeh ek ACK scan / spoofed probe hai.

KYU woh slip through karta hai. Stateless filter ka sirf ek test hai woh flag. Forged packet mein $ACK = 1$ dikhta hai, rule 2 se match karta hai, aur allowed ho jata hai. Filter yeh nahi pooch sakta "kya maine kabhi woh SYN dekha jo tumhe start kiya?" — kyunki usse kuch yaad nahi rehta. Yeh woh degenerate case hai jiske baare mein parent note ne warn kiya tha, aur yeh probe/scan ka beej hai.

PICTURE. ACK bit ticked ke saath ek red forged packet stateless door ke seedha past chala jata hai — uske peeche koi handshake nahi.

Step 6 — Memory add karna: state table

KYA. Firewall ko ek notebook do: state table. Har baar jab ek outbound packet ko connection start karne ki permission milti hai, uska 5-tuple aur uski phase likh do:

$StateTable = {(5-tuple, tcpState), \dots}$

Har row ek live conversation hai. $tcpState$ phases mein chalti hai — $SYN_SENT \to ESTABLISHED \to closed$ — TCP Three-Way Handshake ko mirror karte hue.

KYU. Ab return-traffic ka sawaal guess nahi raha. Ek flag par trust karne ki jagah, firewall reverse 5-tuple (src↔dst, srcPort↔dstPort swap karo) look up karta hai aur poochta hai: kya yeh row meri notebook mein hai?

PICTURE. Notebook: outbound SYN ek row likhta hai; arrow dikhata hai state aage badhti hai jab handshake complete hota hai.

Step 7 — Stateful decision, aur kyun yeh trick ko beat karta hai

KYA. Stateful return rule ek single, honest test mein collapse ho jaata hai:

$allow (p) ⟺ main tumhe yaad karta hoon p \in StateTable \lor policy tumhe start karne deti hai matchesExplicitAllow (p)$

Left branch ka matlab hai "reverse 5-tuple meri notebook mein ek row hai." Right branch ordinary policy hai nayi allowed flows shuru karne ke liye. Koi fragile ACK check nahi kahin bhi.

KYU yeh spoof ko khatam karta hai. Step 5 ka attacker ka forged ACK daalo. Uska 5-tuple table mein nahi hai (koi handshake ne kabhi use likha nahi), aur woh kisi explicit ALLOW se match nahi karta → DROP. Firewall ne "kya maine kabhi tumhara SYN dekha?" ka jawab sachchi tarah se "nahi" mein diya.

PICTURE. Wohi teen packets — legit reply, forged ACK, data packet — har ek notebook ke against query kiya gaya: do mile (ALLOW), ek absent (DROP).

Worked example Teeno trace karo, dono firewalls mein

Packet	Stateless verdict	Stateful verdict
Server ka real SYN-ACK reply (ACK=1)	ALLOW (rule 2) ✅	ALLOW (row found) ✅
Attacker ka forged ACK (no handshake)	ALLOW (rule 2) ❌	DROP (no row) ✅
Tumhare session ka baad ka data packet	ALLOW (rule 2) ✅	ALLOW (ESTABLISHED) ✅

Beech wali row hi poora point hai: same flag, ulta — aur sahi — verdict.

Step 8 — Stateful firewall ki apni kamzori: state exhaustion

KYA. Notebook finite hai. Ek attacker tumhe lakhon opening SYNs ki flood karta hai (ek SYN flood), jinmein se har ek ek half-open $SYN_SENT$ row create karta hai jo kabhi complete nahi hoti.

KYU yeh Step 5 ka mirror image hai. Stateless firewalls ke paas koi table nahi hoti, isliye unhe exhaust nahi kiya ja sakta — woh SYN flood se shrug off karte hain. Stateful firewalls security memory rakh ke gain karte hain, aur wohi memory woh resource hai jise attacker bharta hai. Security aur vulnerability bilkul usi same feature se aati hain. (Firewall ke against ek DoS.)

PICTURE. Half-open $SYN_SENT$ rows se notebook overflow ho rahi hai; legitimate rows ab add nahi ho sakti.

Ek-picture summary

Upar sab kuch ek canvas par: ek outbound SYN ek row likhta hai (memory janam leti hai); real reply aur baad ka data match hote hain aur allow hote hain; forged ACK ko koi row nahi milti aur woh mar jaata hai; aur half-open rows ki flood stateful box ki Achilles' heel hai.

Recall Feynman retelling — poora walkthrough simple words mein

Ek packet ek envelope hai; firewall sirf label padhta hai (Step 1). Us label se paanch fields staple karo aur tumhe ek fingerprint milta hai jo ek exact conversation ko naam deta hai (Step 2). Ek bhoolne wala guard har envelope ko rules ki ek list ke against check karta hai, upar se neeche, pehla match wins — bilkul koi memory nahi (Step 3). Takleef: tumhare replies andar aate hain, aur bina memory ke use ek flag par trust karna padta hai — "andar aane do agar ACK bit set hai," kyunki asli replies hamesha iske saath hote hain aur ek stranger ki pehli knock mein nahi hoti (Step 4). Lekin koi bhi ek fake envelope par ACK bit paint kar sakta hai, aur bhoolne wala guard use through wave karta hai (Step 5). Toh hum guard ko ek notebook dete hain: har baar jab woh koi conversation bahar jane deta hai, woh use likh leta hai (Step 6). Ab reply rule honest hai — "andar aane do sirf agar woh meri notebook mein hai" — aur paint-on ACK, koi page na hone ki wajah se, wapas bhejna paata hai (Step 7). Pakad yeh hai: notebook mein finite pages hain, isliye fake half-started conversations ki ek mob use bhar ke jam kar sakti hai — bhoolne wala guard, koi notebook na hone ki wajah se, is tarah jam nahi ho sakta (Step 8). Memory hi uski strength bhi hai aur uski weakness bhi.

Recall Quick self-test

Ek filter ko "stateless" kya banata hai? ::: Uska decision sirf current packet ke header aur rule list ka use karta hai — past packets ki koi memory nahi. "Inbound allow karo agar ACK=1 hai" leak kyun karta hai? ::: Ek attacker ACK=1 ke saath ek packet forge kar sakta hai jo kisi asli connection se belong nahi karta; flag akele ek flow mein membership prove nahi kar sakta. Stateful filter us forged ACK ko kaise reject karta hai? ::: Woh 5-tuple reverse karta hai, state table search karta hai, koi matching row nahi milti, aur drop kar deta hai. Kaun sa firewall SYN flood ke liye vulnerable hai, aur kyun? ::: Stateful — har half-open SYN ek table row create karta hai, isliye lakhon SYNs uski finite memory exhaust kar dete hain. Wohi stateless box us SYN flood ko kyun shrug off karta hai? ::: Woh per-connection state nahi rakhta, isliye exhaust karne ke liye koi table hi nahi hai.