TCP Port 67 – DHCP Server (Dynamic Host Configuration Protocol)
Port 67 is the standard server-side port for the Dynamic Host Configuration Protocol (DHCP), the technology that automatically assigns IP addresses, subnet masks, default gateways, and DNS servers to devices joining a network. When a laptop, phone, or IoT device connects to a Wi-Fi network or plugs into an Ethernet jack, it almost always receives its network configuration through DHCP from a server listening on UDP/67.
DHCP grew out of the older Bootstrap Protocol (BOOTP), originally specified in RFC 951 in 1985 for booting diskless workstations from a network. DHCP was formalized in RFC 2131 in 1993 and inherited BOOTP’s port assignments along with the IANA service name “bootps” (BOOTP Server). The two protocols are wire-compatible enough that a DHCP server can answer a BOOTP client and vice versa.
The exchange follows a fixed pattern. A client without an address broadcasts a DHCPDISCOVER message from UDP/68 to UDP/67. A DHCP server on the network responds with a DHCPOFFER from UDP/67 back to UDP/68, the client confirms its choice with a DHCPREQUEST, and the server sends a DHCPACK. After that, the client owns its lease until the renewal timer expires or it disconnects. Every home router, every office Wi-Fi access point, and every cloud subnet runs some form of DHCP server on this port.
DHCP traffic is link-local by design. The protocol relies on broadcast for client discovery, and routers do not forward DHCP broadcasts unless they are explicitly configured as DHCP relays. As a result, DHCP traffic does not traverse the public internet under normal conditions. Inbound UDP/67 from a public internet source is unusual and is generally treated as anomalous.
Port 67 is also defined for TCP in the IANA registry, but TCP/67 is not used in practice. DHCP is a UDP-only protocol.
About TCP Port 67
The Internet Assigned Numbers Authority (IANA) registers port 67 for bootps. The IANA description reads: ‘Bootstrap Protocol Server’.
Security Considerations
The security story for port 67 is unusual in shape. Most internet-exposed services attract attacks aimed at the listening server. DHCP attacks tend to run in the opposite direction: the malicious actor operates a rogue DHCP server, and the target is the DHCP client connecting to it.
Our data shows 8 IDS rules referencing this port, all on UDP. A small number detect older attacks against DHCP server software itself, including hardware-address-length overflows and hostname format-string attempts from the BOOTP and early DHCP era when server-side parsers had exploitable bugs. These are rare today.
The dominant pattern is malicious-DHCP-server attacks against clients. Two named vulnerabilities account for most of this activity. CVE-2014-6271, the original Shellshock bug in GNU bash, could be triggered through DHCP option fields when vulnerable Linux clients passed DHCP response strings into bash hooks during interface configuration. A rogue DHCP server on the same network could send a crafted response and execute commands as root on connecting clients.
CVE-2018-1111, known as DynoRoot, was a similar pattern targeting the NetworkManager DHCP client used by Red Hat, CentOS, and Fedora; a malicious DHCP server could inject shell commands through specific option fields. Sample rules in our dataset detect both attack families.
The threat model is therefore network-local, not internet-borne. The attacker needs to be in a position to answer DHCP requests on the local network: a guest on the corporate Wi-Fi, a compromised device on the same LAN segment, or a malicious wireless access point posing as a legitimate one.
Defensive practice for managed environments centers on DHCP snooping, a feature on enterprise switches that validates DHCP responses against an authorized-server list and drops responses from any other source. Client systems should be patched against known DHCP-client vulnerabilities. Untrusted networks (public Wi-Fi, conference networks) should be treated with the assumption that any DHCP response received may be malicious.
Inbound UDP/67 from the public internet is unusual and worth investigating. Outbound UDP/67 from typical end-user devices is essentially nonexistent; clients use UDP/68 outbound as part of the DHCP exchange.
Data Sources
This information is compiled from: IANA Service Name and Transport Protocol Port Number Registry, Emerging Threats Open Ruleset (BSD 2-Clause / GPLv2 per SID range), and Snort Community Rules (GPLv2).