Hi all,

When you scan a host using Nmap without specifying ports, by default it scans 1000 TCP ports, or 1000 UDP ports if you specifically ask Nmap to scan UDP ports (-sU). As far as I am concerned UDP ports are less than TCP ports. What is Nmap actually doing? There is a conflict here, for example port 20 (FTP) is a TCP port, when sending a UDP packet to a TCP port for example "nmap -sU scanme.nmap.org -p 20", Nmap output is:

20/udp closed ftp-data

What? 20 is TCP how did this happen, how did it read the status of the port when the port is TCP and not UDP. Another questions, Nmap states that UDP and TCP cannot be sent together, so when performing a stealth scan (-sS), does this means that it is performing a half-open connection scan only on TCP ports?

Thanks

superkojiman, thanks very much for this information, I don't understand why Fyodor set it like this. I am programming a port scanner and I want to know what are the action made when a UDP packet is sent to a TCP port to check the state of the port (open/closed). In reality what happens if a UDP frame is sent to a TCP port? I am trying to research on this topic, all I get is the difference between TCP and UDP which isn't a mystery.

Thanks alot.

nmap doesn't send UDP packets to a TCP port. Some services run the same port number on TCP and UDP (eg: DNS), and there's nothing preventing a user from changing which port a service can run on. When you do a UDP scan, it only sends packets to UDP ports. If it finds 20/UDP open/closed, it reports it as whatever is listening for port 20 UDP in nmap-services.

You can verify this with tcpdump:


Do a UDP scan on port 20 and you'll see that tcpdump captures it. Do the same scan again but change tcpdump to scan for tcp packets and you'll see that it doesn't capture anything.

Hope that clears things up.

superkojiman, thanks again, apart from what you said I also compared those scans:

nmap -sT scanme.nmap.org -p22:
22/tcp open   ssh

nmap -sU scanme.nmap.org -p22:
22/udp closed ssh

Its just sending UDP packets to all 1000 ports and checking for UDP services, I though that I had to filter all the TCP port numbers out when performing UDP scanning (programming wise). But that’s not efficient anyway since the application can be set to listen on any port and that UDP won't connect to a TCP, this make a lot more sense now.

Thanks,

As far as I know, if you specify a Syn Scan (TCP) -sS, or e.g. a UDP Scan (UDP) -sU, without specifying any port, the top 1000 ports are scanned. The scanning is completely different, and UDP scanning often takes longer time, due to NMAP is waiting for a time-out when it does not receive an ICMP message such as: ICMP Unreachable.


There is no conflict. A port as others stated, is a port. The actual port number, does not define whether it is TCP or UDP, the service listening on that port does. The reason why NMAP shows it as ftp-data, as that is what this port is most commonly used for (i.e. NMAP has a default list it falls back on, when the port is closed, not responding (e.g. TCP wrapped), etc.), plus it's in the "reserved ports range" (i.e. the first 1024 or 1000). You could've easily changed a configuration file within a service, and made it listen on port 20 UDP though. (Keep in mind that on most if not all Linux distributions by default, you need root privileges to listen on the reserved ports. Completely off topic, but something to keep in mind when administrating servers and moving services to different ports.)


Port 20 can be either TCP or UDP as previously stated.  As to how this happened, check the above paragraph which describes how some of NMAP functions.

Now about the status of the port:
TCP Syn Scan) The first "SYN" packet in a TCP handshake is sent to a port, if the target respond with "SYN/ACK", the port is open. (The last packet confirming that the target said the port was open, which also establishes the connection, is not sent. This last packet is an "ACK" packet. Side-note: Some services on the target system, will send an additional ACK after the "attacker" has sent his "ACK" packet. This is why there are sites about e.g. "The 3-way TCP handshake is a lie", etc.) Anyway, that is how a port is determined whether it is open. IF the target respond with a "RST" (reset) packet, the port is closed. (Meaning the target reset the connection.)

TCP Connect Scan)
This type of scan sends the entire TCP handshake. This can be useful in some scenarios/cases where Syn Scans does not work or return different results. (Rarely, but it does happen. Note that this type of scan is slower and costs more server resources as well. As the session/connection after being established, will time out unless NMAP/Fyodor has changed that.)

UDP Scan)
When this scan is issued, a UDP packet is sent to a port (can't remember exactly what type of packet, this is not so important with UDP as it is a stateless protocol, i.e. it does not perform a handshake like TCP), and if the port is open, NMAP will determine this IF there is no response. (Will show up as open/filtered.)
If the port is closed on the other hand, the target will/should send an ICMP Unreachable packet to the attacker. (This is not always the case, but some firewalls and operating systems do this.) When this type of ICMP packet is sent, it is almost safe/certain to say that the port is closed.
If such a packet however, isn't received by the attacker and the -sV (banner grabbing) flag has been set, NMAP will send additional UDP probes with common UDP requests to these services, to determine what kind of service they are. If there is no response (i.e. packets are dropped at the target which is quite common), NMAP will use it's built-in list of ports and determine what kind of service is listening based on this. (In your case, ftp-data.)


I am not sure where you got that statement from, but you are somewhat right that TCP and UDP packets are not sent in the same "packet" at the exact same time. They are sent separately, and when both scans are used, i.e. -sS and -sU, the TCP Syn Scan is done first, and then the UDP Scan.

See scan below: