🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🧍 धडा 06 — Security groups विरुद्ध NACLs: पाहुण्यांची यादी आणि wing चे दार

📍 तुम्ही इथे आहात: 12 पैकी धडा 06 · मागे: lesson-05-igw-public · पुढे: lesson-07-endpoints

📦 या ब्रँचमध्ये काय आहे

धडे 01–05, आणि campus च्या आत प्रत्येक packet ला भेटणारे दोन रक्षक: vpc/network.py मधील SG (desk वरची पाहुण्यांची यादी — stateful) आणि NACL (wing चे दार — stateless, क्रमांकित). vpc/demo.py मधील guards() तीन packets दोन्हींमधून पायरी-पायरीने चालवतो.

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

प्रत्येक desk वर पाहुण्यांची यादी 🧍 घेऊन एक मॉनिटर बसलेली असते — हा security group. यादीत फक्त कोण आत येऊ शकते तेच लिहिलेले असते: "app wing मधल्या शिक्षिका, खोली 5432 साठी". तिची स्मरणशक्ती परिपूर्ण आहे: तिने एखाद्याला आत सोडले, तर त्याचे उत्तर कोणताही प्रश्न न विचारता परत बाहेर जाऊ शकते. ती कधीच "चालते व्हा" असे ओरडत नाही — अनोळखी व्यक्तीकडे फक्त दुर्लक्ष केले जाते.

प्रत्येक wing ला क्रमांकित नियमांचा फलक असलेले एक दार 🚦 असते — हा network ACL. ते आत येणाऱ्यांना आणि बाहेर जाणाऱ्यांना तपासते, नियम सर्वात लहान नंबरपासून वर वाचते, आणि जुळणारा पहिला नियम निर्णय देतो — allow किंवा deny. त्याला स्मरणशक्ती अजिबात नाही. जेव्हा उत्तर बाहेर जाते, तेव्हा दार ते अनोळखी असल्यासारखे तपासते. उत्तरांना बाहेर सोडणारा एकही नियम नसेल, तर उत्तर अडवले जाते, आणि पाहुणा कायमचा वाट पाहत राहतो.

एका wing मधून दुसऱ्या wing कडे जाणारा packet असा जातो: स्वतःची पाहुण्यांची यादी (बाहेर) → स्वतःच्या wing चे दार (बाहेर) → corridor ची पाटी → दुसऱ्या wing चे दार (आत) → दुसऱ्या desk ची पाहुण्यांची यादी (आत).

🗺️ आकृती

flowchart LR
    web["🖥️ web 10.20.0.10"]
    s1["🧍 sg-web out ✓"]
    n1["🚦 acl-open rule 100 ALLOW"]
    rt["🪧 rt-public: 10.20.0.0/16 → local"]
    n2["🚦 acl-data rule 110 ALLOW<br/>(1024–65535 from anywhere)"]
    s2["⛔ sg-db in<br/>only 10.20.48.0/20 on the list"]
    web -->|"1"| s1 -->|"2"| n1 -->|"3"| rt -->|"4"| n2 -->|"5"| s2

🗺️ काढलेली आकृती + एक lab: https://school-edh.pages.dev/vpc/lesson-diagrams.html#l06

❓ काय

Security group (SG) — network interface ला जोडलेला (म्हणजे instance, load balancer, database ला). फक्त allow नियम — deny लिहिता येत नाही. Stateful: परवानगी मिळालेल्या request चे उत्तर आपोआप जाऊ दिले जाते. नवा SG आत काहीच नाही आणि बाहेर सगळे allow करतो. नियमाचा source एखादा CIDR किंवा दुसरा security group असू शकतो — "sg-app घातलेला कोणीही" — जो servers येत-जात राहिले तरी चालत राहतो.
Network ACL (NACL) — subnet ला जोडलेला. allow आणि deny असलेले क्रमांकित नियम, सर्वात लहान नंबर आधी तपासले जातात; पहिला जुळणारा निर्णय देतो; शेवटचा * नियम बाकी सगळे deny करतो. Stateless: inbound आणि outbound वेगवेगळे तपासले जातात, म्हणून उत्तरांना स्वतःचा नियम लागतो — सहसा ephemeral ports 1024–65535.
Default विरुद्ध custom NACL — VPC चा default NACL आत आणि बाहेर सगळे traffic allow करतो. नवा custom NACL तुम्ही नियम जोडेपर्यंत सगळे deny करतो.
व्याप्ती — NACL subnet च्या सीमेचे रक्षण करतो; एकाच subnet मधल्या दोन desks मधले traffic त्यातून जात नाही. SG प्रत्येक interface चे रक्षण करतो.
Drop विरुद्ध refused — SG किंवा NACL ने केलेला drop timeout सारखा दिसतो. "Connection refused" म्हणजे packet पोहोचला पण तिथे कोणी ऐकत नव्हते.

🤔 का

कारण ते उलट पद्धतीने चुकतात. Security groups हे मुख्य साधन — नेमके, stateful, समजायला सोपे — आणि जास्तच उघडे करायलाही सोपे. NACLs बोथट, पूर्ण subnet साठी, आणि चुकायला सोपे: उत्तरासाठीचा नियम नसला की connections कुठेही error न देता लटकून राहतात. बहुतेक teams सगळ्यासाठी SGs वापरतात आणि NACLs फक्त काही subnet-wide denies साठी.

🔧 कसे (या repo मध्ये)

SG.allows(rules, proto, port, ip) कोणताही नियम जुळला तर true परत करतो — deny नाहीच. NACL.__init__ नियम नंबरप्रमाणे लावतो; NACL.check() पहिला जुळणारा (allowed, "acl-… rule N ALLOW|DENY") म्हणून, किंवा "final * DENY" परत करतो. Campus.walk() source SG आणि NACL outbound, route, आणि मग destination NACL आणि SG inbound तपासतो. तो request तपासतो, उत्तर नाही — खालचा snippet उत्तर हाताने तपासतो.

Demo मधला acl-data नीट पाहा: नियम 100 app wing मधून 5432 आत येऊ देतो, आणि नियम 110 कुठूनही 1024–65535 आत येऊ देतो (उत्तरांसाठी ठेवलेला). Port 5432 हा 1024–65535 च्या आत आहे, म्हणून नियम 110 web ची request सुद्धा दारातून सोडतो — फक्त पाहुण्यांची यादीच ती थांबवते. उत्तरे allow करावी लागणारे stateless दार अनेकदा तुम्हाला वाटते त्यापेक्षा जास्त उघडे असते.

🧪 करून पाहा

python3 vpc/demo.py guards
python3 - <<'EOF'
import sys; sys.path.insert(0, "vpc"); from network import SG, NACL
from demo import campus
c = campus()
# 1) put the public wing on db's guest list
c.sgs["sg-db"] = SG("sg-db", [("tcp", (5432, 5432), "10.20.48.0/20"), ("tcp", (5432, 5432), "10.20.0.0/20")])
print("web → db, SG widened:", c.walk("web", "10.20.96.15", "tcp", 5432)[1][-2:])
# 2) a data-wing door with a numbered DENY for the public wing, before the allows
c.nacls["acl-data"] = NACL("acl-data",
    [(90, "deny", "all", (0, 65535), "10.20.0.0/20"), (100, "allow", "tcp", (5432, 5432), "10.20.48.0/20"), (110, "allow", "tcp", (1024, 65535), "0.0.0.0/0")],
    [(100, "allow", "tcp", (1024, 65535), "10.20.0.0/16")])
print("web → db, NACL rule 90:", c.walk("web", "10.20.96.15", "tcp", 5432)[1][-1])
print("app → db still:        ", c.walk("app", "10.20.96.15", "tcp", 5432)[0])
# 3) the reply: db answers app on its ephemeral port — the data wing's OUTBOUND rules decide
acl = c.nacls["acl-data"]
print("reply out to 51514:", acl.check(acl.outbound, "tcp", 51514, "10.20.48.25"))
no_reply = NACL("acl-data", acl.inbound, [])
print("no outbound rules: ", no_reply.check(no_reply.outbound, "tcp", 51514, "10.20.48.25"))
EOF

✅ तपासा — तुम्हाला काय दिसायला हवे

guards web → 10.20.48.25:8080 ✅ आणि app → 10.20.96.15:5432 ✅ छापतो, आणि मग:

   web → 10.20.96.15:5432  🚫
        🧍 sg-web out ✓
        🚦 acl-open rule 100 ALLOW
        🪧 rt-public: 10.20.0.0/16 → local
        🚦 acl-data rule 110 ALLOW (destination subnet, in)
        ⛔ sg-db in — not on the guest list

तुमचा snippet छापतो:

web → db, SG widened: ['🚦 acl-data rule 110 ALLOW (destination subnet, in)', '🧍 sg-db in ✓']
web → db, NACL rule 90: ⛔ acl-data rule 90 DENY (destination subnet, in)
app → db still:         True
reply out to 51514: (True, 'acl-data rule 100 ALLOW')
no outbound rules:  (False, 'acl-data final * DENY')

🏁 तुम्ही आत्ताच काय सिद्ध केले

तुम्ही प्रत्येक packet चे भाकीत केले: पाहुण्यांची यादी प्रत्येक desk साठी निर्णय देते आणि उत्तरे लक्षात ठेवते; wing चे दार सर्वात लहान नंबरपासून वर वाचते, deny करू शकते, आणि विसरते — म्हणून outbound नियम नसलेले उत्तर शेवटच्या * वर मरते.

⚠️ नेहमीच्या चुका

outbound ephemeral-port नियम नसलेला custom NACL — requests पोहोचतात, उत्तरे मरतात, pages लटकतात
ज्या ALLOW ला हरवायचे होते त्याच्या नंतरचा नंबर दिलेला DENY नियम
"कुठूनही ephemeral ports" असा inbound नियम, जो 5432, 3306, 8080… सुद्धा उघडतो
SG reference पुरेसा असताना CIDR नियम ("sg-app मधून 5432")
"सुरक्षेसाठी" प्रत्येक SG नियम NACLs मध्ये copy करणे — दुप्पट नियम, दुप्पट चुका
22 किंवा 3389 हे 0.0.0.0/0 साठी उघडे

🏭 प्रत्यक्ष वापरात

नेहमीची रचना: load balancer चा SG internet वरून 443 घेतो, app SG फक्त load balancer च्या SG कडून traffic घेतो, database SG फक्त app SG कडून 5432 घेतो. Subnet-wide block लागल्याशिवाय NACLs default वरच राहतात.

खऱ्या account वर (AWS CLI आणि credentials लागतात; IDs उदाहरणादाखल आहेत):

aws ec2 authorize-security-group-ingress --group-id sg-0db0000000000000a \
    --protocol tcp --port 5432 --source-group sg-0app000000000000a
aws ec2 create-network-acl-entry --network-acl-id acl-0123456789abcdef0 --ingress --rule-number 90 \
    --protocol -1 --cidr-block 10.20.0.0/20 --rule-action deny
aws ec2 create-network-acl-entry --network-acl-id acl-0123456789abcdef0 --egress --rule-number 100 \
    --protocol tcp --port-range From=1024,To=65535 --cidr-block 10.20.0.0/16 --rule-action allow

हाच SG नियम Terraform मध्ये:

resource "aws_vpc_security_group_ingress_rule" "db_from_app" {
  security_group_id            = aws_security_group.db.id
  referenced_security_group_id = aws_security_group.app.id
  ip_protocol                  = "tcp"
  from_port                    = 5432
  to_port                      = 5432
}

⏭️ पुढे

भाग 1 पूर्ण झाला: तुम्ही campus बांधला. भाग 2 तो जोडतो — सर्वात आधी AWS शीच. Private wing दरवाजातून न जाता S3 पर्यंत कसा पोहोचतो? VPC endpoints — एक खाजगी बोगदा.

git checkout lesson-07-endpoints

🧍 Lesson 06 — Security groups vs NACLs: the guest list and the wing door

📍 You are here: Lesson 06 of 12 · Previous: lesson-05-igw-public · Next: lesson-07-endpoints

📦 What's in this branch

Lessons 01–05, plus the two guards every packet meets inside the campus: SG (the guest list at the desk — stateful) and NACL (the wing door — stateless, numbered) in vpc/network.py. guards() in vpc/demo.py walks three packets through both, step by step.

🧒 Explain like I'm 5

Every desk has a monitor with a guest list 🧍 — the security group. The list only says who may come in: "teachers from the app wing, for room 5432". It has a perfect memory: if it let someone in, their answer may walk back out, no questions asked. It never shouts "go away" — a stranger is simply ignored.

Every wing has a door 🚦 with a numbered rule board — the network ACL. It checks people walking in and people walking out, reads the rules from the lowest number up, and the first rule that matches decides — allow or deny. It has no memory. When an answer walks out, the door checks it like a stranger. If no rule lets answers out, the answer is stopped, and the visitor waits forever.

A packet from one wing to another passes: its own guest list out → its own wing door out → the corridor sign → the other wing's door in → the other desk's guest list in.

🗺️ Diagram

flowchart LR
    web["🖥️ web 10.20.0.10"]
    s1["🧍 sg-web out ✓"]
    n1["🚦 acl-open rule 100 ALLOW"]
    rt["🪧 rt-public: 10.20.0.0/16 → local"]
    n2["🚦 acl-data rule 110 ALLOW<br/>(1024–65535 from anywhere)"]
    s2["⛔ sg-db in<br/>only 10.20.48.0/20 on the list"]
    web -->|"1"| s1 -->|"2"| n1 -->|"3"| rt -->|"4"| n2 -->|"5"| s2

🗺️ Drawn version + a lab: https://school-edh.pages.dev/vpc/lesson-diagrams.html#l06

❓ What

Security group (SG) — attached to a network interface (so to an instance, a load balancer, a database). Allow rules only — you cannot write a deny. Stateful: the reply to an allowed request is allowed automatically. A new SG allows nothing in and everything out. A rule's source can be a CIDR or another security group — "anyone wearing sg-app" — which keeps working as servers come and go.
Network ACL (NACL) — attached to a subnet. Numbered rules with allow and deny, checked lowest number first; the first match decides; a final * rule denies everything else. Stateless: inbound and outbound are checked separately, so replies need their own rule — usually the ephemeral ports 1024–65535.
Default vs custom NACL — the VPC's default NACL allows all traffic in and out. A new custom NACL denies all until you add rules.
Scope — a NACL guards the subnet boundary; traffic between two desks in the same subnet does not pass it. An SG guards each interface.
Dropped vs refused — a drop by an SG or NACL looks like a timeout. "Connection refused" means the packet arrived and nothing was listening.

🤔 Why

Because they fail in opposite ways. Security groups are the main tool — precise, stateful, easy to reason about — and easy to open too wide. NACLs are blunt, subnet-wide, and easy to get wrong: a missing reply rule makes connections hang with no error anywhere. Most teams use SGs for everything and NACLs only for a few subnet-wide denies.

🔧 How (in this repo)

SG.allows(rules, proto, port, ip) returns true if any rule matches — there is no deny. NACL.__init__ sorts the rules by number; NACL.check() returns the first match as (allowed, "acl-… rule N ALLOW|DENY"), or "final * DENY". Campus.walk() checks the source SG and NACL outbound, the route, then the destination NACL and SG inbound. It checks the request, not the reply — the snippet below checks the reply by hand.

Look closely at the demo's acl-data: rule 100 lets 5432 in from the app wing, and rule 110 lets 1024–65535 in from anywhere (meant for replies). Port 5432 is inside 1024–65535, so rule 110 also lets web's request through the door — only the guest list stops it. A stateless door that must allow replies is often wider than you think.

🧪 Try it

python3 vpc/demo.py guards
python3 - <<'EOF'
import sys; sys.path.insert(0, "vpc"); from network import SG, NACL
from demo import campus
c = campus()
# 1) put the public wing on db's guest list
c.sgs["sg-db"] = SG("sg-db", [("tcp", (5432, 5432), "10.20.48.0/20"), ("tcp", (5432, 5432), "10.20.0.0/20")])
print("web → db, SG widened:", c.walk("web", "10.20.96.15", "tcp", 5432)[1][-2:])
# 2) a data-wing door with a numbered DENY for the public wing, before the allows
c.nacls["acl-data"] = NACL("acl-data",
    [(90, "deny", "all", (0, 65535), "10.20.0.0/20"), (100, "allow", "tcp", (5432, 5432), "10.20.48.0/20"), (110, "allow", "tcp", (1024, 65535), "0.0.0.0/0")],
    [(100, "allow", "tcp", (1024, 65535), "10.20.0.0/16")])
print("web → db, NACL rule 90:", c.walk("web", "10.20.96.15", "tcp", 5432)[1][-1])
print("app → db still:        ", c.walk("app", "10.20.96.15", "tcp", 5432)[0])
# 3) the reply: db answers app on its ephemeral port — the data wing's OUTBOUND rules decide
acl = c.nacls["acl-data"]
print("reply out to 51514:", acl.check(acl.outbound, "tcp", 51514, "10.20.48.25"))
no_reply = NACL("acl-data", acl.inbound, [])
print("no outbound rules: ", no_reply.check(no_reply.outbound, "tcp", 51514, "10.20.48.25"))
EOF

✅ Verify — what you should see

guards prints web → 10.20.48.25:8080 ✅ and app → 10.20.96.15:5432 ✅, then:

   web → 10.20.96.15:5432  🚫
        🧍 sg-web out ✓
        🚦 acl-open rule 100 ALLOW
        🪧 rt-public: 10.20.0.0/16 → local
        🚦 acl-data rule 110 ALLOW (destination subnet, in)
        ⛔ sg-db in — not on the guest list

Your snippet prints:

web → db, SG widened: ['🚦 acl-data rule 110 ALLOW (destination subnet, in)', '🧍 sg-db in ✓']
web → db, NACL rule 90: ⛔ acl-data rule 90 DENY (destination subnet, in)
app → db still:         True
reply out to 51514: (True, 'acl-data rule 100 ALLOW')
no outbound rules:  (False, 'acl-data final * DENY')

🏁 What you just proved

You predicted every packet: the guest list decides per desk and remembers replies; the wing door reads numbers from the lowest up, can deny, and forgets — so a reply with no outbound rule dies at the final *.

⚠️ Common mistakes

a custom NACL with no outbound ephemeral-port rule — requests arrive, replies die, pages hang
a DENY rule numbered after the ALLOW it was meant to beat
an "ephemeral ports from anywhere" inbound rule that also opens 5432, 3306, 8080…
CIDR rules where an SG reference would do ("5432 from sg-app")
copying every SG rule into NACLs "for safety" — twice the rules, twice the mistakes
22 or 3389 open to 0.0.0.0/0

🏭 In production

The standard shape: the load balancer's SG takes 443 from the internet, the app SG takes traffic only from the load balancer's SG, the database SG takes 5432 only from the app SG. NACLs stay at the default unless you need a subnet-wide block.

On a real account (needs the AWS CLI and credentials; IDs are examples):

aws ec2 authorize-security-group-ingress --group-id sg-0db0000000000000a \
    --protocol tcp --port 5432 --source-group sg-0app000000000000a
aws ec2 create-network-acl-entry --network-acl-id acl-0123456789abcdef0 --ingress --rule-number 90 \
    --protocol -1 --cidr-block 10.20.0.0/20 --rule-action deny
aws ec2 create-network-acl-entry --network-acl-id acl-0123456789abcdef0 --egress --rule-number 100 \
    --protocol tcp --port-range From=1024,To=65535 --cidr-block 10.20.0.0/16 --rule-action allow

The same SG rule in Terraform:

resource "aws_vpc_security_group_ingress_rule" "db_from_app" {
  security_group_id            = aws_security_group.db.id
  referenced_security_group_id = aws_security_group.app.id
  ip_protocol                  = "tcp"
  from_port                    = 5432
  to_port                      = 5432
}

⏭️ Next

Part 1 is done: you built a campus. Part 2 connects it — first to AWS itself. How does a private wing reach S3 without going through the gate? VPC endpoints — a private tunnel.

git checkout lesson-07-endpoints

← Previousigw public Next →endpoints

This page is the lesson's README from the lesson-06-sg-vs-nacl branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.