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?
Best Answer
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.
http://www.cyberciti.biz/faq/key-differences-between-tcp-and-udp-protocols/
(source: ml-ip.com)
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:
And your listening TCP ports with the command:
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.
TCP/IP connection negotiation: 3 way handshake
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.
ICMP Destination unreachable
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)".
Block all ports except SSH/HTTP in ipchains and iptables