Network Segmentation Audit: How to Review Firewall Rules and VLAN Configurations to Find the Paths That Defeat Your Segmentation Design

Before reviewing individual rules, document what the segmentation design intends:

1. Zone map: List every network zone (DMZ, production servers, workstations, management, OT/ICS, guest WiFi, PCI scope). For each zone, document the VLAN IDs, IP ranges, and the trust level.

2. Permitted flow matrix: For each zone pair, document what traffic should be permitted and what must be blocked. Example:

| Source Zone      | Destination Zone  | Permitted Ports           | Direction |
|-----------------|-------------------|--------------------------|----------|
| Workstations    | Production Servers| 443, 8443 (HTTPS)        | Outbound  |
| Workstations    | Production Servers| 445, 3389, 22            | BLOCKED   |
| Production Srv  | Database          | 1433 (SQL), 5432 (Postgres) | Outbound |
| Database        | Internet          | ALL                       | BLOCKED   |
| Management      | All zones         | 22, 3389, 443, 161        | Both      |

1. Enforcement points: Identify every device enforcing segmentation -- perimeter firewalls, internal firewalls between zones, host-based firewalls (Windows Firewall, iptables), cloud security groups, and network ACLs on switches.

The audit cross-references the actual rule set at each enforcement point against the permitted flow matrix.

Export the rule set from your firewall platform and analyze for high-risk patterns:

Finding any-any rules (Palo Alto example):

# Palo Alto Panorama/NGFW -- show rules matching any-any
show running security-policy | match "any"
# Or via API:
curl -k -G "https://firewall/api/" \
  --data-urlencode "type=op" \
  --data-urlencode "cmd=<show><running><security-policy></security-policy></running></show>" \
  --data-urlencode "key=$API_KEY"

For Cisco ASA, export the running config and parse:

# Extract all permit-any rules from ASA config
grep -n "permit any any" running-config.txt
grep -n "access-list.*permit ip any any" running-config.txt

For iptables (Linux host-based):

# Find any ACCEPT rules with broad scope
iptables -L -n -v | grep -v ESTABLISHED | grep ACCEPT
# Look for rules with 0.0.0.0/0 source or destination in ACCEPT chains

For each overpermissive rule found, determine:

1. When it was added (check firewall change logs or git history if rules are in version control)
2. What application or operational need it was created for
3. Whether a narrower rule can replace it
4. Whether the original need still exists

Rules with zero hits in 90+ days are candidates for removal (after verification they are not needed for rare traffic patterns):

Palo Alto (PAN-OS):

# Show hit counts for all security policies
show rule-hit-count vsys vsys1 security pre-rulebase security rules all

# Rules with zero hits
show rule-hit-count vsys vsys1 security pre-rulebase security rules all | match " 0 "

Fortinet FortiGate:

# Show policy hit counts
get firewall policy | grep -A5 "policyid"
diagnose firewall iprope show 100004  # Shows hit counts per policy

Cisco ASA:

show access-list | include access-list.*[0-9] hitcnt=0
# Rules with hitcnt=0 have never matched traffic since last counter reset

For each zero-hit rule:

1. Check whether traffic that the rule was designed to permit is actually flowing through the firewall via a different path (the rule may be shadowed by a broader rule above it)
2. Check with application owners whether the use case the rule was created for is still operational
3. Create a cleanup ticket with a 30-day hold period -- disable the rule first, monitor for any application breaks, then remove

Document every rule removed with the original ticket that created it (if known), the removal date, and the approver.

Documentation review is insufficient -- validate actual network connectivity matches the intended design:

From a workstation in the workstation VLAN, test that these connections are blocked:

# Test-NetConnection verifies TCP connectivity
Test-NetConnection -ComputerName 10.10.20.5 -Port 445  # SMB to server -- should FAIL
Test-NetConnection -ComputerName 10.10.20.5 -Port 3389  # RDP to server -- should FAIL
Test-NetConnection -ComputerName 10.10.30.5 -Port 1433  # SQL to DB -- should FAIL

# Test that permitted connections work
Test-NetConnection -ComputerName 10.10.20.5 -Port 443   # HTTPS to server -- should SUCCEED

From a production server, test that internet access is blocked if intended:

# On Linux server
curl -m 5 https://api.ipify.org  # Should fail if internet access is blocked
nc -zv 8.8.8.8 53 2>&1  # DNS to Google -- should fail if external DNS is blocked

Testing east-west controls between servers in the same subnet: East-west traffic within the same VLAN typically does not traverse the firewall at all. If host-based firewall or micro-segmentation (NSX-T, Calico, Azure NSG) is the east-west control, test directly between two servers:

nmap -sS -p 445,3389,22,5985 10.10.20.0/24  # Scan the server subnet from another server
# Any open port that is not in the permitted flow matrix is a finding

Document the test date, the testing account, and the results in a test matrix table. Run the same tests after each major firewall change.

Ransomware lateral movement uses SMB (port 445) and WMI/RPC to spread from an initial foothold. Effective ransomware containment through segmentation requires:

1. Block workstation-to-workstation SMB (east-west) Most environments allow workstations to communicate freely within the workstation VLAN. This enables ransomware to spread from one infected workstation to every other workstation on the segment.

Fix: Deploy Windows Defender Firewall via GPO to block inbound SMB on all workstations except from the IT management subnet:

GPO: Computer Configuration > Windows Settings > Security Settings > Windows Firewall
Inbound rule: Block TCP 445 from source = Any, except management VLAN IP range

2. Block workstations from reaching backup storage directly Ransomware encrypts backup shares if the workstation tier can reach the backup VLAN. Ensure:

• Backup storage VLAN has a perimeter firewall rule blocking all access from the workstation VLAN
• Backup agent pull model (backup server pulls from workstation) rather than push model (workstation pushes to backup server) eliminates the need for inbound connectivity to backup storage

3. Segment OT/ICS from IT If IT and OT networks share a firewall, verify that the OT network cannot be reached from the workstation VLAN at all. OT network compromises via lateral movement from IT have caused multiple critical infrastructure incidents.