How Hackers Check if a UDP Port Is Open or Filtered

Determining the state of a User Datagram Protocol (UDP) port is fundamentally different from scanning Transmission Control Protocol (TCP) ports due to UDP’s connectionless architecture. Without a standardized three-way handshake to confirm active sessions, security analysts and attackers must rely on application-specific payloads, ICMP response messages, and inference to classify a target UDP port as open, closed, or filtered.

The Challenge of UDP Port Scanning

TCP provides definitive feedback through SYN/ACK and RST flags. In contrast, UDP does not establish a connection before sending data. A UDP service is not required to respond to arbitrary or malformed packets. Consequently, scanning a UDP port involves sending a probe packet and analyzing whether the target system responds, rejects the packet, or remains silent.

Detecting a Closed Port

A closed UDP port is the easiest state to identify reliably:

• ICMP Port Unreachable Message: When a scanner sends a raw UDP packet to a port where no service is listening, the target host’s operating system generates an ICMP Type 3, Code 3 (Destination Unreachable: Port Unreachable) error message.
• Interpretation: Receiving an ICMP Port Unreachable error confirms that the host is reachable, the packet was not blocked by a firewall, and the specific port is definitively closed.

Detecting an Open Port

Because open UDP services often ignore unexpected data, confirming an open port requires specific techniques:

• Application-Specific Probes: Attackers send protocol-compliant payloads tailored to common UDP services (such as DNS queries on port 53, SNMP requests on port 161, or NTP requests on port 123). If the service receives a valid request, it returns a protocol-specific response, definitively marking the port as open.
• The “Open|Filtered” Dilemma: If a scanner sends an empty or generic UDP packet to an open port, the application will typically drop the invalid packet without replying. Because no response is received, the scanner cannot immediately determine whether the port is open and silently ignoring the probe, or if a firewall dropped the packet entirely. Tools like Nmap classify this non-responsive state as open|filtered.

Detecting a Filtered Port

A filtered state means a firewall, router, or security appliance is intercepting and blocking the traffic before it reaches the destination service:

• Administrative ICMP Errors: Some firewalls are configured to reject packets and explicitly inform the sender. They return ICMP Type 3 with specific codes, such as Code 1 (Host Unreachable), Code 2 (Protocol Unreachable), Code 9/10 (Communication Administratively Prohibited), or Code 13 (Communication Administratively Filtered).
• Packet Dropping (No Response): If a packet filter is configured to silently drop unauthorized incoming traffic (or block outgoing ICMP replies), the scanner receives no response after multiple retransmissions.

Overcoming Rate Limiting and False Positives

Operating systems like Linux implement strict ICMP rate limiting (often capping ICMP error responses to one per second). When rapid scanning occurs, closed ports may appear silent because the host throttles its ICMP error generation, leading to false open|filtered results. Attackers counter this by slowing down scan rates, using custom payload libraries, and sending follow-up verification probes to distinguish genuine services from firewalled endpoints.