Port 68 – BOOTP (Bootstrap Protocol)

Port 68 is the default UDP port for the client side of BOOTP and DHCP — the port a machine listens on to receive its network configuration. The server side answers on port 67. A booting host broadcasts a DHCPDISCOVER from 0.0.0.0:68 to 255.255.255.255:67, and the DHCP server sends its offer back to port 68. The whole exchange is UDP, unauthenticated, and (for the initial lease) broadcast to the entire local segment, which is exactly what makes it worth a pentester’s attention.

Why It’s Open

Almost every host that gets its address automatically has a DHCP client bound to port 68 — laptops, servers, phones, printers, IoT gear. On Linux that’s dhclient, dhcpcd, or systemd-networkd; on Windows it’s the DHCP Client service. So an open UDP 68 usually just means “this box is a DHCP client,” which is the normal state for the vast majority of the network.

The important point is that port 68 isn’t an internet-facing listener you attack from outside. The attack surface is the DHCP conversation itself, and it lives on the local link. Anyone with a foothold on the same broadcast domain can answer DHCP requests, and because there’s no authentication, the client can’t tell a real server from a rogue one. That’s why DHCP attacks show up in internal pentests and red-team engagements rather than in an external port scan.

Common Risks

• Rogue DHCP server. An attacker on the segment answers DHCPDISCOVER faster than (or instead of) the real server and hands the client a gateway, DNS server, and routes of their choosing — the setup for a man-in-the-middle on all of the victim’s traffic.
• Malicious routes via option 121. The classless-static-route option lets a DHCP server push arbitrary routes into the client’s table. More-specific routes beat the VPN’s default route, so traffic a user believes is tunneled leaks in cleartext (see TunnelVision below).
• DNS redirection. DHCP option 6 sets the client’s resolvers. Point them at an attacker box and you control name resolution on port 53 — phishing, credential capture, update hijacking.
• DHCP starvation. Flooding the server with spoofed MAC addresses drains the address pool so legitimate clients can’t get a lease, often as a prelude to standing up a rogue server once the real one is exhausted.
• Client-side code execution. The client parses attacker-controlled option values. Bugs in that parsing (or in the scripts that consume it) have turned a DHCP reply into root-level command execution — DynoRoot and the systemd DHCPv6 overflow are the classic cases.
• Configuration disclosure. The offer itself maps out the network: subnet, gateway, DNS, domain name, WINS, NTP, and vendor options all describe the environment before you’ve touched anything else.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

Check the client/server ports with nmap

nmap -sU -p 67,68 <target>

Discover DHCP servers on the segment

nmap --script broadcast-dhcp-discover -e eth0

This broadcasts a discover and prints every server that answers, along with the options it offers — the quickest way to spot a second, unexpected DHCP server.

Query a specific server and dump its options

nmap --script dhcp-discover -e eth0 --script-args 'dhcp-discover.mac=DE:AD:BE:EF:00:01'

Watch the exchange on the wire

tcpdump -i eth0 -n 'port 67 or port 68'

Look at the Your-IP, Router (option 3), Domain-Name-Server (option 6), and any Classless-Static-Route (option 121) fields to see exactly what the client is being told.

Force a fresh lease from the client side

dhclient -v eth0

The -v output shows the full request/offer/ack, which is useful for confirming which server the client actually accepted.

Stand up a rogue server / spoof offers

# Metasploit fake DHCP server
msfconsole -q
use auxiliary/server/dhcp
set SRVHOST 192.168.1.1
set DNSSERVER 192.168.1.66
run

For DHCP starvation before taking over the pool, yersinia -G (DHCP mode) or dhcpstarv will exhaust the real server. On IPv6, mitm6 abuses the DHCPv6 client to become the network’s DNS server — the same broadcast-trust problem as the LLMNR poisoning on port 5355.

Capture every rogue offer, injected route, and swapped DNS server as you confirm it, so the MITM chain lands in the pentest report with the exact DHCP options attached instead of scrolling out of your capture window.

What to Look For

Known CVEs and Exploits

• CVE-2024-3661 — “TunnelVision.” A DHCP server that sends classless-static-route option 121 can install routes more specific than a VPN’s 0.0.0.0/0, pulling the victim’s traffic outside the tunnel while the VPN still shows connected. Affects Windows, Linux, macOS, and iOS clients that honor option 121; PoC and write-up from Leviathan Security.
• CVE-2018-1111 — “DynoRoot.” A command-injection flaw in the NetworkManager DHCP integration script on Red Hat / CentOS / Fedora. A rogue DHCP server returns option values that get executed as root on the client. Metasploit ships exploit/unix/dhcp/rhel_dhcp_client_command_injection and it’s on Exploit-DB.
• CVE-2018-15688 — Heap buffer overflow in the DHCPv6 client of systemd-networkd (≤ v239). A malicious DHCPv6 server advertising an over-long server-id gets a controlled out-of-bounds write, leading to denial of service or remote code execution.
• CVE-2011-0997 — ISC dhclient fails to sanitize server-supplied hostnames before passing them to shell scripts, allowing a malicious DHCP server to inject commands on the client.

Mitigation

• Enable DHCP snooping on managed switches so only trusted ports may send DHCP offers. This is the single most effective control against rogue servers and starvation.
• Add port security / dynamic ARP inspection alongside snooping to cap MAC addresses per port and stop the address-exhaustion phase of a takeover.
• Patch DHCP clients promptly — DynoRoot, the systemd DHCPv6 overflow, and the dhclient injection were all fixed upstream; keep dhclient / systemd / NetworkManager current.
• Handle option 121 deliberately. Where a VPN must survive a hostile network, either ignore DHCP-supplied routes or run the client inside a namespace/firewall that drops traffic leaving the tunnel interface.
• Segment and monitor. Keep client subnets isolated and alert on any host that starts answering DHCP that isn’t your authorized server.
• Prefer static or reserved addressing for exposed infrastructure so critical hosts don’t depend on the DHCP exchange at all.

Real-World Example

In May 2024, Leviathan Security disclosed TunnelVision (CVE-2024-3661) — a technique that reads a VPN user’s traffic without ever breaking the tunnel. The attacker runs a DHCP server on the local network (a coffee-shop Wi-Fi, a compromised switchport) and uses option 121 to push routes more specific than the VPN’s catch-all default. The victim’s operating system prefers the specific route, so packets exit through the physical interface in cleartext while the VPN client still reports “connected.” It worked against most VPNs on Windows, Linux, macOS, and iOS; Android was spared only because it never implemented option 121. The whole attack is nothing more than a DHCP reply to port 68 — no exploit, no client bug, just the protocol trusting whatever answers on the local segment.

FAQ

What is port 68 used for?

Port 68 is the UDP port DHCP and BOOTP clients listen on to receive their network configuration — IP address, subnet mask, default gateway, and DNS servers. The client sends its request to the server on port 67 and the server sends the reply back to port 68.

What is the difference between port 67 and port 68?

Port 67 is the server side (bootps): the DHCP/BOOTP server listens there. Port 68 is the client side (bootpc): the host being configured listens there. A normal lease uses both — the client broadcasts from port 68 to the server’s port 67, and the server answers back to port 68.

Is port 68 dangerous?

The port itself is normal — nearly every device is a DHCP client. The danger is in the exchange: because DHCP is unauthenticated and broadcast, an attacker on the same network can answer with a rogue server and redirect your gateway, DNS, or routes (as in TunnelVision). It’s a local-network risk, not something exposed to the internet.

How do I close port 68?

Only close it on a host that uses a static address. Set static IP configuration and disable the DHCP client (systemctl disable --now systemd-networkd or the equivalent NetworkManager/dhclient setup), then confirm with nmap -sU -p 68 <target>. On the network side, the real fix isn’t closing the port but enabling DHCP snooping so rogue servers can’t answer.

TL;DR

• Service: DHCP/BOOTP client
• Default port: 68/UDP (client); 67/UDP is the server
• Biggest risk: rogue DHCP server / route injection for man-in-the-middle (e.g. TunnelVision, CVE-2024-3661)
• Mitigation: DHCP snooping + port security on switches, patch the client, control option 121 on VPN hosts