ICMP : Port unreachable error even if port is open
I am testing my Debian Server with some Nmap port Scanning. My Debian is a Virtual Machine running on a bridged connection. Classic port scanning using TCP SYN request works fine and detects port 80 as open (which is correct) :
nmap -p 80 192.168.1.166 Starting Nmap 6.47 ( http://nmap.org ) at 2016-02-10 21:36 CET Nmap scan report for 192.168.1.166 Host is up (0.00014s latency). PORT STATE SERVICE 80/tcp open http MAC Address: xx:xx:xx:xx:xx:xx (Cadmus Computer Systems) Nmap done: 1 IP address (1 host up) scanned in 0.51 seconds But when running UDP port scan, it fails and my Debian server answers with an ICMP : Port unreachable error :
nmap -sU -p 80 192.168.1.166 Starting Nmap 6.47 ( http://nmap.org ) at 2016-02-10 21:39 CET Nmap scan report for 192.168.1.166 Host is up (0.00030s latency). PORT STATE SERVICE 80/udp closed http MAC Address: xx:xx:xx:xx:xx:xx (Cadmus Computer Systems) Nmap done: 1 IP address (1 host up) scanned in 0.52 seconds 
Wireshark record : How is that possible ? My port 80 is open, how come that Debian answers with an ICMP : Port unreachable error ? Is that a security issue?
3 Answers 3
Albeit TCP and UDP are part of TCP/IP, both belong to the same TCP/IP or OSI layers, and both are a layer above IP, they are different protocols.
Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) are two of the core protocols of the Internet Protocol suite. Both TCP and UDP work at the transport layer TCP/IP model and both have a very different usage. TCP is a connection-oriented protocol. UDP is a connectionless protocol.
Some services do indeed answer to TCP and UDP ports at the same time, as is the case of DNS and NTP services, however that is not certainly the case with web servers, which normally only answer by default to port 80/TCP (and do not work/listen at all in UDP)
You can list your UDP listenning ports in a linux system with:
$sudo netstat -anlpu Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name udp 0 0 0.0.0.0:1900 0.0.0.0:* 15760/minidlnad udp 0 0 0.0.0.0:5000 0.0.0.0:* 32138/asterisk udp 0 0 0.0.0.0:4500 0.0.0.0:* 1592/charon udp 0 0 0.0.0.0:4520 0.0.0.0:* 32138/asterisk udp 0 0 0.0.0.0:5060 0.0.0.0:* 32138/asterisk udp 0 0 0.0.0.0:4569 0.0.0.0:* 32138/asterisk udp 0 0 0.0.0.0:500 0.0.0.0:* 1592/charon udp 0 0 192.168.201.1:53 0.0.0.0:* 30868/named udp 0 0 127.0.0.1:53 0.0.0.0:* 30868/named udp 0 0 0.0.0.0:67 0.0.0.0:* 2055/dhcpd udp 0 0 0.0.0.0:14403 0.0.0.0:* 1041/dhclient udp 17920 0 0.0.0.0:68 0.0.0.0:* 1592/charon udp 0 0 0.0.0.0:68 0.0.0.0:* 1041/dhclient udp 0 0 0.0.0.0:56417 0.0.0.0:* 2055/dhcpd udp 0 0 192.168.201.1:123 0.0.0.0:* 1859/ntpd udp 0 0 127.0.0.1:123 0.0.0.0:* 1859/ntpd udp 0 0 192.168.201.255:137 0.0.0.0:* 1777/nmbd udp 0 0 192.168.201.1:137 0.0.0.0:* 1777/nmbd udp 0 0 0.0.0.0:137 0.0.0.0:* 1777/nmbd udp 0 0 192.168.201.255:138 0.0.0.0:* 1777/nmbd udp 0 0 192.168.201.1:138 0.0.0.0:* 1777/nmbd udp 0 0 0.0.0.0:138 0.0.0.0:* 1777/nmbd udp 0 0 192.168.201.1:17566 0.0.0.0:* 15760/minidlnad And your listening TCP ports with the command:
$sudo netstat -anlpt Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:5060 0.0.0.0:* LISTEN 32138/asterisk tcp 0 0 192.168.201.1:8200 0.0.0.0:* LISTEN 15760/minidlnad tcp 0 0 192.168.201.1:139 0.0.0.0:* LISTEN 2092/smbd tcp 0 0 0.0.0.0:2000 0.0.0.0:* LISTEN 32138/asterisk tcp 0 0 192.168.201.1:80 0.0.0.0:* LISTEN 7781/nginx tcp 0 0 192.168.201.1:53 0.0.0.0:* LISTEN 30868/named tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 30868/named tcp 0 0 192.168.201.1:22 0.0.0.0:* LISTEN 2023/sshd tcp 0 0 0.0.0.0:8888 0.0.0.0:* LISTEN 1919/perl tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 30868/named tcp 0 0 192.168.201.1:445 0.0.0.0:* LISTEN 2092/smbd tcp 0 224 192.168.201.1:22 192.168.201.12:56820 ESTABLISHED 16523/sshd: rui [pr Now normally NMAP does send a SYN to the port being scanned, and per the TCP protocol, if a daemon/service is bound to the port, it will answer with a SYN+ACK, and nmap will show it as open.
To establish a connection, TCP uses a three-way handshake. Before a client attempts to connect with a server, the server must first bind to and listen at a port to open it up for connections: this is called a passive open. Once the passive open is established, a client may initiate an active open. To establish a connection, the three-way (or 3-step) handshake occurs:
SYN: The active open is performed by the client sending a SYN to the server. The client sets the segment’s sequence number to a random value A. SYN-ACK: In response, the server replies with a SYN-ACK.
However, if a service is not running there, TCP/IP defines the kernel will send an ICMP message back with an «Port unreachable» message for UDP services, and TCP RST messages for TCP services.
Destination unreachable is generated by the host or its inbound gateway[3] to inform the client that the destination is unreachable for some reason. A Destination Unreachable message may be generated as a result of a TCP, UDP or another ICMP transmission. Unreachable TCP ports notably respond with TCP RST rather than a Destination Unreachable type 3 as might be expected.
So indeed, your UDP scanning to port 80/UDP simply receives an ICMP unreachable message back because there is not a service listening to that combination or protocol/port.
As for security considerations, those ICMP destination unreachable messages can certainly be blocked, if you define firewall/iptables rules that DROP all messages by default, and only allow in the ports that your machine serves to the outside. That way, nmap scans to all the open ports, especially in a network, will be slower, and the servers will use less resources.
As an additional advantage, if a daemon/service opens additional ports, or a new service is added by mistake, it won’t be serving requests until it is expressly allowed by new firewall rules.
Please do note, that if instead of using DROP in iptables, you use REJECT rules, the kernel won’t ignore the scanning/ TCP/IP negotiation tries, and will answer with ICMP messages of Destination unreachable, code 13: «Communication administratively prohibited (administrative filtering prevents packet from being forwarded)».
Linux icmp destination unreachable
NAME
icmp - Linux IPv4 ICMP kernel module.
DESCRIPTION
This kernel protocol module implements the Internet Control Message Protocol defined in RFC 792. It is used to signal error conditions and for diagnosis. The user doesn't interact directly with this module; instead it communicates with the other protocols in the kernel and these pass the ICMP errors to the application layers. The kernel ICMP module also answers ICMP requests. A user protocol may receive ICMP packets for all local sockets by opening a raw socket with the protocol IPPROTO_ICMP. See raw(7) for more information. The types of ICMP packets passed to the socket can be filtered using the ICMP_FILTER socket option. ICMP packets are always processed by the kernel too, even when passed to a user socket. Linux limits the rate of ICMP error packets to each destination. ICMP_REDIRECT and ICMP_DEST_UNREACH are also limited by the destination route of the incoming packets. /proc interfaces ICMP supports a set of /proc interfaces to configure some global IP parameters. The parameters can be accessed by reading or writing files in the directory /proc/sys/net/ipv4/. Most of these parameters are rate limitations for specific ICMP types. Linux 2.2 uses a token bucket filter to limit ICMPs. The value is the timeout in jiffies until the token bucket filter is cleared after a burst. A jiffy is a system dependent unit, usually 10ms on i386 and about 1ms on alpha and ia64. icmp_destunreach_rate (Linux 2.2 to 2.4.9) Maximum rate to send ICMP Destination Unreachable packets. This limits the rate at which packets are sent to any individual route or destination. The limit does not affect sending of ICMP_FRAG_NEEDED packets needed for path MTU discovery. icmp_echo_ignore_all (since Linux 2.2) If this value is nonzero, Linux will ignore all ICMP_ECHO requests. icmp_echo_ignore_broadcasts (since Linux 2.2) If this value is nonzero, Linux will ignore all ICMP_ECHO packets sent to broadcast addresses. icmp_echoreply_rate (Linux 2.2 to 2.4.9) Maximum rate for sending ICMP_ECHOREPLY packets in response to ICMP_ECHOREQUEST packets. icmp_errors_use_inbound_ifaddr (Boolean; default: disabled; since Linux 2.6.12) If disabled, ICMP error messages are sent with the primary address of the exiting interface. If enabled, the message will be sent with the primary address of the interface that received the packet that caused the ICMP error. This is the behavior that many network administrators will expect from a router. And it can make debugging complicated network layouts much easier. Note that if no primary address exists for the interface selected, then the primary address of the first non-loopback interface that has one will be used regardless of this setting. icmp_ignore_bogus_error_responses (Boolean; default: disabled; since Linux 2.2) Some routers violate RFC1122 by sending bogus responses to broadcast frames. Such violations are normally logged via a kernel warning. If this parameter is enabled, the kernel will not give such warnings, which will avoid log file clutter. icmp_paramprob_rate (Linux 2.2 to 2.4.9) Maximum rate for sending ICMP_PARAMETERPROB packets. These packets are sent when a packet arrives with an invalid IP header. icmp_ratelimit (integer; default: 1000; since Linux 2.4.10) Limit the maximum rates for sending ICMP packets whose type matches icmp_ratemask (see below) to specific targets. 0 to disable any limiting, otherwise the minimum space between responses in milliseconds. icmp_ratemask (integer; default: see below; since Linux 2.4.10) Mask made of ICMP types for which rates are being limited. Significant bits: IHGFEDCBA9876543210 Default mask: 0000001100000011000 (0x1818) Bit definitions (see the Linux kernel source file include/linux/icmp.h): 0 Echo Reply 3 Destination Unreachable * 4 Source Quench * 5 Redirect 8 Echo Request B Time Exceeded * C Parameter Problem * D Timestamp Request E Timestamp Reply F Info Request G Info Reply H Address Mask Request I Address Mask Reply The bits marked with an asterisk are rate limited by default (see the default mask above). icmp_timeexceed_rate (Linux 2.2 to 2.4.9) Maximum rate for sending ICMP_TIME_EXCEEDED packets. These packets are sent to prevent loops when a packet has crossed too many hops.
VERSIONS
Support for the ICMP_ADDRESS request was removed in 2.2. Support for ICMP_SOURCE_QUENCH was removed in Linux 2.2.
NOTES
As many other implementations don't support IPPROTO_ICMP raw sockets, this feature should not be relied on in portable programs. ICMP_REDIRECT packets are not sent when Linux is not acting as a router. They are also accepted only from the old gateway defined in the routing table and the redirect routes are expired after some time. The 64-bit timestamp returned by ICMP_TIMESTAMP is in milliseconds since the Epoch, 1970-01-01 00:00:00 +0000 (UTC). Linux ICMP internally uses a raw socket to send ICMPs. This raw socket may appear in netstat(8) output with a zero inode.
SEE ALSO
ip(7) RFC 792 for a description of the ICMP protocol.