TCP Port 68 – DHCP Client (Dynamic Host Configuration Protocol)
Port 68 is the client-side counterpart to port 67 in the Dynamic Host Configuration Protocol (DHCP) exchange. When a device joins a network and needs an IP address, subnet mask, gateway, and DNS server, it sends and receives DHCP messages from UDP/68 on its own end. The server it talks to listens on UDP/67.
The protocol’s history runs through the same lineage as port 67. The Bootstrap Protocol (BOOTP), specified in RFC 951 in 1985, originally used port 68 for the client side and registered the IANA service name “bootpc” (BOOTP Client). DHCP, formalized in RFC 2131 in 1993, inherited BOOTP’s port assignments while extending the protocol with leases, automatic renewal, and richer configuration options.
A client uses UDP/68 throughout the lease lifecycle. At first connection, with no address yet assigned, the client broadcasts a DHCPDISCOVER from UDP/68 to UDP/67. It receives the server’s DHCPOFFER on UDP/68, sends a DHCPREQUEST from UDP/68, and receives a DHCPACK on UDP/68. Renewal exchanges, which happen automatically before the lease expires, also use UDP/68. The port is therefore active on essentially every networked device, from laptops and phones to printers and IoT devices.
Like port 67, DHCP client traffic is link-local by design. Clients broadcast their initial discovery, and routers do not forward DHCP broadcasts across subnets unless explicitly configured as DHCP relays. Inbound UDP/68 traffic from a public internet source is unusual and is generally treated as anomalous.
Port 68 is also defined for TCP in the IANA registry, but TCP/68 is not used in practice. DHCP is a UDP-only protocol.
About TCP Port 68
Port 68 carries the IANA assignment for bootpc. The IANA description reads: ‘Bootstrap Protocol Client’.
Security Considerations
Port 68 is the client end of the DHCP exchange, and the IDS rule activity here reflects that. Our data shows 5 IDS rules referencing this port, all on UDP, all detecting attacks where a malicious DHCP server attempts to compromise a connecting client.
The dominant rules cover two named vulnerabilities. CVE-2014-6271, the original Shellshock bug in GNU bash disclosed in September 2014, could be triggered through DHCP option fields when vulnerable Linux clients ran configuration hooks that passed server-supplied strings into bash. A rogue DHCP server on the local network could craft a response that caused the client to execute arbitrary commands as root. CVE-2018-1111, known as DynoRoot, exploited a similar weakness in the NetworkManager DHCP client used by Red Hat, CentOS, and Fedora, allowing a malicious DHCP server to inject shell commands through specific option fields. Both vulnerabilities are now patched in supported distributions, but the rules remain useful for detecting attempts against legacy or unpatched systems.
The shared characteristic of these attacks is that the attacker must be positioned to answer DHCP requests on the local network. The threat is not an internet-borne scan against an exposed client port; it is a rogue server operating on the same LAN segment as the target. Common scenarios include a guest device on a poorly-segmented corporate Wi-Fi network, a compromised host on an internal subnet, and a malicious wireless access point impersonating a legitimate one in a public location.
Defensive practice for managed networks relies on DHCP snooping at the switch layer, which validates that DHCP responses come from an authorized server list and discards responses from any other source. Client systems should be kept patched. Devices connecting to untrusted networks (public Wi-Fi, conference networks, hotel networks) should be treated with the assumption that the DHCP infrastructure may be hostile.
Inbound UDP/68 from a public internet source is unusual and worth investigating. Outbound UDP/68 is universal across networked endpoints during DHCP lease acquisition and renewal.
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).