This chapter covers rogue DHCP server attacks, a critical network security threat where an unauthorized DHCP server assigns IP configurations to clients, enabling man-in-the-middle attacks, denial of service, and traffic interception. For the N10-009 exam, this topic falls under Domain 4.0 (Network Security), Objective 4.1 (Explain common security concepts). Expect approximately 5-8% of exam questions to touch on DHCP security, including rogue server detection and mitigation. Mastering this topic requires understanding DHCP operation, attack vectors, and defense mechanisms like DHCP snooping and port security.
Jump to a section
Imagine a large office building where employees receive internal mail via a central mailroom. The legitimate mailroom clerk knows which desks belong to which employees and delivers mail accordingly. A rogue clerk sets up a fake mailroom in a supply closet, intercepts incoming mail, and delivers it to wrong desks or steals packages. When an employee sends a request for a package (DHCPDISCOVER), both the legitimate clerk and the rogue clerk respond. The rogue clerk responds faster, offering a fake desk assignment (IP address) and a fake return address (gateway). The employee accepts the fastest offer, and now all outgoing mail goes through the rogue clerk, who can read, modify, or block it. This mirrors a rogue DHCP server: it responds to DHCP requests before the legitimate server, assigning malicious IP configurations (wrong default gateway, wrong DNS) to perform man-in-the-middle attacks. The rogue server must be on the same broadcast domain (VLAN) to hear the DHCPDISCOVER broadcasts, just as the rogue mailroom must be in the same building to intercept mail. Mitigation involves DHCP snooping on switches, which acts like security cameras that verify only authorized mailroom clerks are allowed to respond.
What Is a Rogue DHCP Server Attack?
A rogue DHCP server is an unauthorized DHCP server deployed on a network segment (broadcast domain) that responds to DHCP client requests before the legitimate DHCP server. Because DHCP relies on broadcast discovery (DHCPDISCOVER) and clients accept the first offer (DHCPOFFER) they receive, a rogue server can hijack the IP address assignment process. This allows the attacker to assign:
A malicious default gateway IP (for traffic interception)
A malicious DNS server IP (for phishing or redirection)
A false subnet mask or lease duration (for denial of service)
A false IP address (causing IP conflicts or exhaustion)
How the Attack Works: Protocol-Level Mechanism
DHCPDISCOVER (Broadcast): Client broadcasts a DHCPDISCOVER packet to 255.255.255.255 (UDP port 67 server, port 68 client). The source IP is 0.0.0.0, destination IP 255.255.255.255. The packet includes the client MAC address and a transaction ID (XID).
Race Condition: Both the legitimate and rogue DHCP servers receive the broadcast. The rogue server is often configured to respond immediately (no delay), while legitimate servers may have a small processing delay or be on a remote subnet via DHCP relay.
DHCPOFFER: The rogue server sends a DHCPOFFER with:
- Offered IP address (often from a legitimate range or a conflicting range) - Subnet mask - Default gateway (set to attacker's IP) - DNS server (attacker's IP) - Lease duration (often very short to force frequent renewals) - Server identifier (the rogue server's IP)
Client Acceptance: The client typically accepts the first DHCPOFFER it receives (per RFC 2131, the client may wait for multiple offers but usually picks the first). The client sends a DHCPREQUEST broadcast requesting the offered IP.
DHCPACK: The rogue server sends a DHCPACK confirming the lease. The client configures its IP stack with the malicious parameters.
Traffic Interception: All client traffic destined for the default gateway or DNS now goes to the attacker's machine, which can forward it to the real gateway (man-in-the-middle) or drop it (DoS).
Key Components, Values, and Defaults
DHCP Ports: UDP 67 (server), UDP 68 (client)
Broadcast Address: 255.255.255.255
Transaction ID (XID): 32-bit random number to match requests and responses. The rogue server must use the same XID as the client's DISCOVER to be accepted.
Lease Time: Default 8 days on many servers (e.g., Windows Server), but rogue servers often set 5-10 minutes to force frequent renewals.
DHCP Message Types: 8 types defined in RFC 2131: DISCOVER (1), OFFER (2), REQUEST (3), DECLINE (4), ACK (5), NAK (6), RELEASE (7), INFORM (8).
DHCP Snooping: The Primary Defense
DHCP snooping is a switch feature (IEEE 802.1Q / Cisco proprietary) that filters untrusted DHCP messages. It acts as a firewall between trusted DHCP servers and untrusted ports (client-facing ports).
How DHCP Snooping Works:
Trusted vs. Untrusted Ports: Ports connected to legitimate DHCP servers are configured as trusted. All other ports (client ports) are untrusted.
Message Filtering: On untrusted ports, DHCP snooping drops:
DHCPOFFER, DHCPACK, DHCPNAK (server-to-client messages) — because a client should never send these.
DHCPRELEASE, DHCPDECLINE (client messages that could be spoofed).
DHCP packets with a source MAC that doesn't match the client's chassis MAC (MAC spoofing protection).
Rate Limiting: DHCP snooping can rate-limit DHCP packets per port to prevent DHCP starvation attacks.
DHCP Snooping Binding Database: The switch maintains a database of valid DHCP leases (MAC address, IP address, VLAN, port, lease time). This database is used by Dynamic ARP Inspection (DAI) and IP Source Guard.
Configuration Example (Cisco IOS):
ip dhcp snooping
ip dhcp snooping vlan 10,20
interface GigabitEthernet0/1
ip dhcp snooping trust
interface GigabitEthernet0/2
ip dhcp snooping limit rate 10Verification Commands:
show ip dhcp snooping
show ip dhcp snooping binding
show ip dhcp snooping statisticsAdditional Mitigation Techniques
Port Security: Limit the number of MAC addresses per port to prevent a rogue server from connecting.
802.1X Authentication: Require device authentication before granting network access.
VLAN Segmentation: Place DHCP servers on separate VLANs and use DHCP relay (ip helper-address) to centralize DHCP services. This reduces the attack surface.
DHCP Server Authorization (Windows): In Active Directory, DHCP servers must be authorized to prevent rogue servers from leasing IPs.
Network Access Control (NAC): Solutions like Cisco ISE can enforce compliance before allowing devices on the network.
Rogue DHCP vs. DHCP Starvation
Rogue DHCP attack involves a malicious server offering IPs. DHCP starvation attack involves flooding the legitimate server with fake DHCPDISCOVER messages to exhaust its IP pool, causing a denial of service. Both can be combined: starvation forces clients to accept offers from the rogue server.
Interaction with Related Technologies
Dynamic ARP Inspection (DAI): Uses DHCP snooping binding table to validate ARP packets. If a rogue server assigns a fake gateway IP, DAI can block ARP replies from that IP.
IP Source Guard: Filters IP traffic on a per-port basis based on the DHCP snooping binding table. Prevents IP spoofing.
DHCP Relay: Uses ip helper-address to forward DHCP broadcasts to a remote server. Rogue servers on the same VLAN still pose a threat because they receive the original broadcast.
Detection of Rogue DHCP Servers
Manual Discovery: Use dhcploc (Windows) or dhcpdump (Linux) to capture DHCP offers and identify unknown server IPs.
Network Scanning: Tools like Nmap can detect open UDP port 67.
SNMP Monitoring: Query switches for DHCP snooping statistics and binding tables.
Syslog Alerts: DHCP snooping logs dropped packets.
Common Attack Tools
Yersinia: A network tool that can act as a rogue DHCP server.
Metasploit: Auxiliary/server/dhcp module.
Custom scripts using Scapy.
Exam Trap: The "First Offer" Rule
Candidates often think the client evaluates offers based on "best" IP or longest lease. Wrong. Per RFC 2131, the client selects the first offer it receives (though it may wait for multiple offers for a brief period). The rogue server wins by responding faster, not by offering better parameters. Also, the rogue server must be on the same broadcast domain (VLAN) to hear the DISCOVER broadcast unless it's connected via a relay agent (uncommon).
Client Broadcasts DHCPDISCOVER
The client sends a DHCPDISCOVER broadcast packet to IP 255.255.255.255, UDP port 67. The source MAC is the client's MAC, source IP 0.0.0.0, destination MAC FF:FF:FF:FF:FF:FF. The packet contains a random transaction ID (XID) and may include a requested IP option. This broadcast is received by all devices in the same VLAN, including the legitimate DHCP server and any rogue server. The client then waits for DHCPOFFER responses.
Rogue Server Responds with DHCPOFFER
The rogue DHCP server, configured with a pool of IP addresses and malicious options (default gateway, DNS), immediately sends a DHCPOFFER unicast to the client's MAC address. The offer includes the XID from the DISCOVER, an offered IP, subnet mask, lease time, and server identifier (rogue's IP). The rogue server may also set the 'broadcast flag' to 1 if the client set it, forcing a broadcast response. The legitimate server may also respond, but the rogue's response often arrives first due to minimal processing or intentional low latency.
Client Accepts First Offer and Sends DHCPREQUEST
Per RFC 2131, the client typically selects the first DHCPOFFER it receives. It broadcasts a DHCPREQUEST packet to 255.255.255.255 with the offered IP in the 'requested IP address' option and the server identifier of the chosen server. This broadcast informs all DHCP servers which offer was accepted. The rogue server sees its own identifier and prepares to send DHCPACK.
Rogue Server Sends DHCPACK
The rogue server sends a DHCPACK unicast to the client, confirming the lease. The ACK includes the same parameters as the OFFER. The client then configures its IP stack: it sets the offered IP, subnet mask, default gateway, and DNS servers. The client may also perform a gratuitous ARP to check for IP conflicts, but if the rogue server assigned an unused IP, no conflict arises. The client is now fully compromised.
Traffic Flows Through Attacker
With the default gateway set to the attacker's IP, all outbound traffic from the client is sent to the attacker's machine. The attacker can forward packets to the real gateway (transparent proxy), modify content, or drop them. Similarly, DNS queries go to the attacker's DNS server, enabling phishing redirection. The attacker can now perform man-in-the-middle attacks, capture credentials, or inject malware.
Enterprise Scenario 1: Campus Network with BYOD
A university campus allows student devices (BYOD) on a dedicated VLAN. A student plugs a rogue Raspberry Pi running a DHCP server into an open wall jack. The rogue server responds faster than the centralized DHCP server (located in the data center, reachable via DHCP relay). Within minutes, dozens of students get IPs with a fake gateway, leading to credential theft when they attempt to log into the university portal. Mitigation: Implement DHCP snooping on all access switches, marking uplink ports as trusted. Also enable 802.1X to authenticate devices before granting network access. Scale: Hundreds of switches, thousands of ports. Performance: DHCP snooping adds minimal latency (microseconds) but requires memory for the binding table (approx. 200 bytes per lease). Misconfiguration: If a trunk port connecting to a legitimate DHCP server is accidentally left untrusted, all DHCP offers are dropped, causing a full network outage.
Enterprise Scenario 2: Enterprise Data Center with Virtualized Servers
In a virtualized environment, a rogue DHCP server could be a VM that was inadvertently deployed with a DHCP service enabled. This VM may be on the same VLAN as production servers. It starts offering IPs to other VMs, causing IP conflicts and traffic misdirection. Mitigation: Use private VLANs to isolate VM traffic, and enforce DHCP snooping on virtual switches (e.g., VMware vDS). Also, use IPAM (IP Address Management) to monitor for unauthorized DHCP servers. Scale: Thousands of VMs. Performance: DHCP snooping in virtual switches uses hypervisor CPU cycles; careful capacity planning needed. Misconfiguration: If DHCP snooping is enabled but the binding database is not synchronized across vSwitches, some VMs may lose connectivity.
Enterprise Scenario 3: Branch Office with Remote DHCP Server
A retail chain has a branch office with a local DHCP server for resiliency. An attacker gains physical access to the branch and connects a rogue DHCP server. Because the legitimate server is on-site, the race condition is tight. However, the attacker can use a tool that responds with zero delay. Mitigation: Configure DHCP snooping with the local server port as trusted. Also, use 802.1X on all switch ports. Consider centralizing DHCP with redundant WAN links to reduce the need for local servers. Common problem: When the WAN link fails, the branch loses DHCP; a rogue server could fill the gap. Solution: Use a local DHCP server that is authorized via AD or NAC.
Objective 4.1: Explain common security concepts
The N10-009 exam tests rogue DHCP server attacks under Objective 4.1, specifically within the context of network security threats and mitigation techniques. Expect 2-3 questions on this topic. The exam focuses on:
Attack Mechanism: How a rogue server intercepts DHCP traffic. Key point: The client accepts the first offer, not the best offer.
Mitigation: DHCP snooping is the primary defense. Know the difference between trusted and untrusted ports.
Related Attacks: DHCP starvation (flooding DISCOVER messages) is often combined with rogue server attacks.
Common Wrong Answers
"The client accepts the offer with the longest lease time." Wrong. The client accepts the first offer. Candidates confuse DHCP with DNS (where longest TTL might be preferred).
"Rogue DHCP servers can be blocked by firewalls." Wrong. DHCP uses broadcasts; firewalls at layer 3 don't filter broadcasts within a VLAN. DHCP snooping at layer 2 is required.
"The rogue server must be on a different subnet." Wrong. It must be on the same broadcast domain (VLAN) to hear the DISCOVER broadcast.
"DHCP snooping prevents rogue servers by encrypting DHCP traffic." Wrong. DHCP snooping does not encrypt; it filters based on port trust.
Specific Numbers and Values
UDP ports: 67 (server), 68 (client)
DHCP message types: DISCOVER (1), OFFER (2), REQUEST (3), ACK (5)
Default lease time: 8 days (Windows Server), but rogue servers often set 5-10 minutes
DHCP snooping rate limit default: 15 packets per second (Cisco)
Edge Cases
DHCP Relay: If a DHCP relay agent is used, the rogue server must be on the same subnet as the client because the relay unicasts the DISCOVER to the legitimate server; the rogue still hears the original broadcast.
IPv6: Rogue DHCPv6 servers pose similar threats; DHCPv6 uses multicast (FF02::1:2) instead of broadcast.
Wireless Networks: Rogue DHCP servers can be deployed on guest Wi-Fi; mitigation includes client isolation and DHCP snooping on wireless controllers.
How to Eliminate Wrong Answers
If a question asks about preventing rogue DHCP, look for answers that mention "DHCP snooping" or "trusted ports." Answers like "firewall rules" or "encryption" are distractors.
If a question describes a scenario where clients get IPs but cannot reach the internet, suspect a rogue server assigning a fake gateway.
If a question asks about detection, tools like dhcploc or dhcpdump are correct; Nmap scanning for UDP 67 is also valid.
Exam Tip
Memorize the DHCP message flow: DISCOVER → OFFER → REQUEST → ACK (DORA). The rogue server hijacks the OFFER step. Know that DHCP snooping creates a binding table used by DAI and IP Source Guard.
A rogue DHCP server exploits the fact that DHCP clients accept the first DHCPOFFER they receive (per RFC 2131).
DHCP snooping is the primary defense; it requires configuring trusted ports for legitimate DHCP servers and untrusted ports for clients.
The rogue server must be on the same broadcast domain (VLAN) as the client to intercept DHCPDISCOVER broadcasts.
Default DHCP lease time on Windows Server is 8 days; rogue servers often set very short leases (e.g., 5 minutes) to force frequent renewals.
DHCP uses UDP ports 67 (server) and 68 (client); the client broadcasts to 255.255.255.255.
DHCP snooping can rate-limit DHCP traffic to prevent starvation; default rate is 15 packets per second on Cisco switches.
Dynamic ARP Inspection (DAI) and IP Source Guard rely on the DHCP snooping binding table to prevent ARP spoofing and IP spoofing.
Detection tools include dhcploc (Windows), dhcpdump (Linux), and Nmap scanning for open UDP 67.
Rogue DHCP attacks can be combined with DHCP starvation to force clients to accept offers from the rogue server.
In IPv6, rogue DHCPv6 servers use multicast address FF02::1:2; DHCPv6 snooping is available on some switches.
These come up on the exam all the time. Here's how to tell them apart.
Rogue DHCP Server Attack
Attacker sets up an unauthorized DHCP server.
Responds to DHCPDISCOVER with malicious OFFERs.
Goal: hijack client IP configuration (MITM).
Mitigation: DHCP snooping (trusted/untrusted ports).
Detection: Look for unknown server IPs in DHCPOFFERs.
DHCP Starvation Attack
Attacker floods legitimate server with fake DHCPDISCOVERs.
Exhausts IP pool, causing denial of service.
Goal: prevent legitimate clients from getting IPs.
Mitigation: DHCP rate limiting on switch ports.
Detection: Monitor for high rate of DISCOVERs from one MAC.
Mistake
A rogue DHCP server can only affect clients on the same subnet if it is faster than the legitimate server.
Correct
True, but the rogue server can also be faster by being on the same physical network with minimal latency. However, even if the legitimate server responds first, the client might still accept a later offer if the first offer is lost or if the client waits for multiple offers (rare). The key is that the rogue server exploits the race condition.
Mistake
DHCP snooping prevents all rogue DHCP attacks by filtering DHCP messages.
Correct
DHCP snooping prevents rogue servers from sending OFFER/ACK messages on untrusted ports. However, if an attacker compromises a trusted port (e.g., by plugging into a trunk port), they can still act as a rogue server. Also, DHCP snooping does not prevent DHCP starvation attacks (which require rate limiting).
Mistake
A rogue DHCP server can be detected by checking for duplicate IP addresses.
Correct
Not necessarily. The rogue server can assign IPs from the same pool as the legitimate server, but with a different gateway. Duplicate IPs may not occur if the rogue server uses a different range. Detection requires monitoring DHCP offers or using DHCP snooping logs.
Mistake
DHCP is only vulnerable to rogue servers if the attacker is on the same VLAN.
Correct
Correct. Because DHCPDISCOVER is a broadcast, it does not cross VLAN boundaries without a relay agent. However, if a rogue server is connected to a trunk port that carries multiple VLANs, it can respond to broadcasts on all those VLANs, making it a threat across multiple VLANs.
Mistake
Using static IP addresses eliminates the risk of rogue DHCP attacks.
Correct
Static IPs avoid DHCP altogether, so rogue servers cannot assign IPs to those devices. However, if a device uses DHCP (e.g., for ease of management), it is vulnerable. Also, static IPs do not prevent the rogue server from existing; it can still affect other DHCP clients.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A rogue DHCP server attack occurs when an unauthorized DHCP server on a network responds to client DHCP requests, assigning malicious IP configurations (e.g., fake default gateway, fake DNS). This allows the attacker to perform man-in-the-middle attacks, traffic interception, or denial of service. The attack exploits the DHCP DORA process: the client accepts the first DHCPOFFER it receives, so a fast rogue server can hijack the assignment. Mitigation primarily involves DHCP snooping on switches, which filters DHCP messages on untrusted ports.
DHCP snooping prevents rogue DHCP servers by filtering DHCP messages based on port trust. Ports connected to legitimate DHCP servers are configured as 'trusted'; all other ports are 'untrusted.' On untrusted ports, the switch drops DHCPOFFER, DHCPACK, and DHCPNAK messages (server-to-client), effectively blocking rogue servers. It also validates source MAC addresses and can rate-limit DHCP packets to prevent starvation. The switch maintains a binding database (MAC-IP-VLAN-port) that can be used by DAI and IP Source Guard.
No, not directly. DHCPDISCOVER is a layer 2 broadcast that stays within the same VLAN. A rogue server must be connected to the same VLAN (broadcast domain) as the target clients. However, if the rogue server is on a trunk port that carries multiple VLANs, it can potentially respond to broadcasts on all those VLANs. Also, if a DHCP relay agent is used, the rogue server cannot intercept the unicasted DISCOVER from the relay to the legitimate server, but it can still hear the original broadcast from the client.
A rogue DHCP server is an unauthorized server that offers IP configurations, often malicious. DHCP starvation is a denial-of-service attack where an attacker floods the legitimate DHCP server with fake DHCPDISCOVER messages, exhausting its IP pool so legitimate clients cannot get addresses. They are often combined: starvation forces clients to accept offers from the rogue server. Mitigation for starvation includes rate limiting on switch ports; for rogue servers, DHCP snooping is used.
Detection methods include: (1) Using tools like dhcploc (Windows) or dhcpdump (Linux) to capture DHCPOFFER packets and identify unknown server IPs. (2) Scanning for open UDP port 67 with Nmap. (3) Checking DHCP snooping logs on switches for dropped OFFER messages. (4) Monitoring syslog for DHCP snooping alerts. (5) Using network monitoring tools that track DHCP server activity. In a Windows domain, unauthorized DHCP servers can be detected via Active Directory authorization checks.
Default lease times vary by vendor: Windows Server defaults to 8 days (691200 seconds). Linux ISC DHCP server defaults to 600 seconds (10 minutes) if not specified. Many enterprise deployments use 8 days to reduce renewal traffic. Rogue servers often set very short leases (e.g., 5 minutes) to force frequent renewals and maintain control. The lease time is included in the DHCPOFFER and DHCPACK messages.
Yes, DHCP snooping is available on many wireless LAN controllers (e.g., Cisco WLC) and can be applied to wireless client VLANs. However, wireless networks often use client isolation, which prevents direct client-to-client communication, but a rogue server could still be connected to the wired infrastructure. In a wireless-only environment, DHCP snooping on the controller's switch ports is effective. Additionally, 802.1X authentication can prevent unauthorized devices from joining the network.
You've just covered Rogue DHCP Server Attacks — now see how well it sticks with free N10-009 practice questions. Full explanations included, no account needed.
Done with this chapter?