Five Minutes and an Empty Port Part 10: The Closing Checklist and a Vendor Comparison
Ten parts ago this series opened with a five-minute Shark Jack drop and a fifty-dollar bill of materials. Parts 7 through 9 answered it: port security and Layer 2 hygiene, 802.1X with a real NAC platform behind it, and the narrower controls, MAC filtering, USB device control, wireless IDS, that close the remaining gaps. This part closes the series with a checklist worth actually running against a real network, and a straight comparison of how the four vendors this site covers most implement each piece.
The checklist
Every item below was the direct answer to something in Parts 2 through 6, not a generic best-practice list assembled separately from the attack side of this series.
Every unused port is administratively shut down and dropped into an unrouted VLAN. This alone would have stopped Part 6’s Shark Jack recon before it produced anything useful.
Port security is enabled on every access port, with sticky MAC learning and a sensible max count. Answers the wired dropbox directly: a Packet Squirrel or LAN Turtle inline behind a phone still needs to present a MAC address the port already trusts.
DHCP snooping, Dynamic ARP Inspection, and IP Source Guard are enabled together, not piecemeal. The three depend on the same binding table and are weaker individually than as a set.
The native VLAN on every trunk is changed off VLAN 1 and left unused.
802.1X is enabled with a real authentication server behind it, EAP-TLS where certificate deployment is feasible, PEAP-MSCHAPv2 where it isn’t, MAB configured only as an explicit, profiled fallback rather than a default.
A NAC platform is actually doing something with the identity 802.1X establishes, posture checks, dynamic VLAN or dACL assignment, device profiling for the MAB devices that can’t authenticate any other way.
MAC OUI filtering, where it’s used at all, is treated as one signal among several, never the access decision itself.
USB device control is enforced at the endpoint, Windows Group Policy or WDAC, Linux udev rules or USBGuard, macOS MDM profiles, closing the one vector in this whole series that no network-layer control ever touches.
Wireless IDS is watching for rogue BSSIDs and abnormal deauthentication volume, the one attack in Part 4 that MAC randomization never slowed down.
How the four vendors implement it
| Control | Cisco | Fortinet | Juniper | Arista |
|---|---|---|---|---|
| Port security | switchport port-security (IOS/IOS-XE) | FortiSwitch mac-limit via FortiLink | Junos EX secure-access-port | EOS port security, MAC address limiting |
| First Hop Security (DHCP snooping/DAI/IPSG) | Native IOS-XE feature set | FortiSwitch/FortiGate via FortiLink | Junos EX DHCP snooping and ARP inspection | EOS DHCP snooping and dynamic ARP inspection |
| 802.1X + NAC | dot1x + Cisco ISE | FortiSwitch dot1x + FortiNAC | Junos dot1x + Mist Access Assurance | EOS dot1x, typically paired with a third-party NAC platform rather than an in-house one |
| MAC/OUI filtering | MAC ACLs (switch and WLC) | FortiSwitch/FortiAP MAC allow/deny lists | MAC-based VLAN assignment on EX | EOS MAC access lists |
| Wireless IDS/WIPS | aWIPS on Catalyst 9800 | FortiAP rogue AP suppression via FortiGate | Mist WIDS/WIPS | CV-CUE (from the Mojo Networks acquisition) |
| USB device control | Endpoint-level, not a network-vendor feature | FortiClient EMS device control policies | Endpoint-level, not a Juniper product area | Endpoint-level, not a network-vendor feature |
Worth being direct about the one real gap in that table: Arista’s NAC story is the least mature of the four. Cisco, Fortinet, and Juniper each have a flagship, purpose-built NAC platform, ISE, FortiNAC, Mist Access Assurance. Arista’s approach leans on CloudVision for visibility and typically pairs EOS 802.1X with a third-party NAC platform rather than shipping an equivalent in-house product. Not a flaw in EOS’s port-level enforcement, which is solid, just a genuine difference worth knowing before assuming feature parity across the board.
USB device control appearing as “endpoint-level” across every network vendor is not an oversight in the table, it’s the point Part 9 made directly: no switch or firewall vendor can see a USB HID device typing into a keyboard buffer, because the operating system never asks the network layer for permission in the first place. That control has to live on the endpoint regardless of which of these four vendors runs the wire.
Closing the loop
Part 1 opened on a simple premise: five minutes and an empty port is still enough, in 2026, to get a foothold on most networks, because the hardware costs less than a takeaway coffee and the techniques haven’t meaningfully changed in over a decade. Parts 7 through 9, and the checklist above, are the actual answer to that premise, and every item on it is something most of the switches and firewalls already sitting in a rack can do today, not a purchase order away. The gap this series has been describing the whole way through was never a technology gap. It was a configuration gap, and closing it is mostly a matter of turning on what’s already there.