Network Segmentation & Firewall

Every Path With Permission

In network security, structure beats improvisation: clear paths, fewer privileges, and explicit trust boundaries.

For Network Segmentation & Firewall, segmentation is the lever: explicit paths, deny-by-default, and controlled management.

This way you limit not only the chance of incidents, but especially the scope and duration when something goes wrong.

Immediate measures (15 minutes)

• Start with MFA, least privilege, and tiering for admin accounts.
• Implement segmentation and explicit firewall rules on critical paths.
• Ensure logging, detection, and recovery testing as a structural operation.

Why this matters

The core of Network Segmentation & Firewall is risk reduction in practice. Technical context supports the choice of measures, but implementation and assurance are central.

Why segmentation

Network segmentation is about three things:

1. Limiting blast radius – when a workstation is compromised, segmentation determines how much of the network the attacker can reach. In a flat network the answer is: everything. In a segmented network the answer is: only the segment where that workstation resides.

2. Stopping lateral movement – there are 13 lateral movement commands in the attack arsenal (see chapter 6). Each of them requires network access to the target system. If that access does not exist, those 13 commands are worthless. Segmentation is not one of the defenses against lateral movement — it is the defense.

3. Compliance – PCI DSS requires segmentation of the cardholder data environment. ISO 27001 requires network segmentation as part of Annex A.13. NIS2 requires "adequate network segmentation." Regulation enforces what common sense could not achieve.

Flat network vs. segmented network

FLAT NETWORK                          SEGMENTED NETWORK

+--------------------------------+    +---------+  +---------+  +----------+
|                                |    | DMZ     |  | Internal|  | Restrict |
| WS01  WS02  SRV01  DC01  DB01 |    | WEB01   |  | WS01    |  | DC01     |
| PRINTER  WEB01  MGMT01  NAS01 |    | WEB02   |  | WS02    |  | DB01     |
|                                |    | MAIL01  |  | SRV01   |  | MGMT01   |
| Everything talks to everything.|    +----+----+  +----+----+  +----+-----+
| The intern pings the DC.       |         |            |            |
+--------------------------------+    +----+------------+------------+---+
                                      |          FIREWALL               |
                                      | Only explicit traffic through   |
                                      +---------------------------------+

Segmentation Models

Not all segmentation is equal. There are four common models, each with their own trade-offs:

VLAN-based – the classic approach. Workstations in VLAN 10, servers in VLAN 20, management in VLAN 30. Traffic between VLANs goes through a layer-3 switch with ACLs. The problem: within a VLAN, everything can talk to everything.

Subnet-based – similar, but with routing as enforcement. ACLs on the gateway determine which traffic is allowed through. Slightly more flexible because you can nest subnets.

Microsegmentation – segmentation at host level. Each workload has its own firewall rules. Two servers in the same VLAN cannot communicate with each other if the microsegmentation does not allow it. The future, but a lot of work.

Zero Trust (ZTNA) – trust nothing, verify everything. Every connection is authenticated, regardless of origin. There is no "internal" and "external" — only "verified" and "not verified." The ideal. The reality is that most organizations still struggle with basic VLAN segmentation.

Zone Design

A well-segmented network has at least three zones:

Design principles: DMZ has no direct access to the restricted zone. Workstations do not talk to workstations (no SMB/WinRM peer-to-peer). Management traffic goes through a dedicated management VLAN. The domain controller is only reachable from management and via LDAP/Kerberos — no RDP or WinRM from workstations.

VLAN Configuration

802.1Q tagging

VLANs work via IEEE 802.1Q tagging. Each frame gets a tag with the VLAN ID. Trunk ports carry traffic for multiple VLANs; access ports are assigned to a single VLAN.

VLAN best practices

! Cisco IOS -- VLAN configuration

! Step 1: Create VLANs
vlan 10
 name WORKSTATIONS
vlan 20
 name SERVERS
vlan 30
 name MANAGEMENT
vlan 40
 name DMZ
vlan 99
 name NATIVE_UNUSED
vlan 999
 name BLACKHOLE

! Step 2: Configure access ports
interface GigabitEthernet0/1
 description Workstation-port
 switchport mode access
 switchport access vlan 10
 switchport nonegotiate
 spanning-tree portfast
 spanning-tree bpduguard enable

! Step 3: Configure trunk ports
interface GigabitEthernet0/24
 description Trunk to core switch
 switchport trunk encapsulation dot1q
 switchport mode trunk
 switchport trunk native vlan 99
 switchport trunk allowed vlan 10,20,30,40
 switchport nonegotiate

! Step 4: Disable unused ports
interface range GigabitEthernet0/12-23
 switchport mode access
 switchport access vlan 999
 shutdown

Preventing VLAN hopping

VLAN hopping is an attack where an attacker sends traffic to a different VLAN. Two variants:

1. Switch spoofing: the attacker pretends their port is a trunk via DTP (Dynamic Trunking Protocol)
2. Double tagging: the attacker sends frames with two 802.1Q tags, where the switch strips the first tag and forwards the frame to the VLAN of the second tag

Defense:

! Disable DTP on ALL access ports
interface GigabitEthernet0/1
 switchport nonegotiate

! Change native VLAN on trunks (not VLAN 1)
interface GigabitEthernet0/24
 switchport trunk native vlan 99

! Tag native VLAN traffic on trunks
vlan dot1q tag native

! Do not allow unused VLANs on trunks
interface GigabitEthernet0/24
 switchport trunk allowed vlan 10,20,30,40

The golden rule: switchport nonegotiate on every port. DTP is an attack vector that should no longer exist in 2026.

Firewall Rules

Default deny

The most important rule: default deny, inbound and outbound. Most firewalls are "default allow outbound" — precisely why unwanted command-and-control channels are so easily established.

iptables (Linux)

#!/bin/bash
# Base rules: default deny with explicit allow

# Flush existing rules
iptables -F
iptables -X

# Default policy: DROP everything
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

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

# Allow established/related connections
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# SSH inbound only from management VLAN (10.0.30.0/24)
iptables -A INPUT -p tcp --dport 22 -s 10.0.30.0/24 -j ACCEPT

# HTTP/HTTPS outbound only via proxy (10.0.30.10)
iptables -A OUTPUT -p tcp --dport 3128 -d 10.0.30.10 -j ACCEPT

# DNS outbound only to internal DNS (10.0.30.53)
iptables -A OUTPUT -p udp --dport 53 -d 10.0.30.53 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 53 -d 10.0.30.53 -j ACCEPT

# NTP outbound only to internal NTP
iptables -A OUTPUT -p udp --dport 123 -d 10.0.30.123 -j ACCEPT

# Log and drop the rest
iptables -A INPUT -j LOG --log-prefix "FW-DROP-IN: " --log-level 4
iptables -A OUTPUT -j LOG --log-prefix "FW-DROP-OUT: " --log-level 4
iptables -A INPUT -j DROP
iptables -A OUTPUT -j DROP

nftables (Linux, modern replacement)

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;
        iif "lo" accept
        ct state established,related accept
        ip saddr 10.0.30.0/24 tcp dport 22 accept
        icmp type echo-request limit rate 5/second accept
        log prefix "nft-drop-in: " counter drop
    }
    chain output {
        type filter hook output priority 0; policy drop;
        oif "lo" accept
        ct state established,related accept
        ip daddr 10.0.30.53 udp dport 53 accept
        ip daddr 10.0.30.123 udp dport 123 accept
        ip daddr 10.0.30.10 tcp dport 3128 accept
        log prefix "nft-drop-out: " counter drop
    }
    chain forward {
        type filter hook forward priority 0; policy drop;
    }
}

pf (BSD / macOS)

# /etc/pf.conf
mgmt_net = "10.0.30.0/24"
dns_srv  = "10.0.30.53"
proxy    = "10.0.30.10"

set block-policy drop
set skip on lo0
block log all
pass on lo0
pass out quick inet proto { tcp udp } keep state
pass in on egress proto tcp from $mgmt_net to any port 22
pass out on egress proto { tcp udp } to $dns_srv port 53
pass out on egress proto tcp to $proxy port 3128

Windows Firewall (PowerShell)

# Default deny inbound (default on Windows, but verify)
Set-NetFirewallProfile -Profile Domain,Public,Private `
    -DefaultInboundAction Block `
    -DefaultOutboundAction Block `
    -Enabled True

# Block SMB inbound on workstations
New-NetFirewallRule -DisplayName "Block SMB In" `
    -Direction Inbound -LocalPort 445 -Protocol TCP -Action Block

# Block WinRM inbound on workstations
New-NetFirewallRule -DisplayName "Block WinRM In" `
    -Direction Inbound -LocalPort 5985,5986 -Protocol TCP -Action Block

# Block RPC inbound on workstations
New-NetFirewallRule -DisplayName "Block RPC In" `
    -Direction Inbound -LocalPort 135 -Protocol TCP -Action Block

# Allow DNS outbound only to internal DNS
New-NetFirewallRule -DisplayName "Allow DNS Out" `
    -Direction Outbound -RemotePort 53 -Protocol UDP `
    -RemoteAddress 10.0.30.53 -Action Allow

# Block direct DNS to external
New-NetFirewallRule -DisplayName "Block External DNS" `
    -Direction Outbound -RemotePort 53 -Protocol UDP `
    -RemoteAddress Any -Action Block

Every drop rule must log. Firewall rules without logging are invisible. Use log prefixes (FW-DROP-IN:, FW-DROP-OUT:) and send them to your SIEM.

ACL best practices

Poorly written ACLs are worse than no ACLs — they provide a false sense of security.

Specific over generic

! WRONG: too broad
access-list 100 permit ip 10.0.10.0 0.0.0.255 10.0.20.0 0.0.0.255

! CORRECT: only what is needed
access-list 100 permit tcp 10.0.10.0 0.0.0.255 host 10.0.20.5 eq 443
access-list 100 permit tcp 10.0.10.0 0.0.0.255 host 10.0.20.6 eq 3306

Documentation of every rule – ticket number, requester, approval, and review date for every ACL entry.

Regular review – every quarter. Remove rules that are no longer needed. Rules with zero hits in 90 days are candidates for removal (show access-list on Cisco, iptables -L -v -n on Linux).

Egress filtering – the most forgotten form. Block direct HTTP/HTTPS outbound, force proxy. Every uncontrolled outbound connection is a potential C2 channel.

Microsegmentation

Firewall rules on individual hosts or workloads, regardless of their location in the network.

Host-based firewalls on every server

# Web server: only HTTP/HTTPS inbound, only DB outbound
nft add rule inet filter input tcp dport { 80, 443 } accept
nft add rule inet filter output ip daddr 10.0.50.10 tcp dport 3306 accept
nft add rule inet filter output ct state established,related accept
nft add rule inet filter output drop

# Database: only traffic from the web server
nft add rule inet filter input ip saddr 10.0.20.5 tcp dport 3306 accept
nft add rule inet filter input ct state established,related accept
nft add rule inet filter input drop

Service mesh and container environments

# Kubernetes NetworkPolicy: only frontend may access backend
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-allow-frontend
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080
  policyTypes:
    - Ingress

Windows IPsec isolation

# Require Kerberos authentication for all traffic
New-NetIPsecRule -DisplayName "Require Auth" `
    -InboundSecurity Require -OutboundSecurity Request `
    -Phase1AuthSet (New-NetIPsecAuthProposal -Machine -Kerberos).Name

Platform-specific tools

Monitoring & Validation

Segmentation without validation is assumption. You think it works, but you do not know.

Firewall log analysis

# Top 10 blocked sources
grep "FW-DROP-IN" /var/log/firewall.log \
    | awk '{for(i=1;i<=NF;i++) if($i ~ /^SRC=/) print $i}' \
    | sort | uniq -c | sort -rn | head -10

Network flow monitoring

NetFlow/sFlow provide insight into traffic patterns: create a baseline of normal traffic between zones, detect deviations (workstation-to-workstation on port 445 is almost always suspicious), and monitor volume anomalies that could indicate data exfiltration.

Segmentation testing

# From workstations: can I reach the database?
nmap -Pn -p 3306 10.0.50.10        # Expected: filtered
# From workstations: can I RDP to the DC?
nmap -Pn -p 3389 10.0.50.1         # Expected: filtered
# From the DMZ: can I scan internal?
nmap -Pn -sn 10.0.10.0/24          # Expected: unreachable

Run these tests regularly. Networks change. "Temporary" exceptions become permanent.

Purple team validation

Combine the attack commands from this handbook with your segmentation rules:

1. Try lateral_wmi from the workstations VLAN to the servers — is it blocked?
2. Try a simulated unwanted tunnel from the DMZ to internal — does egress filtering work?
3. Try a simulated DNS tunnel from a server — is this detected?
4. Try lateral_psremoting between workstations — is peer-to-peer traffic blocked?

If any of these tests succeeds, your segmentation is not effective for that scenario.

Common Mistakes

Checklist

There is a phenomenon in the IT world that I call the "Mondrian effect." It goes like this: a consultant is hired. That consultant creates a beautiful network diagram. Colored blocks. Clean lines. DMZ in red. Internal zone in blue. Management in green. Restricted zone in purple. It is a work of art. It hangs framed on the wall of the server room.

Meanwhile, the intern can ping the domain controller from their workstation. The printer in the hallway is in the same VLAN as the payroll administration. The "temporary" any-any rule for that one project from 2019 is still there. And the firewall that cost 200,000 euros functions in practice as an expensive switch with a nice dashboard.

"We are going to segment" is the IT equivalent of "we are going to refactor." It is on the roadmap. It has a Jira ticket. There is a high-level design. But there is never budget, never time, and never buy-in. Because segmentation means things break. Applications that rely on the flat network stop working. Users call the helpdesk. Managers write angry emails. And before you know it, someone decides that "we will roll back the segmentation until after the go-live" — and that go-live is never.

The best part is the incident reports afterward. "The attacker was able to move laterally through the network." No. The attacker was not able to do that because they were so clever. The attacker was able to do that because your network was so flat you could fry a pancake on it. The domain controller was reachable from the guest WiFi. The backup server accepted SMB from the entire /16. The "firewall" was on monitor-only.

Segmentation is boring. It does not generate nice dashboards. It does not win security awards. It does not produce LinkedIn posts about "innovative zero trust architectures." It produces helpdesk tickets and angry phone calls from department heads who can no longer access their shared drive. But it is the difference between "the attacker compromised a workstation" and "the attacker owns the entire network."

Choose your discomfort: segment now, or write the incident report later.

Summary

Network segmentation is the most effective and most neglected defense against lateral movement. A well-segmented network with default deny firewalls, separate VLANs for workstations, servers, management, and DMZ, and egress filtering on every zone, renders the vast majority of attack techniques in this handbook unusable. The implementation requires discipline: disable DTP, change native VLANs, document every ACL, perform quarterly reviews, and actually test segmentation with the tools attackers use. Microsegmentation via host-based firewalls and container network policies adds an extra layer that protects even when network segmentation fails. It is not glamorous. It does not generate nice dashboards. But it works — provided you do it. And that "provided" is where most organizations get stuck.