[TryHackMe] Writeup — Nmap
Name: NMAP/Further Nmap
Difficulty: Easy
Description: Introduction to NMAP tool
Though I have been using NMAP at work for the past years, I approached this “room” with my “hunger for knowledge” self face on. I cannot thank you so much :D I devoured this room as if I do not know a single thing about NMAP. And yes, it didnt disappoint. I learned quite a lot and had fun doing it.
NMAP Intro
NMAP is open-source and comes pre-installed in Kali Linux. I first used this during my CCNA training/certification. NMAP is short for Network Mapper and used by network and system admins/security engineers to discover or audit network-connected devices such us client computers, servers, routers, switches etc. data from NMAP may be used for auditing, monitoring, inventory purposes.
Nmap uses raw IP packets in novel ways to determine what hosts are available on the network, what services (application name and version) those hosts are offering, what operating systems (and OS versions) they are running, what type of packet filters/firewalls are in use, and dozens of other characteristics. It was designed to rapidly scan large networks, but works fine against single hosts. Nmap runs on all major computer operating systems, and official binary packages are available for Linux, Windows, and Mac OS X.
For security professionals, NMAP is used to discover “alive” hosts, the services and ports that are open — all for the purpose of hacking it. You see information is the best friend of hackers.
Scan Types
TCP Connect scans (-sT)
To understand TCP Connect scans (-sT), it's important that you're comfortable with the TCP three-way handshake. If this term is new to you then completing Introductory Networking before continuing would be advisable.
As a brief recap, the three-way handshake consists of three stages. First the connecting terminal (our attacking machine, in this instance) sends a TCP request to the target server with the SYN flag set. The server then acknowledges this packet with a TCP response containing the SYN flag, as well as the ACK flag. Finally, our terminal completes the handshake by sending a TCP request with the ACK flag set.
This is one of the fundamental principles of TCP/IP networking, but how does it relate to Nmap?
Well, as the name suggests, a TCP Connect scan works by performing the three-way handshake with each target port in turn. In other words, Nmap tries to connect to each specified TCP port, and determines whether the service is open by the response it receives.
For example, if a port is closed, RFC 793 states that:
“… If the connection does not exist (CLOSED) then a reset is sent in response to any incoming segment except another reset. In particular, SYNs addressed to a non-existent connection are rejected by this means.”
In other words, 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. By this response, Nmap can establish that the port is closed.
If, however, the request is sent to an open port, the target will respond with a TCP packet with the SYN/ACK flags set. Nmap then marks this port as being open (and completes the handshake by sending back a TCP packet with ACK set).
This is all well and good, however, there is a third possibility.
What if the port is open, but hidden behind a firewall?
Many firewalls are configured to simply drop incoming packets. Nmap sends a TCP SYN request, and receives nothing back. This indicates that the port is being protected by a firewall and thus the port is considered to be filtered.
That said, it is very easy to configure a firewall to respond with a RST TCP packet. For example, in IPtables for Linux, a simple version of the command would be as follows:iptables -I INPUT -p tcp --dport <port> -j REJECT --reject-with tcp-reset
This can make it extremely difficult (if not impossible) to get an accurate reading of the target(s).
Which RFC defines the appropriate behaviour for the TCP protocol?
— RFC 793
If a port is closed, which flag should the server send back to indicate this?
— RST
SYN scans (-sS)
As with TCP scans, SYN scans (-sS) are used to scan the TCP port-range of a target or targets; however, the two scan types work slightly differently. SYN scans are sometimes referred to as "Half-open" scans, or "Stealth" scans.
Where TCP scans perform a full three-way handshake with the target, SYN scans sends back a RST TCP packet after receiving a SYN/ACK from the server (this prevents the server from repeatedly trying to make the request). In other words, the sequence for scanning an open port looks like this:
This has a variety of advantages for us as hackers:
• 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. Again, this plays into the idea of SYN scans being stealthy.
• 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, however, a couple of disadvantages to SYN scans, namely:
◇ They require sudo permissions[1] 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.
All in all, the pros outweigh the cons.
For this reason, SYN scans are the default scans used by Nmap if run with sudo permissions. If run without sudo permissions, Nmap defaults to the TCP Connect scan we saw in the previous task.
When using a SYN scan to identify closed and filtered ports, the exact same rules as with a TCP Connect scan apply.
If a port is closed then the server responds with a RST TCP packet. If the port is filtered by a firewall then the TCP SYN packet is either dropped, or spoofed with a TCP reset.
In this regard, the two scans are identical: the big difference is in how they handle open ports.
[1] SYN scans can also be made to work by giving Nmap the CAP_NET_RAW, CAP_NET_ADMIN and CAP_NET_BIND_SERVICE capabilities; however, this may not allow many of the NSE scripts to run properly.
There are two other names for a SYN scan, what are they?
-half-open, stealth
Can Nmap use a SYN scan without Sudo permissions (Y/N)?
-No
UDP Scans (-sU)
Unlike TCP, UDP connections are stateless. This means that, rather than initiating a connection with a back-and-forth “handshake”, UDP connections rely on sending packets to a target port and essentially hoping that they make it. This makes UDP superb for connections which rely on speed over quality (e.g. video sharing), but the lack of acknowledgement makes UDP significantly more difficult (and much slower) to scan. The switch for an Nmap UDP scan is (-sU)
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.
When scanning UDP ports, Nmap usually sends completely empty requests -- just raw UDP packets. That said, for ports which are usually occupied by well-known services, it will instead send a protocol-specific payload which is more likely to elicit a response from which a more accurate result can be drawn.
If a UDP port doesn't respond to an Nmap scan, what will it be marked as?
- open|filtered
When a UDP port is closed, by convention the target should send back a "port unreachable" message. Which protocol would it use to do so?
-icmp
