Dormitory Rogue Routers Hijacking the Campus SSID
A university dormitory campus has 180 APs across six buildings managed by an AC in the core, with 802.1X used for staff and a captive-portal guest SSID for students, and WIDS enabled on all APs. Over two weeks, helpdesk tickets spike: students connect successfully but receive 192.168.0.x addresses, cannot reach the portal, and sometimes see a certificate or login page they do not recognise. Investigation finds students plugging consumer routers into wall ports and configuring the SSID to match the official campus SSID with open security. Some affected students associate to these devices unknowingly. The network team proposes enabling active countermeasures against every detected rogue device immediately, across all buildings, around the clock.
1. Describe how you would detect and positively identify these devices as rogue (on-network) rather than merely interfering, and what data you need before acting.
Read the worked answer
Classification first. WIDS distinguishes an interfering device (a foreign AP whose BSSID is not seen on the wired network) from a rogue device (an AP whose BSSID or associated wired MAC is seen on the infrastructure). Only the second is a security incident requiring wired action.
Detection sources:
- WIDS/air scan on the APs: the rogue AP list shows BSSID, SSID, channel, RSSI and the monitoring APs. Matching SSID to the campus SSID with open security is an immediate flag, but SSID matching alone can implicate a legitimate neighbouring campus, so do not act on it alone.
- Wired correlation: take the rogue BSSID or the client MACs behind it and look them up in the switch MAC address table to find the access port and VLAN. A BSSID that maps to a dorm wall port confirms an on-network rogue.
- DHCP evidence: the 192.168.0.x leases plus the rogue's gateway address identify which device is serving DHCP. Check the legitimate DHCP server logs for the affected MACs - no lease means someone else answered.
- Client-side evidence: the unrecognised portal or certificate warning is consistent with a device intercepting the captive-portal flow.
Before acting, record: BSSID(s), SSID, channel, serving switch and port, VLAN, first/last seen, affected client count, and whether the device is in student rooms or a common area. Without the switch port you cannot remediate precisely, and without timestamps you cannot prove the incident.
2. The team wants active countermeasures against every detected rogue, everywhere, continuously. Evaluate that proposal and recommend a safer response.
Read the worked answer
Do not blanket-enable active countermeasures. Problems with the proposal:
- Collateral damage: countermeasure frames are sent on the rogue's channel and can disrupt any client in range - including neighbouring institutions' legitimate APs, dorm residents' personal devices, and the campus's own clients if the classification is wrong.
- Regulatory exposure: transmitting deauthentication frames at a device you do not own may breach radio regulations in many jurisdictions; containment policy must be reviewed before it is switched on.
- Persistence: a student router will simply be re-plugged; countermeasures fight the symptom, not the port.
- Scale: 180 APs across six buildings generating continuous countermeasures will degrade the WLAN the team is trying to protect.
Recommended response, in order:
- Wired containment: shut down or apply a restrictive VLAN/ACL to the identified wall port, and notify the resident. This is precise, legal, and durable.
- Wireless containment only as a targeted, time-boxed action for a confirmed rogue on a known port in a specific building, with a defined start and stop, and after confirming the target is not a neighbour's legitimate AP.
- Prioritise by impact: rogues using the campus SSID with open security, or serving DHCP, are incidents; a random home SSID is noise.
- Automate alerting, not just blocking: alarm to the NOC with BSSID and switch port so a human confirms before any transmit action.
Document the policy: what is auto-alarmed, what requires approval, and who may authorise containment.
3. Design the preventive controls that would stop this recurring next semester, covering both the wired and wireless sides.
Read the worked answer
Wired side - stop the device joining the network:
- 802.1X on all dorm wall ports with MAC authentication fallback for devices that cannot supplicate, plus MAB profiling so an unknown consumer router is placed in a quarantine VLAN rather than a student VLAN.
- Port security: limit MAC addresses per port (typically 1–2) and configure the violation action to restrict rather than to silently forward. A router NATing many clients behind one MAC still fails the profile check.
- Disable unused wall ports in unoccupied rooms and common areas.
- DHCP snooping + IP source guard on access switches so an unauthorised DHCP server cannot hand out leases inside the student VLAN.
- NAC/profiling to fingerprint consumer router OUIs and DHCP server behaviour, and quarantine automatically.
Wireless side:
- Keep WIDS enabled with rogue and interference classification, tuned so alarms are actionable, and integrate the rogue list with the switch MAC-table lookup to speed identification.
- Consider management frame protection (802.11w) on the student SSID, which raises the cost of spoofing the campus SSID, and ensure the captive portal is validated (HTTPS with a trusted certificate) so students can recognise a fake portal.
- Monitor and report rogue counts per building weekly; a rising trend signals a policy problem, not a technology problem.
People: publish a clear policy that personal routers are prohibited, provide a legitimate way to connect extra devices, and give the helpdesk a script that identifies a rogue from the SSID/DHCP symptom and escalates with the switch port.