UDP and TCP Scans.
The transport layer is responsible for the transparent transfer of data between layers, from a source to a destination host via one or more networks. It can do this in a “reliable” fashion, which means the transport layer will retransmit if there is packet loss, or an “unreliable / best efforts” fashion, which means that data lost at lower layers must be retransmitted by some higher-layer application. Connectionless protocols ( UDP ) spread the state required to carry the data through every possible device while a connection oriented protocols ( TCP ) constrains the state to only those that are involved in the two-way communication process. These distinct differences affect network convergence and the way applications react to network failure. Connectionless, simply moves the data onto another path, while connections-orientated will have to build up the state again.
You can see from the packet header below that UDP is a lightweight protocol with little options to set. On the other hand, TCP has many options and flags that can influence communication.
Consider how these protocols work and respond to scans when they are enabled at your perimeter. The way these protocols interact with the network affects how they are viewed and scanned from the outside world. UDP simply sends a packet to the receiver with no mechanism for ensuring packet delivery and does not require a response from the target machine.This type of communication is often referenced to dropping a letter into a mailbox and not knowing if the receiver has opened it. So how does the design of these protocols affect the type of scans and results they offer?
A classic problem with UDP fingerprinting is that it is unlikely you will get a response back from the receiver. If the service is available and accepting UDP packets, the normal behavior for this service is to simply accept the packet but not send back a response to the sender. Likewise, a common firewall strategy is to absorb the packet and not send a response back to the sender – “if you can’t see me you can’t attack me” approach.
This is a very common case with UDP scans and they tend to result back with false positives. As a result of this behavior, most UDP scans provide very little information and mark nearly every port as “open|filtered”. Generally, a port is considered to be “open” if the scanning host does not receive back an Internet Control Message Protocol ( ICMP ) port unreachable message. To elicit more of a response you can optimize NMAP ( Network Mapper ) to include the “-sV” switch which will send special crafted packets to the ports that are listed as “open|filtered”. This can hopefully help us narrow down the results and generate ports to become “open|open”. Alternatively, you could go above Layer 4. For example, if you are doing an SNMP scanning, instead of looking for open UDP ports, you would send an “SNMP ping”. An SNMP ping is not like an ICMP ping. It operates above Layer 4 and simply requests the OID/object name universally present on all SNMP agents.
Another problem with UDP scans is that they are slow. UDP does not provide any error checking and in some cases the UDP CRC32 checksum is not supported by the IP stack being used. As a result, the scanning host usually sends three successive UDP packets and waits for at least one ICMP port unreachable message ( if the receiving host decides to generate a response ). The only way to go around this is to offset your stealth and generate multiple UDP scans in parallel.
In contrast, TCP is a connection-oriented protocol that uses a three-way handshake to create the communication session.
Its design makes is subject to a number of different scans which offer better results than a UDP scan. The most basic and stable type of scan is a TCP Connect scan. The scanning host attempts to complete the three-way handshake and tear down the session gracefully. This type of scan is not a “Stealth” scan and most applications will log the completion of a three-way handshake. If you want a faster or more stealthier scan, you could go for a TCP SYN scan. SYN scans are faster because rather than completing the entire three-way handshake, it only completes the first two steps of the process. If we consider the example of comparing the TCP three-way handshake to the analogy of someone making a phone call, an SYN scan would be similar to someone making a call but once the receiver picks up you say nothing and hang up. An SYN scan is the default NMAP scan.
Another useful scan which works by setting specific flags in the TCP header is called an XMAS scan. XMAS scans get their name due to the analogy of being “lit up like a Christmas tree”. The “lighting up” refers to the fact that the FIN, PSH, and URG packet flags are all set to “on” and the packet is “lit up like a Christmas tree”.
An XMAS crafted packet is highly unusual because it doesn’t have an SYN, ACK or RST flag set, violating traditional TCP communications. Why would you not set these flags? to elicit a response or not a response from the receiver. The RFC states that if an opened port receives a packet without an SYN, ACK or RST flag set, the packet should be ignored. As a result, NMAP is able to determine the port state without initiating or completing a connection to the target system but only if the target host’s operating system fully complies with the TCP RFC.
Consider early packet filters that would block inbound SYN packets in an attempt to stop a TCP three-way handshake. If no TCP three-way handshake could occur then no TCP communication can be originated from outside the filter. You need to take into consideration that the NMAP XMASS scan does not attempt to establish a full TCP session to determine what ports are open. It is true that this filter will prevent a TCP Connect scan but because an XMASS scan creates packets without the SYN flag set, it will bypass the filter.