.

TCP/UDP scanning questions!

<<

ZeroOne

Jr. Member
Jr. Member

Posts: 59

Joined: Tue Apr 24, 2012 7:41 am

Post Tue Dec 04, 2012 1:04 pm

TCP/UDP scanning questions!

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
Last edited by ZeroOne on Tue Dec 04, 2012 1:13 pm, edited 1 time in total.
<<

superkojiman

User avatar

Jr. Member
Jr. Member

Posts: 81

Joined: Thu Sep 20, 2012 9:42 pm

Post Tue Dec 04, 2012 2:44 pm

Re: TCP/UDP scanning questions!

nmap uses nmap-services to look up ports and their names. If you open this file up, you'll see an entry for TCP and UDP for port 20

ftp-data    20/sctp 0.000000    # File Transfer [Default Data]
ftp-data    20/tcp  0.001079    # File Transfer [Default Data]
ftp-data    20/udp  0.001878    # File Transfer [Default Data]
ftp 21/sctp 0.000000    # File Transfer [Control]
ftp 21/tcp  0.197667    # File Transfer [Control]
ftp 21/udp  0.004844    # File Transfer [Control]
ssh 22/sctp 0.000000    # Secure Shell Login
ssh 22/tcp  0.182286    # Secure Shell Login


To check this, you can modify the ftp-data name for UDP to something like myftp-data and re-run the scan. You should see it report 20/UDP as myftp-data. See here for more details: http://nmap.org/book/nmap-services.html

As for stealth scan, they only work on TCP given that it manipulates the TCP handshake - something that UDP does not have. See the nmap man page for more details.
OSCP + OSCE
<<

ZeroOne

Jr. Member
Jr. Member

Posts: 59

Joined: Tue Apr 24, 2012 7:41 am

Post Tue Dec 04, 2012 3:33 pm

Re: TCP/UDP scanning questions!

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.
Last edited by ZeroOne on Tue Dec 04, 2012 3:41 pm, edited 1 time in total.
<<

lorddicranius

User avatar

Sr. Member
Sr. Member

Posts: 448

Joined: Thu Mar 03, 2011 3:54 am

Post Tue Dec 04, 2012 4:11 pm

Re: TCP/UDP scanning questions!

Port 20 isn't just a TCP port.  A port is just a port.  Whether or not it accepts TCP or UDP is up to the daemon/application listening on that port (or the firewall filtering the traffic to said port).
GSEC, eCPPT, Sec+
<<

superkojiman

User avatar

Jr. Member
Jr. Member

Posts: 81

Joined: Thu Sep 20, 2012 9:42 pm

Post Tue Dec 04, 2012 4:17 pm

Re: TCP/UDP scanning questions!

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:

  Code:
tcpdump -v udp and dst port 20


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.
OSCP + OSCE
<<

dynamik

Recruiters
Recruiters

Posts: 1119

Joined: Sun Nov 09, 2008 11:00 am

Location: Mile High City

Post Tue Dec 04, 2012 4:30 pm

Re: TCP/UDP scanning questions!

You can't send a UDP packet to a TCP port. Both of those segments are only going to be seen as data instead of an IP packet. As the OS unpacks the frame > packet > segment and moves encapsulated data up the stack, it's going to check if there is a socket for that protocol and port. If not, it's going to discard the packet. It's not like the OS will try a TCP socket if a UDP socket isn't available, and vice versa. I mean, I guess it could, but that'd be a pretty messed up networking implementation :o
The day you stop learning is the day you start becoming obsolete.
<<

ZeroOne

Jr. Member
Jr. Member

Posts: 59

Joined: Tue Apr 24, 2012 7:41 am

Post Tue Dec 04, 2012 4:34 pm

Re: TCP/UDP scanning questions!

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,
Last edited by ZeroOne on Tue Dec 04, 2012 4:42 pm, edited 1 time in total.
<<

ZeroOne

Jr. Member
Jr. Member

Posts: 59

Joined: Tue Apr 24, 2012 7:41 am

Post Tue Dec 04, 2012 4:37 pm

Re: TCP/UDP scanning questions!

ajohnson, exactly, its just that when dealing with raw sockets.. you can mess things up badly (at least at your side).
Last edited by ZeroOne on Tue Dec 04, 2012 4:39 pm, edited 1 time in total.
<<

MaXe

User avatar

Hero Member
Hero Member

Posts: 671

Joined: Tue Aug 17, 2010 9:49 am

Post Tue Dec 04, 2012 6:53 pm

Re: TCP/UDP scanning questions!

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.)

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.)

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
Time
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: 74.207.244.221 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 (74.207.244.221)
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
I'm an InterN0T'er

Return to Network Pen Testing

Who is online

Users browsing this forum: No registered users and 2 guests

.
Powered by phpBB® Forum Software © phpBB Group.
Designed by ST Software