I85PREP
⌘ K
CompTIA Network+ study materials
CompTIA Network+ study resources

The Rogue DHCP Server on the Third Floor

CompTIA Network+ · Put your knowledge to work in context.

All case studies

The Rogue DHCP Server on the Third Floor

Third-floor users at a 500-person office can reach the internet but not internal file shares. ipconfig shows 192.168.1.57/24 with gateway 192.168.1.1, on a floor that should be 10.10.30.0/24. The floor has one 48-port access switch with no port security and no DHCP snooping, and wired and wireless clients share a single VLAN - the wireless controller bridges clients onto it. A facilities vendor was on site two days earlier installing a networked label printer. About 40 of roughly 120 users are affected; others on the same floor work normally. The core firewall permits all traffic from 10.10.30.0/24 to internal networks and treats the third floor the same as every other floor.

1. Give the immediate containment steps in the order you would perform them, and explain what evidence each step produces.

Read the worked answer
  1. Confirm the scope. Collect ipconfig /all from several affected machines. If the lease server field points at something other than the known DHCP server, you have a rogue and its IP. If the lease server is correct and only the address is odd, this is a different problem (a static misconfiguration or a second scope).
  2. Locate the rogue by MAC, not by guessing. From an affected PC, ARP for the gateway address (192.168.1.1) and read the MAC. Then search the access switch's MAC address table for that MAC. If it is learned on an access port, you have the physical port; if it is learned via the wireless controller uplink, the source is a wireless client and you need the controller's client table.
  3. Disable the port (or blackhole the wireless client) rather than shutting random ports. That stops new bad leases while keeping the search evidence intact.
  4. Restore clients. Affected hosts keep their bad lease until it expires; force a release/renew or bounce the port so they obtain addresses from the real server. This is why the symptom persisted for hours after the device appeared.
  5. Preserve the device. Photograph it, record the port, serial, and configuration before returning it to the vendor - you need to know whether it was a default-config DHCP server or a deliberate act.

Do not skip step 2. Shutting ports until the problem stops is a common reflex that causes a second outage and destroys the evidence trail.

2. A colleague argues the incident proves the floor needs its own VLAN. Explain why VLAN separation alone would not have prevented this and what control set would.

Read the worked answer

A VLAN is a broadcast domain, not a security boundary. The rogue device was physically plugged into a port that was already in the users' VLAN, so it was Layer 2 adjacent to every victim no matter how many VLANs exist. VLANs only help if the unmanaged device is placed in a different VLAN - which requires knowing what it is before it connects.

The controls that actually stop this:

  • DHCP snooping with only the real server's uplink marked trusted. Untrusted ports cannot offer DHCP; the rogue's OFFER is dropped at the switch and clients keep their legitimate address. Add option-82 for subscriber identification.
  • Dynamic ARP Inspection paired with snooping, so a rogue cannot poison the gateway mapping after failing at DHCP.
  • Port security / MAC limiting and disabling unused ports so a device cannot appear on an arbitrary port unnoticed.
  • 802.1X or MAB on access ports. A vendor laptop or printer that authenticates receives a restricted, profiled VLAN - that is the mechanism that puts unknown devices somewhere harmless.
  • Spanning-tree BPDU guard on edge ports, since many of these devices also ship with a switch and a DHCP server in one box.

Note the firewall gap too: it permitted all 10.10.30.0/24 traffic internally, so even a properly-placed rogue on that VLAN would have had broad access. Segmentation without filtering is decoration.

3. Design the segmentation for the label printer and similar facilities devices, and say exactly where the policy is enforced.

Read the worked answer

Placement

  • A dedicated untrusted/IoT VLAN (e.g. 10.10.90.0/24) for label printers, badge readers, cameras, and building systems. The vendor device goes here via a profile assigned by MAB/802.1X, not by someone remembering to patch it to a special port.
  • Facilities devices get DHCP reservations rather than static addresses, so they survive addressing changes and appear in the lease table - a searchable inventory is itself a control.

Policy

  • Default deny in both directions between IoT and user/voice/server VLANs.
  • Permit only the flows required: IoT → print server on the specific ports used; the print server → IoT for status. No IoT → internet unless there is a documented update mechanism, and if there is, put it behind an explicit allow with logging.
  • Deny inter-VLAN routing between user subnets on the same floor - most normal user traffic should never cross the core.

Where it is enforced

  • Primarily on the Layer 3 SVI / firewall zone, because access-switch ACLs are easy to shadow and inconsistent across 20 closets. One policy point, one place to audit.
  • On the access switch: snooping, DAI, port security, and BPDU guard - Layer 2 hygiene, which the L3 device cannot see.
  • Log denies from IoT to user subnets and alert on volume: repeated attempts are how you find a compromised camera before it becomes an incident.

Also fix the firewall rule that currently allows the whole third-floor subnet to reach everything internally. Flat-permit rules are what turn a mis-plugged device into a floor-wide outage.