67
Summary
- // if you see it open
- DHCP is not intended to be internet-facing; perimeter exposure of UDP/67 enables DHCP starvation (spoofed-MAC DISCOVER flooding to exhaust the address pool, e.g. via Yersinia) and rogue DHCP server deployment (Yersinia, Metasploit aux modules). Hardening blocks UDP/67-68 at the perimeter and scopes DHCP to trusted VLANs. No CVEs specific to TCP/67 exposure were found; historical DHCP-server CVEs (ISC DHCP overflows, Microsoft MS04-042) relate to UDP/67 software, not TCP.
- // analyst note
- A responsive TCP/67 is anomalous — legitimate DHCP/BOOTP uses UDP/67; investigate a live TCP listener rather than assume normal DHCP.
About port 67/tcp.
Port 67/tcp is registered with IANA as bootps ("Bootstrap Protocol Server"), assignee Bill Croft, referencing RFC 951 — and it is dual-registered on UDP (the companion 67/udp row carries the same service name with the assignee, contact, and reference columns left blank). The assignment dates back to BOOTP, the protocol RFC 951 (1985) defined for a diskless client to learn its IP address and boot file from a server. DHCP (Dynamic Host Configuration Protocol) is BOOTP's successor and inherits the same server port: a DHCP server listens on port 67 to receive client DISCOVER and REQUEST messages and to hand back IP configuration (address, subnet mask, gateway, DNS) through the DORA handshake (Discover, Offer, Request, Acknowledge), with clients on the partner port 68. The operative point for an analyst is that real-world traffic on this service is UDP, not TCP: DHCP/BOOTP is a link-local broadcast protocol, and a client that has no IP address yet cannot complete a TCP three-way handshake, so TCP/67 is formally assigned but carries essentially no legitimate traffic and is virtually never observed by internet scanners. Common server software binding the UDP side includes ISC DHCP (dhcpd), ISC Kea, dnsmasq, Windows Server DHCP, and the DHCP servers embedded in Cisco IOS and Juniper Junos. Because DHCP is not meant to be internet-facing, exposure at a network perimeter is a misconfiguration: the primary attack vectors are DHCP starvation (flooding DISCOVER packets with spoofed MAC addresses to exhaust the address pool, e.g. via Yersinia) and rogue DHCP server deployment, both targeting UDP/67. Standard hardening blocks UDP/67–68 at the perimeter and scopes DHCP server access to trusted VLANs. No CVEs specific to TCP/67 exposure were found; historical DHCP server CVEs (ISC DHCP overflows, Microsoft MS04-042) relate to UDP/67 server software, not TCP.
- IANA assignment
bootps— "Bootstrap Protocol Server"; reference RFC 951; assignee/contact Bill Croft; dual-registered 67/tcp + 67/udp (the 67/udp row leaves assignee/contact/reference blank in the registry) [Confirmed] — IANA Service Name and Transport Protocol Port Number Registry- Range class
- well-known (0–1023)
- Registration / modification date
- blank in IANA registry [Confirmed — null] — IANA registry
- Related ports
- 68/tcp + 68/udp (
bootpc, the DHCP/BOOTP client port); the DHCP pair is 67 (server) / 68 (client)
Primary use
DHCP/BOOTP server listening port — receives client DISCOVER/REQUEST and distributes IP configuration via the DORA handshake; DHCP is the successor to BOOTP (RFC 951)
Common software
ISC DHCP (dhcpd), ISC Kea, dnsmasq, Windows Server DHCP Service, Cisco IOS DHCP server, Juniper Junos DHCP — all bind the UDP side
Security implications
DHCP is link-local by design and not intended to be internet-facing; perimeter exposure of UDP/67 enables DHCP starvation (spoofed-MAC DISCOVER flooding to exhaust the pool) and rogue DHCP servers (Yersinia, Metasploit aux modules). Standard hardening blocks UDP/67–68 at the perimeter and scopes DHCP to trusted VLANs. TCP/67 sees no legitimate traffic and is not expected in scans
Notable CVEs
none specific to TCP/67 exposure found; historical DHCP-server CVEs (ISC DHCP heap overflows; Microsoft MS04-042) relate to UDP/67 server software, not TCP
- TCP vs UDP
- only UDP/67 carries real traffic; TCP/67 is formally assigned but unused in practice because a DHCP client has no IP address at discovery time and cannot complete a TCP handshake [Confirmed] — IANA registry; two-angle (registry + web)
- Analyst note
- A responsive TCP/67 is anomalous — legitimate DHCP/BOOTP uses UDP/67; investigate a live TCP listener rather than assume normal DHCP.
About port 67/udp.
Port 67/udp is the server-side port for DHCP and its predecessor BOOTP — the service that hands out IP addresses and network configuration to clients, and by nmap-services frequency one of the most commonly open UDP ports on any network. DHCP address assignment follows the four-step DORA exchange: the client broadcasts a Discover from 0.0.0.0 (source port 68) to 255.255.255.255 (destination port 67); the server replies with an Offer; the client broadcasts a Request accepting one offer; and the server confirms with an Ack carrying the lease and options (gateway, DNS, lease time, and more). Discover and Request are broadcast because the client has no IP yet, and on routed networks a relay agent (the "ip helper-address") forwards these between subnets to the server on port 67. The ports were inherited from BOOTP (RFC 951, 1985); DHCP itself was standardized in RFC 1531 and then RFC 2131 (1997), with options defined in RFC 2132. DHCPv6 is a separate protocol on ports 546 (client) and 547 (server). Security is the weak point: base DHCP has no authentication, which enables rogue DHCP servers (handing out an attacker-controlled gateway or DNS for man-in-the-middle), DHCP starvation (flooding Discover messages with spoofed MACs to exhaust the address pool, via tools like Yersinia, DHCPig, or Metasploit), and DHCP spoofing. The standard mitigations live on the switch: DHCP snooping (trust only the legitimate server port), port security (limit MACs per port), and IP Source Guard. The IANA registry leaves the 67/udp Reference field blank — RFC 951 is cited only on the 67/tcp row, not the UDP one — so the protocol RFCs are linked separately rather than presented as the registry citation. For an analyst, an open 67/udp marks a DHCP server; if it is unexpected on a segment, investigate it as a possible rogue server.
- IANA assignment
bootps— "Bootstrap Protocol Server"; reference (blank — no RFC cited in IANA registry for 67/udp; the 67/tcp row cites [RFC951]); governing protocols RFC 951 (BOOTP) + RFC 2131 (DHCP), not the IANA-cited reference for the udp row[IANA-assigned] — IANA Service Name and Transport Protocol Port Number Registry- Range class
- well-known (0–1023)
- Prevalence
- nmap-services open-frequency 0.228010 — among the most common open UDP ports [Well-established] — nmap-services file
- Related ports
- 68 (bootpc, DHCP client); 546/547 (DHCPv6 client/server); 69 TFTP and 4011 (PXE) in the boot ecosystem
Primary use
DHCP/BOOTP server — IP address and configuration assignment via the DORA exchange
Other/unofficial uses
PXE/network-boot signaling rides on DHCP options
Security implications
no authentication in base DHCP; rogue DHCP servers (MITM via attacker gateway/DNS); DHCP starvation (Yersinia/DHCPig/Metasploit); spoofing. Mitigate with DHCP snooping, port security, IP Source Guard
Typically seen on
DHCP servers (routers/firewalls, Windows Server DHCP, ISC Kea/dhcpd), and relay agents
- Analyst note
- Open 67/udp marks a DHCP server. If unexpected on the segment, investigate as a possible rogue DHCP server; confirm DHCP snooping is enforced on access switches.
Service assignments.
| Name | Protocol | Description | Open frequency |
|---|---|---|---|
| dhcps | UDP | DHCP/Bootstrap Protocol Server | 22.80% |
| dhcps | TCP | bootps | 0.00% |
Service assignments from the IANA Service Name and Transport Protocol Port Number Registry, with open-frequency data from nmap-services.