hack3rs.ca network-security

/learning/subnetting-nat-firewall-policy-segmentation :: module-2

student@hack3rs:~/learning$ open subnetting-nat-firewall-policy-segmentation

Subnetting, NAT, Firewall Policy Logic, and Segmentation Basics

Subnetting and firewall policy design are not just routing concerns — they are the structural controls that determine how far an attacker can move once they are inside. This module turns address planning, policy boundaries, and segmentation from routing afterthoughts into defensive controls.

A flat network with broad implicit trust makes every downstream security control harder to operate. When users, servers, admin systems, and guest devices all share the same broadcast domain and can reach each other freely, incident scoping becomes guesswork and lateral movement is trivial. Segmentation limits blast radius. Clear firewall policy turns unexpected traffic into a high-confidence alert instead of background noise.

learning-objectives

$Calculate subnets and understand host ranges, broadcast domains, and route summaries.
$Explain source NAT, destination NAT, and port forwarding in plain operational terms.
$Read firewall policies in the correct order and predict packet outcomes.
$Design basic segmentation zones for users, servers, admin access, and management planes.

example-dataflow-and-observation-paths

Trace each step and identify which log or capture point gives you evidence at that stage. Most triage mistakes happen when someone skips a hop and draws conclusions from an incomplete picture.

$Host in 10.10.20.0/24 sends a packet to 10.10.30.5 -> default gateway receives it -> route table selects the correct interface -> firewall evaluates source zone / dest zone / dest port -> NAT rewrites the source address if the rule applies -> destination host sees the translated source, not the original.
$To validate a new firewall rule: send a test connection from the source zone -> watch the firewall hit counter on the intended rule -> check the destination service log for the arrival -> confirm the deny log is empty for traffic that should be blocked.
$When a subnet is modified: update the IP plan -> push the route change -> run `ip route show` on affected hosts -> test reachability with `nc -vz` -> check firewall logs confirm the correct rule is matching.

baseline-normal-before-debugging

$Every allowed cross-zone connection matches exactly one firewall rule; the hit counter on that rule increments during a validation test.
$The output of `ip route show` lists only the subnets documented in the IP address plan with the correct gateway.
$NAT translation table entries match the expected source addresses on each side of the boundary when compared across firewall and host logs.

Expert tip: Record what normal looks like in your actual environment before you test any edge case. A baseline you measured beats a baseline you assumed every time.

concept-breakdown-and-mastery

1. Subnetting for Security and Operations

$ core idea: Subnetting shapes broadcast scope, route design, ACL readability, and how quickly you can isolate a compromised segment. Clear subnet boundaries make incident scoping faster. When an alert fires on a host in 10.10.20.0/24 and your naming standard tells you that is the server VLAN, you know the immediate blast radius before you even pull a log.

$ defender angle: SIEM alerts and firewall rules reference IP ranges constantly, not hostnames. Misreading a /26 as a /24 leads to triage errors. Comfortable CIDR arithmetic is a practical skill, not just exam prep.

$ prove understanding: Calculate subnets and understand host ranges, broadcast domains, and route summaries.

2. NAT and the Security Interpretation Problem

$ core idea: NAT changes packet source or destination addresses in transit. That is useful for address conservation and exposure control, but it creates investigation problems. The IP in a firewall log may not be the IP the endpoint or server recorded. Correlating pre-NAT and post-NAT views across firewall, endpoint, and application logs is a skill incident responders need every week.

$ defender angle: Source NAT handles outbound traffic; destination NAT and port forwarding publish internal services externally. Both require explicit documentation of address translation rules so analysts can follow a connection across log sources without losing the thread.

$ prove understanding: Explain source NAT, destination NAT, and port forwarding in plain operational terms.

3. Firewall Policy Logic and Segmentation Strategy

$ core idea: Most firewall failures are policy design problems, not product problems. A small set of explicit, intentional rules with a clear implicit-deny default is far safer than a pile of accumulated exceptions nobody remembers adding. Learn rule order, object groups, service definitions, and change control before you learn advanced features.

$ defender angle: Segment based on trust boundaries and business function: user devices, servers, privileged admin hosts, OT or IoT equipment, guest access, and management interfaces should not all communicate freely. Each boundary is a chokepoint where you can inspect, allow, block, or log.

$ prove understanding: Read firewall policies in the correct order and predict packet outcomes.

deep-dive-notes-expanded

Read each section, then immediately test the concept in your lab. Theory that you have not verified with a real command or log line does not stick.

1. Subnetting for Security and Operations

Subnetting shapes broadcast scope, route design, ACL readability, and how quickly you can isolate a compromised segment. Clear subnet boundaries make incident scoping faster. When an alert fires on a host in 10.10.20.0/24 and your naming standard tells you that is the server VLAN, you know the immediate blast radius before you even pull a log.

SIEM alerts and firewall rules reference IP ranges constantly, not hostnames. Misreading a /26 as a /24 leads to triage errors. Comfortable CIDR arithmetic is a practical skill, not just exam prep.

Encode purpose into your address plan early. A subnet that communicates its role — user-lan, server-lan, mgmt, guest — makes policies easier to write, easier to review, and easier to automate later.

Normal Behavior

Every allowed cross-zone connection matches exactly one firewall rule; the hit counter on that rule increments during a validation test.

Failure / Abuse Pattern

A host in a restricted zone can reach a service that the policy matrix says it should not — a shadow rule with a broad destination ('any') is matching before the deny rule.

Evidence To Collect

Calculate subnets and understand host ranges, broadcast domains, and route summaries.

2. NAT and the Security Interpretation Problem

NAT changes packet source or destination addresses in transit. That is useful for address conservation and exposure control, but it creates investigation problems. The IP in a firewall log may not be the IP the endpoint or server recorded. Correlating pre-NAT and post-NAT views across firewall, endpoint, and application logs is a skill incident responders need every week.

Source NAT handles outbound traffic; destination NAT and port forwarding publish internal services externally. Both require explicit documentation of address translation rules so analysts can follow a connection across log sources without losing the thread.

NAT alone is not a security strategy. It reduces accidental exposure, but it does not replace filtering, segmentation, authentication, and monitoring. Treating NAT as a security boundary is a mistake that shows up repeatedly in incident reports.

Normal Behavior

The output of `ip route show` lists only the subnets documented in the IP address plan with the correct gateway.

Failure / Abuse Pattern

Firewall logs show the original RFC 1918 source address, but the destination server logs show a different NAT address — the SIEM is correlating the wrong field and missing the link.

Evidence To Collect

Explain source NAT, destination NAT, and port forwarding in plain operational terms.

3. Firewall Policy Logic and Segmentation Strategy

Most firewall failures are policy design problems, not product problems. A small set of explicit, intentional rules with a clear implicit-deny default is far safer than a pile of accumulated exceptions nobody remembers adding. Learn rule order, object groups, service definitions, and change control before you learn advanced features.

Segment based on trust boundaries and business function: user devices, servers, privileged admin hosts, OT or IoT equipment, guest access, and management interfaces should not all communicate freely. Each boundary is a chokepoint where you can inspect, allow, block, or log.

From a detection standpoint, segmentation also improves signal quality. When only documented flows are permitted between zones, an unexpected connection attempt becomes a meaningful alert rather than a routine event buried in general traffic.

Normal Behavior

NAT translation table entries match the expected source addresses on each side of the boundary when compared across firewall and host logs.

Failure / Abuse Pattern

A host reports intermittent packet loss to a destination in a different subnet — two overlapping routes are causing asymmetric forwarding; check `ip route get <dest>` on both ends.

Evidence To Collect

Read firewall policies in the correct order and predict packet outcomes.

terminal-walkthroughs-with-example-output

Each walkthrough shows a command and what useful output looks like. Your lab output will differ — focus on which fields to read, not on matching the exact values shown here.

Addressing And Route Validation

Beginner

Command

ip -br addr

Example Output

# command executed in lab
# review output for expected fields, errors, and anomalies

$ why this matters: Run this against your lab environment and read the output field by field before moving on to the next command in this block. If you cannot explain what you see, re-read the section on addressing and route validation.

NAT / Firewall Quick Checks (Linux Lab)

Intermediate

Command

sudo nft list ruleset

Example Output

# command executed in lab
# review output for expected fields, errors, and anomalies

Segmentation Validation

Advanced

Command

ping -c 3 10.10.30.10

Example Output

# command executed in lab
# review output for expected fields, errors, and anomalies

cli-labs-and-workflow

Run these in a lab VM or network segment you own or are authorized to test against. After each command, write down one thing the output told you that you did not already know.

Addressing And Route Validation

Beginner

ip -br addr
ip route show
ipcalc 10.10.20.0/24
ipcalc 10.10.20.0/27

Run in a lab or authorized environment. Record what fields change when you alter the test conditions.

NAT / Firewall Quick Checks (Linux Lab)

Intermediate

sudo nft list ruleset
sudo iptables -t nat -L -n -v
sudo iptables -L -n -v
sudo conntrack -L | head

Run in a lab or authorized environment. Record what fields change when you alter the test conditions.

Segmentation Validation

Advanced

ping -c 3 10.10.30.10
nc -vz 10.10.30.10 22
traceroute 10.10.30.10 || tracepath 10.10.30.10

Run in a lab or authorized environment. Record what fields change when you alter the test conditions.

expert-mode-study-loop

$Explain the concept out loud as if briefing a colleague — no notes.
$Pick one CLI command and walk through exactly what the output means field by field.
$Name a specific failure mode and the log line or packet flag that reveals it.
$Write down what normal looks like for your lab before you introduce any anomaly.

Progress marker: Move on when you can brief the topic to someone else, run the commands from memory, and explain what a bad result looks like.

knowledge-check-and-answer-key

Answer each question out loud or in writing before you look at the hints. If you cannot answer it, go back to the section that covers it — do not just read the hint and move on.

1. Subnetting for Security and Operations

Questions

?How would you explain "Subnetting for Security and Operations" to a new defender in plain language?
?What does normal behavior look like for subnetting for security and operations in your lab or environment?
?Which logs, packets, or commands would you use to validate subnetting for security and operations?
?What failure mode or attacker abuse pattern matters most for subnetting for security and operations?

Show answer key / hints

Answer Key / Hints

#Calculate subnets and understand host ranges, broadcast domains, and route summaries.
#Every allowed cross-zone connection matches exactly one firewall rule; the hit counter on that rule increments during a validation test.
#ip -br addr
#A host in a restricted zone can reach a service that the policy matrix says it should not — a shadow rule with a broad destination ('any') is matching before the deny rule.

2. NAT and the Security Interpretation Problem

Questions

?How would you explain "NAT and the Security Interpretation Problem" to a new defender in plain language?
?What does normal behavior look like for nat and the security interpretation problem in your lab or environment?
?Which logs, packets, or commands would you use to validate nat and the security interpretation problem?
?What failure mode or attacker abuse pattern matters most for nat and the security interpretation problem?

Show answer key / hints

Answer Key / Hints

#Explain source NAT, destination NAT, and port forwarding in plain operational terms.
#The output of `ip route show` lists only the subnets documented in the IP address plan with the correct gateway.
#sudo nft list ruleset
#Firewall logs show the original RFC 1918 source address, but the destination server logs show a different NAT address — the SIEM is correlating the wrong field and missing the link.

3. Firewall Policy Logic and Segmentation Strategy

Questions

?How would you explain "Firewall Policy Logic and Segmentation Strategy" to a new defender in plain language?
?What does normal behavior look like for firewall policy logic and segmentation strategy in your lab or environment?
?Which logs, packets, or commands would you use to validate firewall policy logic and segmentation strategy?
?What failure mode or attacker abuse pattern matters most for firewall policy logic and segmentation strategy?

Show answer key / hints

Answer Key / Hints

#Read firewall policies in the correct order and predict packet outcomes.
#NAT translation table entries match the expected source addresses on each side of the boundary when compared across firewall and host logs.
#ping -c 3 10.10.30.10
#A host reports intermittent packet loss to a destination in a different subnet — two overlapping routes are causing asymmetric forwarding; check `ip route get <dest>` on both ends.

lab-answer-key-expected-findings

These are reference answers for a generic environment. Replace them with observations from your own lab — what you measured yourself is more useful than what is written here.

Expected Normal Findings

+Every allowed cross-zone connection matches exactly one firewall rule; the hit counter on that rule increments during a validation test.
+The output of `ip route show` lists only the subnets documented in the IP address plan with the correct gateway.
+NAT translation table entries match the expected source addresses on each side of the boundary when compared across firewall and host logs.

Expected Failure / Anomaly Clues

!A host in a restricted zone can reach a service that the policy matrix says it should not — a shadow rule with a broad destination ('any') is matching before the deny rule.
!Firewall logs show the original RFC 1918 source address, but the destination server logs show a different NAT address — the SIEM is correlating the wrong field and missing the link.
!A host reports intermittent packet loss to a destination in a different subnet — two overlapping routes are causing asymmetric forwarding; check `ip route get <dest>` on both ends.

hands-on-labs

$Practice subnet calculations for /24, /26, /27, and /28 networks and map them to user/server/management zones.
$Create a sample firewall rule set for user-to-internet, user-to-server, admin-to-management, and default deny.
$Simulate a port-forwarded service and document the pre-NAT and post-NAT addresses visible in logs.

common-pitfalls

$Allow-any temporary rules that never get removed.
$Overlapping subnets and unclear naming conventions.
$Assuming NAT equals segmentation or meaningful access control.

tools-and-references

completion-outputs

# A zone-based network diagram
# A baseline firewall policy matrix (source, destination, service, reason)
# A segmentation improvement backlog for your current environment

related-threat-pages

See where these fundamentals appear in real attack scenarios and what evidence defenders look for during triage.

open /threats/exposed-services-and-remote-access-weaknesses Exposed services and remote access weaknesses open /threats/lateral-movement-after-initial-access Lateral movement after initial access

<- previous page TCP/IP, DNS, HTTP, TLS, Routing and Switching Fundamentals -> next page Linux and Windows Logging Basics for Defenders

learning-path-position

Foundations / Weeks 1-2 · Module 2 of 12