Why do netcat scans for UDP ports always succeed?

Question

I'm trying to verify that a couple of our servers can communicate via certain ports before migrating some of our services to them, and that they're not blocked by our organizations firewall ACLs.

Makes Sense

[mrduki@mybox1~]$ nc -ul 40000
---
[mrduki@mybox2~]$ nc -zvuw2 mybox1.com 40000
Connection to mybox1.com 40000 port [udp/*] succeeded!

Doesn't Make Sense

[mrduki@mybox1~]$ nc -ul 40000
[mrduki@mybox1~]$ ^C
---
[mrduki@mybox2~]$ nc -zvuw2 mybox1.com 40000
Connection to mybox1.com 40000 port [udp/*] succeeded!

In fact, if I do a port scan from 40000-40100, every single port succeeds.

If I do the same tests without -u (so that it tests TCP instead of UDP), I get 40000 (tcp) timed out: Operation now in progress errors, as I would expect (since I have no such TCP service listening on 40000).

Doing a sudo netstat -alnp | grep LISTEN on mybox1 though shows no such services listening on these ports. So what am I missing?

Answer 1

nc may not be the best tool for testing port status. Have you tried nmap? It's actually a port scanner. I checked a file server on my home network and 127.0.0.1, both report that UDP port 40000 is closed.

nmap

# nmap -sU -p 40000 igor

Starting Nmap 7.01 ( https://nmap.org ) at 2016-08-18 18:27 EDT
Nmap scan report for igor (192.168.1.125)
Host is up (0.00027s latency).
rDNS record for 192.168.1.125: igor.swass
PORT      STATE  SERVICE
40000/udp closed unknown
MAC Address: 68:05:CA:3A:BF:B7 (Intel Corporate)

Nmap done: 1 IP address (1 host up) scanned in 0.53 seconds

Kernel + /dev

You can also use the kernel to do this like so. But nmap is probably better.

# timeout 3 cat < /dev/udp/example.com/40000

When I tried nc on the same server (igor) I was getting the same results as you. But I went back to try again, and now it returning no output (no succeeded message) and wireshark is showing "Destination unreachable" being sent back over ICMP. I don't understand any of this. But I'd switch to a different method of checking UDP port status.

Answer 2

UDP is a "connectionless" protocol. If you send a packet and you don't get a rejection (via ICMP), regardless of whether you get a reply or not, it's considered successful. Something quite common is a firewall blocking the target's ICMP rejection packets from being sent back to you (which is what netcat uses to know whether the port is closed, otherwise it thinks it's open).

Contrast this with TCP, which is statefull. A failure to receive a reply (ACK) is considered a failure within TCP (this usually shows up as "filtered"), as are negative replies (RST, which will show up as closed).

UDP: open|filtered closed TCP: open closed filtered

Answer 3

No firewall block will stop a UDP connection attempt from succeeding since connecting with UDP doesn't involve sending anything or listening for any responses. Functionally, a UDP connect operation is the same as a send up to the point where data is actually sent, that is, it:

1. Ensures the selected local port can be bound to, if one was selected.
2. If no local port was selected, it chooses one.
3. Locks the endpoint so that it, by default, will communicate with the selected IP and port and discard any datagrams received from any other IP address or port.
4. The system may change the way it handles some types of errors.
5. That's it.

Notice that none of this does anything a firewall would interfere with, nor is anything sent on the wire.