Scrolls
6 min read
On this page

Firewalls & Network Segmentation

A flat network is a single point of failure. Once an attacker gets past the perimeter, they move laterally without restriction, accessing databases, internal services, and administrative interfaces. Firewalls and network segmentation limit what an attacker can reach after initial compromise. The goal is not to make the perimeter impenetrable -- it is to ensure that breaching one system does not mean breaching everything.

Firewalls

A firewall controls traffic flow based on rules. It inspects packets and either allows or denies them based on source IP, destination IP, port, and protocol.

Types of Firewalls

Type                    What It Does                          Example
──────────────────────────────────────────────────────────────────────────
Packet filter           Inspects individual packets            iptables, pf
                        (IP, port, protocol)

Stateful firewall       Tracks connection state, allows        AWS Security Groups,
                        return traffic automatically           firewalld

Application firewall    Inspects application layer data        WAF, ModSecurity
                        (HTTP headers, request body)

Next-gen firewall       Deep packet inspection, IDS/IPS,       Palo Alto, Fortinet
                        application awareness

Firewall Rules

Firewall rules are evaluated top to bottom. The first matching rule wins. A default-deny policy means any traffic not explicitly allowed is dropped.

# iptables example: basic web server rules
# Allow established connections
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow SSH from management network only
iptables -A INPUT -p tcp --dport 22 -s 10.0.1.0/24 -j ACCEPT

# Allow HTTP and HTTPS from anywhere
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Allow loopback
iptables -A INPUT -i lo -j ACCEPT

# Default deny everything else
iptables -P INPUT DROP
iptables -P FORWARD DROP

The principle: deny by default, allow by exception. Every open port is an attack surface. Only open what is required.

Network Segmentation

Network segmentation divides a network into isolated segments. Each segment has its own access controls. Traffic between segments passes through a firewall or router that enforces policies.

Why Segment

The Target breach of 2013 is the canonical example. Attackers compromised an HVAC vendor's credentials and used them to access Target's network. Because the HVAC system, point-of-sale terminals, and payment processing systems were all on the same network, the attackers moved laterally from the HVAC system to the payment infrastructure. They exfiltrated 40 million credit card numbers and 70 million customer records. Network segmentation between the HVAC vendor network and the payment network would have prevented lateral movement.

Segmentation Patterns

Segment               Contains                    Access Policy
───────────────────────────────────────────────────────────────────────
DMZ                    Public-facing servers        Internet → DMZ: allowed
                       (web servers, load           DMZ → Internal: restricted
                       balancers, CDN origins)      DMZ → Database: denied

Application tier       Application servers,         DMZ → App: specific ports
                       API backends                 App → Database: allowed
                                                    App → Internet: restricted

Database tier          Databases, caches,           App → DB: specific ports
                       message queues               Internet → DB: denied
                                                    DB → Internet: denied

Management network     SSH bastion hosts,           VPN → Management: allowed
                       monitoring, CI/CD            Management → All: allowed
                                                    Internet → Management: denied

VPCs & Subnets in Cloud Environments

Cloud providers implement network segmentation through Virtual Private Clouds (VPCs) and subnets.

VPC Architecture

A VPC is an isolated virtual network within a cloud provider. You control the IP address range, subnets, route tables, and gateways.

VPC: 10.0.0.0/16
├── Public Subnet: 10.0.1.0/24  (has internet gateway route)
│   ├── Load Balancer
│   └── NAT Gateway
├── Private Subnet: 10.0.2.0/24 (no direct internet access)
│   ├── Application Servers
│   └── Worker Nodes
└── Isolated Subnet: 10.0.3.0/24 (no internet route at all)
    ├── Database (RDS)
    └── Redis Cache

Public subnets have a route to an internet gateway. Private subnets route outbound traffic through a NAT gateway (for software updates, API calls) but are not reachable from the internet. Isolated subnets have no internet access at all.

Security Groups

Security groups are stateful firewalls attached to individual resources (EC2 instances, RDS databases, Lambda functions). They define allowed inbound and outbound traffic.

# Security group for web servers
Inbound:
  - Port 443 (HTTPS) from 0.0.0.0/0
  - Port 80 (HTTP) from 0.0.0.0/0
  - Port 22 (SSH) from sg-management (security group reference)

Outbound:
  - Port 5432 (PostgreSQL) to sg-database
  - Port 6379 (Redis) to sg-cache
  - Port 443 (HTTPS) to 0.0.0.0/0 (for external API calls)

# Security group for database
Inbound:
  - Port 5432 from sg-webservers
  - Port 5432 from sg-workers

Outbound:
  - None (databases should not initiate outbound connections)

Security group best practices:

  • Reference other security groups instead of IP addresses when possible. This decouples rules from specific IPs.
  • Never use 0.0.0.0/0 for SSH or database ports.
  • Review security group rules regularly. Stale rules accumulate over time.

Network ACLs

Network ACLs (NACLs) are stateless firewalls at the subnet level. They provide a second layer of defense. Unlike security groups, NACLs are stateless -- you must define both inbound and outbound rules for return traffic.

# NACL for database subnet
Inbound:
  Rule 100: Allow TCP 5432 from 10.0.2.0/24 (application subnet)
  Rule *:   Deny all

Outbound:
  Rule 100: Allow TCP 1024-65535 to 10.0.2.0/24 (ephemeral ports for responses)
  Rule *:   Deny all

Zero Trust

The traditional security model trusts everything inside the network perimeter. Zero trust assumes the network is already compromised and requires authentication and authorization for every request, regardless of network location.

Zero Trust Principles

1. Never trust, always verify
2. Assume breach
3. Verify explicitly (authenticate every request)
4. Use least-privilege access
5. Inspect and log all traffic

Zero trust is not a product you buy. It is an architecture approach. Key components:

  • Identity-aware proxy: Every request goes through a proxy that verifies the user's identity and device health before granting access. Google's BeyondCorp is the most well-known implementation.
  • Mutual TLS (mTLS): Both client and server present certificates. The server verifies the client's identity. Service meshes like Istio and Linkerd implement mTLS between services.
  • Microsegmentation: Fine-grained network policies at the workload level, not just the subnet level.

BeyondCorp (Google)

After the Aurora attacks in 2009 (a Chinese state-sponsored attack that compromised Google's internal network), Google built BeyondCorp. It eliminated the concept of a privileged internal network. Every Google employee accesses internal applications through an identity-aware proxy, regardless of whether they are in the office or at home. Access decisions are based on user identity, device health, and context -- not network location.

Micro-Segmentation

Micro-segmentation applies network policies at the individual workload level rather than the subnet level. In Kubernetes, this means network policies between pods. In a service mesh, this means mTLS and authorization policies between services.

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

Without a network policy, all pods in a Kubernetes cluster can communicate with all other pods by default. This is a flat network inside the cluster. Define network policies for every service.

Real-World Segmentation Failures

NotPetya (2017)

The NotPetya malware spread through Maersk's network in seven minutes, destroying 49,000 laptops, 3,500 servers, and 1,200 applications. The malware used EternalBlue (an SMB vulnerability) and credential harvesting to move laterally. Maersk's network was largely flat -- once the malware entered, it spread everywhere. The total damage was estimated at $300 million. Network segmentation would have contained the spread to the initially compromised segment.

SolarWinds (2020)

After compromising SolarWinds Orion, attackers used the monitoring software's broad network access to move laterally within victim organizations. Orion had access to virtually every network segment because it needed to monitor everything. Organizations that segmented their monitoring infrastructure and limited Orion's access reduced the blast radius of the compromise.

Common Pitfalls

  • Default-allow firewall policies. Start with deny-all and add specific allow rules. Never start open and try to close things down later.
  • Flat networks. A single network segment with no internal firewalls means one compromised system exposes everything. At minimum, separate public-facing services from databases and internal services.
  • Overly broad security group rules. 0.0.0.0/0 on port 22 is an invitation. Restrict administrative access to specific IPs or, better, use a bastion host or VPN.
  • Not reviewing firewall rules. Rules accumulate. Temporary exceptions become permanent. Review rules quarterly and remove anything no longer needed.
  • Trusting the internal network. The perimeter will be breached. Internal services should authenticate and authorize requests, not rely on network location for security.
  • Kubernetes without network policies. Default Kubernetes networking allows all pods to communicate with all other pods. This is a flat network inside your cluster. Apply network policies from day one.

Key Takeaways

  • Default-deny is the fundamental firewall principle. Only allow traffic that is explicitly required.
  • Network segmentation limits blast radius. Separate public-facing services, application servers, and databases into distinct network segments.
  • In cloud environments, use VPCs, subnets, security groups, and NACLs to implement segmentation. Reference security groups instead of IP addresses.
  • Zero trust assumes the network is already compromised. Authenticate and authorize every request regardless of network location.
  • Micro-segmentation applies access controls at the workload level. In Kubernetes, use network policies. In service meshes, use mTLS.
  • The Target, NotPetya, and SolarWinds incidents all demonstrate the catastrophic consequences of flat or insufficiently segmented networks.
  • Review firewall rules regularly. Stale rules and temporary exceptions are a common source of exposure.