Networking Deep Dive — Subnets, Routing, Firewalls, VPNs, Zero Trust

Networking is the substrate of every security problem. Firewalls make decisions based on IP addresses and port numbers. VPNs extend trust across untrusted networks. Network segmentation limits lateral movement after a breach. Zero Trust replaces the network perimeter with identity and device posture checks. You cannot design or operate any of these without understanding how packets actually move.

This module builds on Module 02 (how the internet works) and Module 10 (network attacks) to go deeper: subnetting and CIDR, stateful vs stateless firewalls, NAT and its security implications, IPSec and WireGuard VPN mechanics, network segmentation patterns, and the Zero Trust architecture model. By the end you'll be able to read firewall rule sets, design segmentation for a corporate network, and explain why "trust but verify" died as a security model.

IP Addressing and CIDR — The Foundation of Network Security

Every firewall rule, network segment, and routing decision is based on IP addresses. CIDR (Classless Inter-Domain Routing) notation specifies IP ranges using a prefix length: 192.168.1.0/24 means "the first 24 bits are fixed, the last 8 bits vary" — a range of 256 addresses (192.168.1.0–192.168.1.255).

CIDR quick reference:

Notation  Subnet Mask       Host Count  Example Range
/8        255.0.0.0         16,777,214  10.0.0.0 – 10.255.255.255
/16       255.255.0.0       65,534      172.16.0.0 – 172.16.255.255
/24       255.255.255.0     254         192.168.1.0 – 192.168.1.254
/25       255.255.255.128   126         192.168.1.0 – 192.168.1.127
/26       255.255.255.192   62          192.168.1.0 – 192.168.1.63
/28       255.255.255.240   14          192.168.1.0 – 192.168.1.15
/30       255.255.255.252   2           192.168.1.0 – 192.168.1.3
/32       255.255.255.255   1 (host)    192.168.1.50 – 192.168.1.50

Reserved private ranges (RFC 1918):
  10.0.0.0/8          Class A private (large corporations)
  172.16.0.0/12       Class B private (172.16–172.31)
  192.168.0.0/16      Class C private (home/small office)

Loopback:
  127.0.0.0/8         Never leaves the host (127.0.0.1 = localhost)

Link-local (APIPA):
  169.254.0.0/16      Auto-assigned when DHCP fails

IPv6 private:
  fc00::/7  (ULA — Unique Local Addresses, similar to RFC 1918)
  ::1       Loopback

Security implication: Firewall rules use CIDR to specify allowed/denied ranges.
  10.0.0.0/8  = "all internal traffic" (risky — allows all internal lateral movement)
  10.10.1.0/24 = "only production subnet 1" (better — scoped access)

Network segmentation using CIDR is the primary control against lateral movement. If an attacker compromises a workstation in the 10.10.5.0/24 (user) subnet, firewall rules that block 10.10.5.0/24 from reaching 10.10.1.0/24 (production servers) prevent lateral movement — even if the attacker has admin credentials.

How Routing Decisions Are Made

When a host sends a packet, it decides whether the destination is local (same subnet) or remote (requires a router). This decision is made using the subnet mask. If the destination IP ANDed with the subnet mask equals the local network address, it's local — send directly via ARP. Otherwise, send to the default gateway.

Routing decision example:

Host: 192.168.1.50, Subnet: /24 (mask 255.255.255.0)
Network: 192.168.1.0

Sending to 192.168.1.100 (local):
  192.168.1.100 AND 255.255.255.0 = 192.168.1.0  ← matches local network
  → ARP for 192.168.1.100, send directly

Sending to 8.8.8.8 (remote):
  8.8.8.8 AND 255.255.255.0 = 8.8.8.0  ← does NOT match 192.168.1.0
  → Send to default gateway (192.168.1.1)
  → Router looks up 8.8.8.8 in routing table → forwards to ISP

Router routing table (ip route on Linux):
  Destination     Gateway        Interface
  0.0.0.0/0       203.0.113.1    eth0      ← default route (everything else)
  10.10.0.0/16    10.10.0.1      eth1      ← internal network
  192.168.1.0/24  directly       eth2      ← local subnet

Longest prefix match:
  When multiple routes match, the most specific (longest) prefix wins.
  Packet to 10.10.5.50:
    0.0.0.0/0  matches (default)
    10.10.0.0/16 matches ← wins (more specific)

  This is why /32 host routes override /24 subnet routes —
  and why BGP hijackers announce more-specific prefixes.

Firewalls — Stateless vs Stateful vs NGFW

A firewall enforces rules on network traffic. The evolution from stateless to stateful to next-generation firewalls corresponds to increasing context — and increasing ability to block sophisticated attacks.

Stateful firewall — connection tracking:

Problem with stateless firewalls:
  Allow outbound TCP/80 (HTTP requests):
    Rule: PERMIT src=internal dst=any port=80 tcp

  Need to allow return traffic:
    Rule: PERMIT src=any dst=internal dport=1024-65535 tcp
    ← This also allows ANY external host to connect to any high port
      on any internal host — a massive hole

Stateful solution:
  Firewall maintains a connection table:
    (src_ip, src_port, dst_ip, dst_port, protocol, state)

  When internal host sends TCP SYN to 93.184.216.34:80:
    Table entry: (10.0.1.50, 54321, 93.184.216.34, 80, TCP, SYN_SENT)

  When 93.184.216.34 sends SYN-ACK back:
    Firewall checks table: is there an entry matching this return flow?
    Yes → PERMIT (it's a response to an established connection)

  Unsolicited inbound from 1.2.3.4:80 → 10.0.1.50:54321?
    No matching table entry → DROP
    Even though 54321 is in the 1024-65535 range

NGFW — TLS inspection (break-and-inspect):
  Problem: Most traffic is HTTPS — firewall can't see the payload

  Solution: NGFW acts as a TLS proxy
  1. Client connects to NGFW (TLS handshake with NGFW's certificate)
  2. NGFW connects to real server (separate TLS session)
  3. NGFW sees plaintext — can scan for malware, data loss, policy violations
  4. Re-encrypts to client

  Security implication: NGFW's CA cert must be trusted by all clients
  This is why corporate-managed devices have extra CA certs in their trust store
  (installed via MDM/Group Policy)

Reading firewall rules (iptables example):

# Show all rules with line numbers
iptables -L -n -v --line-numbers

Chain INPUT (policy DROP)     ← Default: deny all inbound
num  pkts bytes target   prot  src            dst       dport
1    1.2M  960M ACCEPT   all   anywhere       anywhere  state RELATED,ESTABLISHED
2    847  62178 ACCEPT   tcp   anywhere       anywhere  tcp dport:22    ← SSH
3    12K  1.3M  ACCEPT   tcp   10.0.0.0/8     anywhere  tcp dport:8080  ← App (internal only)
4      0      0 LOG      all   anywhere       anywhere  LOG prefix="DROP "
5      0      0 DROP     all   anywhere       anywhere  ← Everything else dropped

Chain FORWARD (policy DROP)   ← Block forwarding by default
Chain OUTPUT (policy ACCEPT)  ← Allow all outbound

Key concepts:
  - Rules processed top-to-bottom; first match wins
  - state RELATED,ESTABLISHED: stateful — allows return traffic
  - policy DROP: implicit deny (implicit allow would be "policy ACCEPT")
  - LOG before DROP: capture drops for analysis without allowing traffic

Security hardening:
  - Default policy: DROP (deny-all, allow-what-you-need)
  - Never: ACCEPT all + block bad (allow-all, deny-what-you-know — fails against unknowns)
  - Log drops: essential for detecting scan attempts and blocked attacks

NAT — Network Address Translation and Its Security Implications

NAT allows many devices with private IP addresses to share a single public IP address. A home router or corporate gateway performs NAT by rewriting source IP addresses in outbound packets and tracking the mapping to route return traffic correctly.

NAT mechanics:

Internal network: 10.0.0.0/24
Public IP: 203.0.113.1 (the router/gateway)

Outbound packet:
  Internal host:  10.0.0.50:54321 → 93.184.216.34:443

  Router rewrites source:
  After NAT:      203.0.113.1:41234 → 93.184.216.34:443

  Router NAT table:
  (10.0.0.50, 54321, 93.184.216.34, 443) ↔ (203.0.113.1, 41234)

Return packet:
  93.184.216.34:443 → 203.0.113.1:41234

  Router reverses translation:
  After un-NAT:   93.184.216.34:443 → 10.0.0.50:54321
  ← Delivered to correct internal host

Security properties of NAT:
  ✓ Internal IPs are hidden from external observers
  ✓ Unsolicited inbound connections are blocked (no NAT entry exists)
  ✓ Obscures internal network structure from attackers

Security limitations of NAT:
  ✗ NAT is NOT a firewall — it's address translation, not access control
    (though the translation table provides stateful-like inbound blocking)
  ✗ Internal hosts can still make outbound connections to malicious sites
  ✗ Malware on internal hosts tunnels C2 through allowed outbound ports
  ✗ IPv6 does not use NAT — all IPv6 hosts get public addresses (new exposure)

Port forwarding (DNAT — Destination NAT):
  Rule: traffic to 203.0.113.1:22 → forward to 10.0.0.100:22
  Exposes internal service to internet
  Common misconfiguration: accidentally exposing RDP (3389), SSH (22),
  admin panels (8080), databases (3306) to internet

VPNs — IPSec and WireGuard Under the Hood

A Virtual Private Network (VPN) creates an encrypted tunnel through an untrusted network (the internet), making remote clients appear to be on the corporate network. Understanding the protocols helps you distinguish between VPNs that are secure by design and those that rely on outdated or weak cryptography.

IPSec VPN (traditional enterprise standard):

Two modes:
  Transport mode: Encrypts only payload, IP headers unchanged
                  Used for host-to-host encryption

  Tunnel mode:   Encrypts the entire original IP packet + new IP header added
                 Used for site-to-site and remote access VPNs

Two protocols:
  AH (Authentication Header): Integrity + authentication, NO encryption
  ESP (Encapsulating Security Payload): Integrity + authentication + encryption
  ← ESP is used almost exclusively in practice

IKE (Internet Key Exchange) — the negotiation protocol:
  Phase 1 (IKE SA): Establish secure channel to negotiate Phase 2
    Algorithms: AES-256-GCM, SHA-256, DH Group 14+ (2048-bit)
    Result: Encrypted channel between peers

  Phase 2 (Child SA): Negotiate encryption for actual data
    Result: IPSec SA with keys for encrypting traffic

Weaknesses in legacy IPSec deployments:
  - IKEv1 with aggressive mode: leaks identity information, crackable offline
  - DH Group 2 (1024-bit): breakable by nation-states (Logjam attack)
  - MD5 or SHA-1 for HMAC: deprecated

Modern: IKEv2 + AES-256-GCM + SHA-256 + DH Group 20 (ECDH P-384) = secure

WireGuard — modern VPN protocol:

Design philosophy: Simple, fast, auditable
Lines of code: ~4,000 (vs OpenVPN ~70,000, IPSec ~400,000)
Smaller codebase = smaller attack surface

Cryptography (hardcoded — no negotiation, no weak options):
  Key exchange:   Curve25519 (ECDH)
  Encryption:     ChaCha20-Poly1305 (AEAD)
  Hashing:        BLAKE2s
  Handshake:      Noise protocol framework

Configuration (server side):
  [Interface]
  PrivateKey = <base64-encoded server private key>
  Address = 10.0.0.1/24           # VPN tunnel address
  ListenPort = 51820               # UDP port

  [Peer]
  PublicKey = <client public key>
  AllowedIPs = 10.0.0.2/32        # What IPs this client can send

Configuration (client side):
  [Interface]
  PrivateKey = <client private key>
  Address = 10.0.0.2/24
  DNS = 10.0.0.1

  [Peer]
  PublicKey = <server public key>
  Endpoint = vpn.company.com:51820
  AllowedIPs = 0.0.0.0/0          # Route all traffic through VPN
  PersistentKeepalive = 25        # Keep NAT open

Security advantages over traditional VPNs:
  - No algorithm negotiation → no downgrade attacks
  - Cryptographically modern algorithms (ChaCha20, Curve25519)
  - Roaming: Reconnects instantly when IP changes (mobile-friendly)
  - No UDP/TCP handshake visible to passive observer until authenticated

Network Segmentation — Designing Defense in Depth

Network segmentation divides a network into isolated zones, limiting how far an attacker can move after gaining a foothold. The principle: breach containment. Even if the attacker compromises one zone, firewall rules prevent them from reaching higher-value zones without additional exploitation.

Segmentation model — tiered security zones:

Internet
    |
    | [DMZ Firewall — allow 443/80 inbound from internet to DMZ]
    |
  DMZ (10.10.0.0/24)
    Web servers, load balancers, public APIs
    Rules: Allow 443/80 from internet; Allow 8080 to App tier; DENY everything else
    |
    | [Internal Firewall — allow only specific app traffic]
    |
  App Tier (10.10.1.0/24)
    Application servers, microservices
    Rules: Allow from DMZ on app ports; Allow DB port to Data tier; DENY rest
    |
    | [DB Firewall — very restrictive]
    |
  Data Tier (10.10.2.0/24)
    Databases, file servers, secrets managers
    Rules: Allow 5432/3306 from App tier only; DENY all else
    |
    | [Management VLAN — separate, highly restricted]
    |
  Management (10.10.99.0/24)
    Jump hosts, monitoring, backup systems
    Rules: Allow SSH/RDP from bastion only; Allow monitoring ports from monitoring only

User/Workstation VLAN (10.10.5.0/24)
    No access to Data tier
    No access to Management VLAN
    Access to App tier limited to needed ports only
    Internet access via proxy only

Firewall rule audit questions:
  - Does the rule apply the principle of least privilege?
  - Is the source as specific as possible (/32 preferred over /24 over 0.0.0.0/0)?
  - Is there a documented business justification for this rule?
  - When was this rule last reviewed? (Shadow rules: rules no longer in use)
  - Does any rule allow 0.0.0.0/0 as source to internal resources?
    ← Most dangerous finding in a firewall audit

Zero Trust Architecture — The End of the Network Perimeter

Traditional network security assumed the network perimeter was trustworthy. Employees inside the corporate network were trusted; outsiders were not. Zero Trust rejects this model entirely. The principle: "Never trust, always verify." Every access request — regardless of network location — must be authenticated, authorised, and verified against device health before access is granted.

The death of the traditional perimeter was not a design choice — it was forced by reality. Cloud services moved workloads outside the corporate network. Remote work moved users outside the corporate network. Mobile devices accessed corporate resources from anywhere. VPNs that grant broad network access became the attack vector (MOVEit, Citrix, Pulse Secure breaches all exploited VPN infrastructure). The perimeter collapsed.

Zero Trust principles (NIST SP 800-207):

1. All data sources and computing services are resources
   Nothing is trusted by virtue of being "on the network"

2. All communication is secured regardless of network location
   TLS for everything; mTLS for service-to-service

3. Access to individual resources is granted per-session
   Not "this user has VPN access, so they can reach everything"
   But "this user, on this device, with this posture, can access this service"

4. Access is determined by dynamic policy including:
   - User identity (who)
   - Device health (is it managed? up to date? no malware?)
   - Requested resource sensitivity
   - Environmental context (location, time, behaviour)

5. All resource authentication and authorisation is dynamic and strictly enforced

6. Collect security telemetry, use it to improve posture

Zero Trust components:
  Identity Provider (IdP): Okta, Azure AD, Google Workspace
    Authenticates users with MFA (preferably FIDO2)
    Issues short-lived access tokens (JWT, SAML assertions)

  Device Trust: MDM (Intune, Jamf) + EDR (CrowdStrike, Defender)
    Checks: Is the device managed? Is it encrypted? Is the OS patched?
    Is there malware detected? Is the EDR running?
    Device certificate issued only to compliant devices

  Policy Engine: Conditional Access (Azure), BeyondCorp, Zscaler
    Decision: Should this user on this device get this resource?
    Input: identity + device posture + resource sensitivity + context
    Output: allow / deny / step-up MFA / limited access

  Network: Micro-segmentation
    Application-layer policies replace IP-based network ACLs
    Each service only accepts connections from authenticated, authorised principals

Zero Trust vs VPN comparison:

Traditional VPN:
  User connects to VPN → receives corporate IP → has network-level access
  Problems:
  - VPN credentials stolen → attacker has full network access
  - VPN software has vulnerabilities (Pulse Secure, Citrix → mass exploitation)
  - Inside the VPN = trusted (but attacker is already inside)
  - Encrypted tunnel hides malware C2 from network monitoring

Zero Trust (ZTNA — Zero Trust Network Access):
  User authenticates to IdP (MFA) → Policy engine checks device posture
  → If compliant: get token for specific application only
  → Application proxy validates token before proxying request to backend

  Benefits:
  - No broad network access even after authentication
  - Device health check blocks BYOD or compromised managed devices
  - Attacker with stolen credentials: blocked by device posture check
  - Each application independently authenticated
  - Full visibility into who accessed what, when, from where

  Products: Cloudflare Access, Zscaler ZPA, BeyondCorp (Google),
            Tailscale (WireGuard-based, simpler), Palo Alto Prisma Access

Implementation sequence:
  1. Enforce MFA for all users (baseline)
  2. Deploy device management (MDM) + EDR
  3. Enable Conditional Access policies (require compliant device)
  4. Migrate internet-facing apps from VPN to ZTNA proxy
  5. Apply micro-segmentation to internal east-west traffic
  6. Enforce mTLS for service-to-service communication

Network Security Monitoring — What to Watch

Network visibility is the foundation of detection. You can't detect lateral movement, C2 communication, or data exfiltration if you can't see the network traffic. The modern network security stack captures traffic at strategic points.

Network monitoring architecture:

Network TAP (Test Access Point):
  Physical/virtual device that copies all traffic on a link
  Passive — doesn't affect traffic, can't be discovered by attackers
  Sends copy to IDS/NSM (Network Security Monitoring) system

SPAN port (Switched Port Analyzer):
  Switch feature: copies specified traffic to a monitor port
  Less reliable than TAP (may drop packets under load)
  Configured on managed switches, simpler to deploy

NetFlow/IPFIX:
  Flow records: who talked to whom, when, how much data
  Does NOT capture packet contents — just metadata
  Much lower storage cost than full packet capture
  Use case: detect beaconing (regular intervals), data exfiltration (high volume)
  Collected by: Cisco Stealthwatch, Zeek, ntopng, Plixer Scrutinizer

Full packet capture:
  Store entire packet (header + payload)
  Highest cost — 10Gbps link generates ~108TB/day
  Typically retained for 24-72 hours (hot), indexed by flow ID
  Use case: deep dive into specific incidents

IDS/IPS placement:
  North-South: Internet ↔ DMZ boundary (detect inbound attacks)
  East-West: Between internal segments (detect lateral movement)
  Key signals to alert on:
    - Connections to known C2 IPs/domains (threat intelligence)
    - DNS queries with high entropy (tunneling)
    - Unusual protocol on standard port (HTTP on port 443)
    - Large outbound transfers to unknown destinations
    - Internal host connecting to TOR exit nodes

Interview Questions

Error Library — Common Mistakes

In Module 16, you systematically harden a Linux server. Minimal install, user privilege management, SSH hardening, mandatory access controls (SELinux/AppArmor), kernel security parameters, audit logging, and automated compliance checking with tools like Lynis and OpenSCAP. You'll work through a CIS Benchmark checklist and understand which controls matter most for servers exposed to the internet.