ZeroOne wrote: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?
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.
ZeroOne wrote: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
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.)
ZeroOne wrote: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.
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.)
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.)
ZeroOne wrote: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?
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:
# nmap scanme.nmap.org -sS -sU -F -T4
Starting Nmap 6.01 ( http://nmap.org
) at 2012-12-05 10:48 AUS Eastern Daylight
Stats: 0:00:02 elapsed; 0 hosts completed (1 up), 1 undergoing SYN Stealth Scan
SYN Stealth Scan Timing: About 68.50% done; ETC: 10:48 (0:00:01 remaining)
Stats: 0:00:09 elapsed; 0 hosts completed (1 up), 1 undergoing UDP Scan
UDP Scan Timing: About 16.50% done; ETC: 10:49 (0:00:20 remaining)
Stats: 0:00:12 elapsed; 0 hosts completed (1 up), 1 undergoing UDP Scan
UDP Scan Timing: About 18.29% done; ETC: 10:49 (0:00:31 remaining)
Warning: 188.8.131.52 giving up on port because retransmission cap hit (6).
Stats: 0:00:20 elapsed; 0 hosts completed (1 up), 1 undergoing UDP Scan
UDP Scan Timing: About 35.71% done; ETC: 10:49 (0:00:29 remaining)
Stats: 0:00:28 elapsed; 0 hosts completed (1 up), 1 undergoing UDP Scan
UDP Scan Timing: About 49.29% done; ETC: 10:49 (0:00:24 remaining)
Stats: 0:01:36 elapsed; 0 hosts completed (1 up), 1 undergoing UDP Scan
UDP Scan Timing: About 99.99% done; ETC: 10:50 (0:00:00 remaining)
Nmap scan report for scanme.nmap.org (184.108.40.206)
Host is up (0.14s latency).
Not shown: 174 closed ports
PORT STATE SERVICE
21/tcp filtered ftp
22/tcp open ssh
80/tcp open http
111/tcp filtered rpcbind
135/tcp filtered msrpc
514/tcp filtered shell
554/tcp filtered rtsp
1720/tcp filtered H.323/Q.931
1723/tcp filtered pptp
2000/tcp filtered cisco-sccp
5060/tcp filtered sip
9/udp open|filtered discard
68/udp open|filtered dhcpc
69/udp open|filtered tftp
111/udp open|filtered rpcbind
123/udp open ntp
135/udp open|filtered msrpc
518/udp open|filtered ntalk
520/udp open|filtered route
1027/udp open|filtered unknown
1030/udp open|filtered iad1
1719/udp open|filtered h323gatestat
2049/udp open|filtered nfs
5060/udp open|filtered sip
49153/udp open|filtered unknown
49186/udp open|filtered unknown
Nmap done: 1 IP address (1 host up) scanned in 112.07 seconds