Haxoris Wiki

Flat Networks And Missing Segmentation

How Flat Networks And Missing Segmentation works

A flat network lets any host in the user VLAN open a session to any other host in the estate, because no zone boundary filters traffic between them. It appears in two shapes. The first is one broadcast domain: workstations, servers, printers, cameras and the hypervisor management port share a /16. The second is more common and looks better on paper: VLANs exist, the layer-3 switch or firewall routes between them, and the inter-VLAN policy is a single permit-any rule kept from the migration that created the VLANs.

The gain is blast radius. One phished workstation reaches the backup server, the hypervisor management network, the OT cell and the DMZ, so a single initial foothold is equivalent to a foothold everywhere and the attacker never has to defeat a boundary. It is easy to miss because both shapes pass the questions an audit asks: VLANs are documented, a firewall exists between zones, and the rule base is short. Nobody reads the rule base as a matrix, and no monitoring fires when a control does nothing, so a permit-any line produces exactly the same evidence as a working policy.

Flat Networks And Missing Segmentation in practice

Establish where the test host actually sits

Start from a normal user-VLAN lease so the result reflects what a compromised workstation sees, not what a jump host sees. Read the local addressing and the routes before probing anything.

ip -4 addr show dev eth0
ip route
# broadcast-domain size: how many neighbours answer without crossing a gateway
sudo arp-scan --interface=eth0 --localnet | tee /tmp/arp-localnet.txt

A /16 or larger local prefix, or ARP replies from servers and hypervisor management addresses, means the first shape: no segmentation at all.

Build the reachability matrix zone by zone

Probe one representative service port per zone rather than sweeping every port, so the test is fast, quiet and produces a matrix a defender can read. Use the ranges from the client’s own documentation.

# zones under test, from the authorised scope document
cat > /tmp/zones.txt <<'EOF'
servers    10.10.30.0/24
management 10.10.99.0/24
backup     10.10.50.0/24
ot         10.20.10.0/24
dmz        192.168.50.0/24
EOF

while read -r zone cidr; do
  echo "== $zone $cidr"
  nmap -Pn -n --open -T3 -p 22,445,3389,5985,161,502 "$cidr" -oN "/tmp/matrix-$zone.txt"
done < /tmp/zones.txt

Keep the OT range read-only and rate-limited: use -T2 --max-retries 1 and drop port 502 entirely if the scope document does not explicitly permit probing controllers, because a scan is enough to disturb some PLCs.

Record the matrix as the finding

A segmentation finding is a zone pair, not a port. Reduce each scan to a single row per zone so the report argues about boundaries rather than about services.

source: 10.10.20.57 (user VLAN, standard DHCP lease)

zone         cidr              22    445   3389  5985  161   502   verdict
-----------  ----------------  ----  ----  ----  ----  ----  ----  ---------------------------
servers      10.10.30.0/24     open  open  open  open  -     -     expected, in the matrix
management   10.10.99.0/24     open  -     -     -     open  -     FINDING: switch and iLO
backup       10.10.50.0/24     open  open  -     -     -     -     FINDING: backup catalogue
ot           10.20.10.0/24     -     -     -     -     -     open  FINDING: Modbus across zones
dmz          192.168.50.0/24   -     open  open  -     -     -     FINDING: DMZ path is two-way

Any row outside the documented matrix is a segmentation finding regardless of whether the service itself is patched. The management row is the one to escalate first, and what each of those consoles then exposes is enumerated on the Exposed Management Interfaces page.

Read the rule base that produced the matrix

The scan shows the symptom; the rule base shows the cause and gives the defender the exact line to change. Pull the policy and look for the wildcard pair.

! layer-3 switch, inter-VLAN ACL applied to Vlan20 (user)
ip access-list extended USER_OUT
 permit ip any any
!
! FortiGate equivalent worth grepping for
config firewall policy
    edit 12
        set srcintf "vlan20-user"
        set dstintf "any"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set service "ALL"
    next
end

Collect it read-only with show running-config | section access-list or the vendor’s config export. A permit ip any any on the user zone, or a policy whose destination interface is any, is the single line that makes every VLAN in the diagram cosmetic.

How to fix and prevent Flat Networks And Missing Segmentation

  1. Write the access matrix before touching a rule base
    • One row per zone pair, one column per permitted service, owner named for each entry.
    • Anything not on the matrix is the removal backlog, in priority order.
  2. Run the target policy in log-only mode first
    • Apply a default-deny policy that only logs, for one business cycle, so the real flow list is measured rather than guessed.
    • Partial control while it logs: nothing is blocked yet, so it reduces no risk until enforcement is switched on.
  3. Remove the user VLAN’s path to management, backup and OT completely
    • These zones carry no user traffic, so they are the cheapest boundaries to close and the largest reduction in blast radius.
    • Reach them through a jump path with its own authentication instead of a routed rule.
  4. Isolate hosts inside the user VLAN
    • Private VLANs or switchport protected mode stop workstation-to-workstation traffic, which no business flow needs and every lateral tool does.
  5. Keep the reachability probes as a regression test
    • Re-run the matrix scan after every firewall change, merger and site rollout, and diff against the approved matrix.

Last updated

References