Guest Wi-Fi Reached the ERP Database in Four Minutes

Prioritise by exposure multiplied by ease of change, not by how important a system feels.

Before Saturday, same day: push an ACL on the existing switch blocking guest subnet to RFC1918 addresses on 1433, 3389, 445 and 22. This is a ten-minute change that kills the demonstrated attack path without waiting for the window.

Saturday, in order:

1. Guest Wi-Fi into its own VLAN with a deny-to-internal rule and internet-only access, plus a separate DHCP scope. Highest exposure, lowest operational risk if it breaks.
2. Cameras into an IoT VLAN. They are unpatchable, often have vendor cloud tunnels, and have no business talking to servers.
3. Servers into a server VLAN with an explicit port matrix (who needs 1433, from where). This is the most likely to break something, so it needs an application owner testing on the day and a written rollback config.
4. Scanners last, after the vendor is available.

Inter-VLAN routing stays on the L3 switch with a default-deny posture; the edge firewall should not be the only enforcement point. Deferring scanners is correct because their vendor dependency makes the change irreversible on the day.

It belongs in a DMZ segment, not in the server VLAN and definitely not on the flat network. It is the one asset deliberately exposed to untrusted parties; its compromise should be a contained event rather than a foothold next to the ERP database.

Rule logic:

• Inbound: allow TCP 21 and the configured passive data range only from the three partner public IP addresses, not from 'any'. If a partner cannot supply stable IPs, that is a business conversation, not a reason to open it to the world.
• Outbound from the DMZ host: deny to the internal server VLAN by default. If the EDI files must land on a file share, allow a single destination host on a single port, initiated from the FTP host, and consider a scheduled pull instead of a push so the DMZ never initiates inward.
• No domain membership for the DMZ host, or at minimum no reusable domain credentials cached on it. Local accounts with unique passwords.
• Logging: retain authentication and file-transfer logs, and alert on failed logins above a threshold.

The outbound rule is the one teams forget. An FTP server that can reach the whole internal network from a compromised account gives an attacker the same flat network you just paid to remove.

Assume nothing about how the scanners get their addressing until you have checked whether they are static or DHCP - vendor-configured handhelds are often static, which is why a VLAN move silently breaks them.

Plan:

• Pre-stage the new VLAN and SVI, with DHCP relay and reservations keyed to scanner MAC addresses if they are DHCP clients.
• Keep the old VLAN SVI alive as a secondary address during the transition so devices physically on the old access ports still resolve their gateway. Move access ports in small batches, ideally by aisle.
• If static: change the VLAN on the port, keep the gateway reachable via the old SVI, then re-address devices in batches with the vendor's tooling once available.
• Prepare a one-line rollback: the port config revert is saved before any change.

Verification before Monday:

• Ping sweep of the new subnet plus a check of the switch MAC address table against the known scanner inventory count.
• Have a warehouse lead perform a real pick-and-scan transaction on three devices in different aisles, not a synthetic test.
• Confirm the scanners cannot reach the server VLAN on any port other than the ERP port they need, tested from a spare handheld.

If the inventory count does not match, revert that batch rather than troubleshooting during shift.