Nmap, short for "Network Mapper," is a free, open-source hacking tool used for network mapping, vulnerability checking & port scanning. It's currently the gold standard in terms of enumeration tools that provide the same functions.
Port Scanning is one of the most common ways to enumerate a system or application. Finding an open HTTP port or obtaining a system version # can lead to greater exploits if conducted correctly. Nmap provides many different scanning options.
There are 3 basic scans that are most commonly used:
TCP Connect Scan (-sT)
SYN Half-Open Scan (-sS)
UDP Scan (-sU)
There are several less common scan types that are still useful in certain environments.
TCP Null Scan (-sN)
TCP Xmas Scan (-sX)
TCP FIn Scans (-sF)
Most of these scans are used for similar purposes. However, the way they work differs and will provide different results depending on how the target is configured to respond. We'll go over some of the basics below.
TCP Connect Scans
TCP Connect Scans (-sT) are reliant on the TCP three way handshake. This process consists of three stages.
The client sends a TCP request to the target server with the SYN flag set.
The server acknowledges this packet with a TCP response containing the SYN flag, as well as the ACK flag.
The client completes the handshake by sending a TCP request with the ACK flag set.
During a TCP Connect Scan, Nmap tries to perform this three way handshake with each target port specified by the attacker to determine whether the service is open by the response it receives.
If Nmap sends a TCP request with the SYN flag set to a closed port, the target server will respond with a TCP packet with the RST (Reset) flag set. This indicates to Nmap that the port is closed.
Now, what if the target port is open but hidden behind a firewall?
Many firewalls are configured to simply drop incoming packets. For example, Nmap sends a TCP packet and receives no response. This indicates that the port is being protected by a firewall and the port is considered to be "filtered". This can make it extremely difficult to get an accurate reading on a target.
SYN Scans
As with TCP Scans, SYN Scans (-sS) are used to scan the TCP ports specified by the client. However, SYN scans don't attempt to complete the three way handshake to obtain results. SYN scans send back a RST/TCP Packet after receiving a SYN/ACK from a server. This prevents the server from trying to repeatedly make the request.
This has a variety of advantages:
It can be used to bypass older Intrusion Detection systems as they are looking out for a full three way handshake. This is often no longer the case with modern IDS solutions; it is for this reason that SYN scans are still frequently referred to as "stealth" scans.
SYN scans are often not logged by applications listening on open ports, as standard practice is to log a connection once it's been fully established.
Without having to bother about completing (and disconnecting from) a three-way handshake for every port, SYN scans are significantly faster than a standard TCP Connect scan.
There are some disadvantages to this method:
They require sudo or root permissions in order to work correctly in Linux. This is because SYN scans require the ability to create raw packets (as opposed to the full TCP handshake), which is a privilege only the root user has by default.
Unstable services are sometimes brought down by SYN scans, which could prove problematic if a client has provided a production environment for the test.
The pro's outweigh the con's in this instance but this may change depending on the network environment of the target. For this reason, SYN scans are the default scan run by Nmap if run with Sudo/Root privileges. If run without Sudo permissions, a TCP Connect scan will be conducted.
UDP Scans
Unlike TCP, UDP connections are stateless. This means that rather than initiating a connection through a handshake, UDP connections essentially send packets to the target port hoping they'll make it to their destination. UDP connections are great for communication that relies on speed over quality like video. However, the lack of acknowledgement makes UDP scans (-sU) more difficult & much slower.
When a packet is sent to an open UDP port, there should be no response. When this happens, Nmap refers to the port as being open|filtered. In other words, it suspects that the port is open, but it could be firewalled. If it gets a UDP response (which is very unusual), then the port is marked as open. More commonly there is no response, in which case the request is sent a second time as a double-check. If there is still no response then the port is marked open|filtered and Nmap moves on.
When a packet is sent to a closed UDP port, the target should respond with an ICMP (ping) packet containing a message that the port is unreachable. This clearly identifies closed ports, which Nmap marks as such and moves on.
Due to this difficulty in identifying whether a UDP port is actually open, UDP scans tend to be incredibly slow in comparison to the various TCP scans (in the region of 20 minutes to scan the first 1000 ports, with a good connection). For this reason it's usually good practice to run an Nmap scan with --top-ports <number> enabled. For example, scanning with "nmap -sU --top-ports 20 <target>". Will scan the top 20 most commonly used UDP ports, resulting in a much more acceptable scan time.
Null, Fin & Xmas Scans
NULL, FIN and Xmas TCP port scans are less commonly used than any of the others we've covered already. All three are interlinked and are used primarily as they tend to be even stealthier, relatively speaking, than a SYN "stealth" scan. Beginning with NULL scans:
NULL scans (-sN) are when the TCP request is sent with no flags set at all. As per the RFC, the target host should respond with a RST if the port is closed.
FIN scans (-sF) work in an almost identical fashion; however, instead of sending a completely empty packet, a request is sent with the FIN flag (usually used to gracefully close an active connection). Once again, Nmap expects a RST if the port is closed.
As with the other two scans in this class, Xmas scans (-sX) send a malformed TCP packet and expects a RST response for closed ports. It's referred to as an xmas scan as the flags that it sets (PSH, URG and FIN) give it the appearance of a blinking christmas tree when viewed as a packet capture in Wireshark.
The expected response for open ports with these scans is also identical, and is very similar to the UDP scan. If the port is open then there is no response to the malformed packet. Unfortunately (as with open UDP ports), that is also an expected behavior if the port is protected by a firewall, so NULL, FIN and Xmas scans will only ever identify ports as being open|filtered, closed, or filtered. If a port is identified as filtered with one of these scans then it is usually because the target has responded with an ICMP unreachable packet.
That said, the goal here is firewall evasion. Many firewalls are configured to drop incoming TCP packets to blocked ports which have the SYN flag set (thus blocking new connection initiation requests). By sending requests which do not contain the SYN flag, we effectively bypass this kind of firewall. While this is good in theory, most modern IDS solutions are savvy to these scan types, so don't rely on them to be 100% effective when dealing with modern systems.
Comments