Network Segmentation and Firewall Architecture

The Problem: Flat Networks Let Attacks Roam Freely

In a flat network, every host can reach every other host. If an attacker compromises a single workstation — through phishing, a vulnerable web application, or a stolen credential — they can scan and attack every other system on the network. There are no barriers to lateral movement. The attacker can reach file servers, databases, domain controllers, and other high-value targets from the initial foothold.

Network segmentation addresses this by dividing the network into isolated zones with controlled traffic flows between them. Each zone has a defined trust level, and traffic between zones is filtered by firewall rules. A compromise in one zone does not automatically grant access to adjacent zones.

The Trust Zone Model

Segmentation starts with classifying assets by trust level and function:

• External/Untrusted — the internet, partner networks, guest Wi-Fi
• DMZ (Semi-Trusted) — internet-facing services: web servers, reverse proxies, mail gateways
• Internal/Trusted — corporate workstations, internal applications, management interfaces
• Restricted/High-Value — databases, domain controllers, financial systems, PII stores
• Management — jump hosts, SIEM, logging infrastructure, backup systems

The principle: traffic flows from lower-trust to higher-trust zones only through explicitly allowed paths. A workstation in the internal zone should never need to connect directly to a database in the restricted zone — the application server in the DMZ or internal zone mediates that access.

VLANs and Subnet Segmentation

VLANs (Virtual Local Area Networks) are the most common segmentation mechanism at Layer 2. Each VLAN is a separate broadcast domain. Hosts in VLAN 10 cannot communicate with hosts in VLAN 20 without a router or Layer 3 switch to forward traffic between them. This is where firewall rules are applied — at the inter-VLAN routing point.

VLAN 10 (Workstations)  ──┐
                           ├──[ Firewall / L3 Switch ]── Internet
VLAN 20 (DMZ)           ──┤
                           │
VLAN 30 (Database)      ──┘

Subnet segmentation complements VLANs at Layer 3. Each zone gets its own IP subnet, and routing between subnets is controlled by Access Control Lists (ACLs) on the router or firewall. This provides defense-in-depth: even if VLAN hopping succeeds (through double-tagging or switch spoofing), the Layer 3 ACLs still restrict traffic.

Microsegmentation

Traditional segmentation is coarse — entire subnets are trusted or untrusted. Microsegmentation applies firewall rules at the individual workload level, even within the same subnet. This is achieved through:

• Host-based firewalls — Windows Defender Firewall, iptables, or nftables on each host
• Software-defined networking (SDN) — VMware NSX, Cisco ACI, or cloud security groups that enforce per-workload policies
• Container network policies — Kubernetes NetworkPolicies that restrict pod-to-pod traffic

Microsegmentation is essential in cloud and containerized environments where workloads in the same subnet may have different trust levels. A compromised web server in a Kubernetes cluster should not be able to reach the database pod unless a NetworkPolicy explicitly allows it.

# Kubernetes NetworkPolicy: only allow traffic from the api pods to the database
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-allow-from-api
spec:
  podSelector:
    matchLabels:
      app: database
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: api
    ports:
    - protocol: TCP
      port: 5432

Lateral Movement Confinement

The primary security benefit of segmentation is confining lateral movement. When an attacker compromises a host, their ability to reach high-value targets is limited by the segmentation rules:

• A compromised workstation in VLAN 10 can reach the DMZ (VLAN 20) but not the database (VLAN 30)
• A compromised web server in the DMZ can reach the application server but not the domain controller
• A compromised container in the frontend namespace cannot reach the backend database namespace

Each barrier forces the attacker to find and exploit another vulnerability, increasing the time and effort required and giving defenders more opportunities to detect the intrusion.

Deny by Default: The Firewall Mindset

A firewall is a traffic filter. It examines packets or connections and decides whether to allow or block them based on a rule set. The single most important principle in firewall configuration is deny by default — if a rule does not explicitly allow traffic, it is blocked. This is the opposite of the legacy approach (allow by default, block known-bad) which leaves enormous gaps for unknown threats.

Firewall Types

Packet-Filtering Firewalls (Layer 3/4)

The simplest firewall type. Examines each packet's source/destination IP, protocol, and port. Makes allow/deny decisions based on these header fields alone. Fast but cannot inspect payload content or track connection state.

# Example packet-filter rule (iptables)
# Allow inbound HTTP from anywhere
iptables -A INPUT -p tcp --dport 80 -j ACCEPT

# Allow outbound DNS
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT

# Drop everything else
iptables -A INPUT -j DROP
iptables -A OUTPUT -j DROP

Stateful Firewalls (Layer 4 with state tracking)

Track the state of active connections. When an internal host initiates a connection to an external server, the firewall automatically allows the return traffic without an explicit rule. This is more secure than packet filtering because it distinguishes between new connections (which require explicit rules) and established connections (which are part of an existing flow).

Next-Generation Firewalls (NGFW, Layer 7)

Combine stateful inspection with application-layer awareness, intrusion prevention, and identity-based policies. An NGFW can distinguish between HTTP traffic to a legitimate web application and HTTP traffic carrying SQL injection payloads. It can enforce policies like "allow Facebook but block Facebook chat" or "allow Windows Update but block other outbound HTTP."

Web Application Firewalls (WAF)

Specialized for HTTP/HTTPS traffic. Inspects request and response payloads for SQL injection, cross-site scripting, and other application-layer attacks. Deployed in front of web applications as a reverse proxy.

Rule Design Principles

1. Deny by default — the last rule in any rule set should be an explicit deny-all
2. Least privilege — allow only the specific traffic required for business function, nothing more
3. Documented justification — every allow rule should have a comment explaining the business need
4. Specific over general — allow tcp 10.0.1.0/24 to 10.0.2.10 port 443 is better than allow tcp any to any
5. Regular review — stale rules accumulate and create unnecessary attack surface

# Well-documented firewall rule example
# Rule: Allow web tier to reach app tier on the API port
# Business need: Web servers call the REST API on app servers
# Owner: Platform team, reviewed 2026-01-15
allow tcp 10.0.2.0/24 10.0.3.0/24 8443

# Rule: Allow monitoring to scrape metrics from all app servers
# Business need: Prometheus scrapes /metrics endpoint
# Owner: SRE team, reviewed 2026-01-15
allow tcp 10.0.4.10/32 10.0.3.0/24 9090

Firewall Placement

Perimeter Firewall

Sits at the network boundary between the internal network and the internet. Controls all inbound and outbound traffic. This is the traditional firewall placement and remains essential, but it is not sufficient on its own — once an attacker bypasses the perimeter (through phishing, a compromised VPN, or a vulnerable web application), there are no internal barriers.

Internal Firewall

Segments internal zones from each other. Enforces the trust zone model — workstations cannot reach databases, DMZ servers cannot reach management interfaces. Internal firewalls are the technical control that makes segmentation enforceable.

Host-Based Firewall

Runs on each endpoint (Windows Defender Firewall, iptables, nftables). Provides the last line of defense when network-level segmentation fails. In a zero-trust architecture, host-based firewalls enforce per-workload policies that do not depend on network location.

# Host-based firewall: allow only SSH from the management subnet
iptables -A INPUT -p tcp -s 10.0.4.0/24 --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP

DMZ Architecture

The Demilitarized Zone (DMZ) is a network segment that hosts internet-facing services. It is called a DMZ because it is neither fully trusted (like the internal network) nor fully untrusted (like the internet) — it is a buffer zone.

Internet ──[ Perimeter FW ]── DMZ (Web servers, reverse proxy)
                                  │
                            [ Internal FW ]── Internal network (workstations, databases)

Traffic flow rules for a DMZ:

• Internet → DMZ: allowed only on specific ports (80, 443) to specific servers
• DMZ → Internet: allowed for software updates and external API calls, but restricted
• DMZ → Internal: denied by default; only specific application-to-database flows are allowed
• Internal → DMZ: allowed for management and monitoring
• Internal → Internet: allowed through the perimeter firewall with content filtering

The key principle: a compromised DMZ server must not provide a foothold into the internal network. The internal firewall enforces this by blocking all unsolicited traffic from the DMZ to internal zones.

Beyond Perimeter: Zero Trust Architecture

Traditional network security assumed that everything inside the perimeter was trusted. Zero trust rejects that assumption. The core principle: never trust, always verify. Every request — whether it originates from inside or outside the network — must be authenticated, authorized, and encrypted before access is granted.

Zero Trust Principles

1. Verify explicitly — authenticate and authorize every request based on all available data points: user identity, device health, location, data classification, and service sensitivity
2. Least privilege access — grant only the minimum permissions needed for the specific task, for the shortest time necessary (just-in-time access)
3. Assume breach — design the network as if the attacker is already inside. Segment aggressively, monitor everything, and minimize blast radius

Identity-Aware Proxies

In a zero-trust architecture, access to applications is mediated by an identity-aware proxy rather than by network location. The user authenticates to the proxy (using SSO, MFA, and device posture checks), and the proxy forwards the request to the backend service only if the authorization policy allows it.

User → [ Identity-Aware Proxy ] → Backend Service
         ↑                        ↑
    Authenticates user         Service-to-service
    Checks device health       authentication (mTLS)
    Evaluates policy            Authorization

This means that network segmentation alone is not sufficient — the application must also verify identity and enforce authorization. A compromised workstation on the internal network cannot access the database even if the firewall rules allow it, because the identity-aware proxy rejects the request (the workstation does not have valid user credentials for that service).

Software-Defined Perimeters

A software-defined perimeter (SDP) hides infrastructure from unauthorized users. The infrastructure is dark — it does not respond to port scans, DNS queries, or any traffic from unauthenticated sources. Only after successful authentication does the SDP controller instruct the firewall to allow traffic from that specific user to that specific service.

Unauthenticated user → Port scan → No response (infrastructure is dark)
Authenticated user  → SDP controller → Firewall opens pinhole → Access granted

Practical Implementation

Zero trust is a journey, not a product. A practical implementation path:

1. Inventory and classify — identify all assets, data flows, and trust relationships
2. Segment the network — implement VLANs, subnets, and firewall rules based on the trust zone model
3. Deploy identity-aware access — implement SSO, MFA, and conditional access policies
4. Encrypt everything — TLS for all traffic, mTLS for service-to-service communication
5. Monitor and log — collect all access logs, analyze for anomalies, and alert on policy violations
6. Automate response — integrate with SOAR to automatically isolate compromised hosts or revoke access

Cloud Segmentation

In cloud environments, segmentation is implemented through security groups, network ACLs, and virtual private clouds (VPCs). Each VPC is an isolated network with its own routing tables and security groups. VPC peering and transit gateways control traffic between VPCs.

# AWS Security Group: allow only the web tier to reach the database
resource "aws_security_group" "db" {
  name = "database-sg"
  ingress {
    from_port   = 5432
    to_port     = 5432
    protocol    = "tcp"
    security_groups = [aws_security_group.web.id]
  }
}

Cloud-native segmentation is more flexible than physical segmentation because policies are defined in code, can be version-controlled, and can be automatically validated against security baselines.