Nmap - Network discovery and security auditing tool
Nmap “Network Mapper” is a free and open-source tool used for network discovery and security auditing. Many systems and network administrators additionally think that its value for errands, for example, monitoring host or service uptime, network inventory, and managing service upgrade schedules. Network Mapper utilizes raw IP packets in novel approaches to figure out what hosts are accessible on the system, what services those hosts are offering, what working frameworks they are running, what sort of packet filters/firewalls are being used, and many different attributes.
It was intended to scan vast networks; however, it works fine against single hosts as well. Nmap keeps running on all major operating frameworks, and official binary packages are accessible for Mac OS X, Windows, and Linux. Notwithstanding the tremendous command-line Nmap executable, this suite has a propelled GUI version called “Zenmap,” which incorporates an adaptable information transfer, redirection, and troubleshooting instrument “Ncat,” a packet generation and response analysis tool “Nping,” and a utility for comparing scan results “Ndiff.”
The packets that Network Mapper conveys come back with IP addresses and an abundance of other information, enabling you to recognize a wide range of system traits, giving you a profile or map of the network, and allowing you to make a hardware and software inventory. Various protocols utilize various types of packet structures. Nmap utilizes transport layer protocols, including TCP, UDP, and SCTP, as well as supporting protocols like ICMP, which is used to send error messages.
Some protocols have different purposes and serve different system ports. For instance, the low resource overhead of UDP is suited for real-time video streaming, where you sacrifice some packet lost in return for speed, while non-real-time video streamings on YouTube are buffered and use the slower, more reliable TCP. Along with its many other features, Network Mapper’s basic port scanning and packet-capture capabilities are continually enhanced.
Let’s get to know some useful command-line-based scans that can be performed using Nmap. To start the tool, type “nmap” in the terminal and it’ll display the help menu with all possible options and usage information.
Basic scanning techniques
Scan a single target
To scan a single host, specify the IP address of your target after the “nmap” command.
Ex: (root@kali:~# nmap 10.10.10.7).
If you want to scan a hostname, replace the IP for the host.
Ex: (root@kali:~# nmap example.com).
These sorts of fundamental scans are ideal for your initial steps when beginning with Nmap.
Scan a range of hosts
You can specify the range of hosts using the “-” sign after the fourth octet of the IP address.
Ex: (root@kali:~# nmap 10.10.10.1–10).
Nmap can scan all possible ports, but you can also scan specific ports by providing a “-p” parameter.
Ex: (root@kali:~# nmap -p 1–65535 10.10.10.1–10).
Perform an aggressive scan
Nmap has a special flag “-A,” which activates an aggressive detection. Aggressive mode enables OS detection (-O), version detection (-sV), script scanning (-sC), and traceroute (–traceroute). This mode sends a lot more probes, and it is more likely to be detected but provides a lot of valuable host information. You can try aggressive detection with the following command: (root@kali:~# nmap -A 10.10.10.7).
Discovery options
Perform a ping scan only
Ex: (root@kali:~# nmap -sP 10.10.10.1–10).
When you run this command, Nmap tries to ping the given IP address range to check if the hosts are alive. If the ping fails, it will try to send “SYN” packets to port 80. It is not a hundred percent reliable because of modern host-based firewalls like Windows block ping and port 80 by default. When hosts on the network are blocking ping, and port 80 is not accepting connections, then Nmap assumes that the host is down.
One of the options you can use is the “-P0” flag to skip the host discovery process and jump to port scan on all the IP addresses. In this case, even unoccupied IP addresses will be scanned. It will take a lot of time to finish the scan even if you are in a small network, but you’ll see the complete results.
The better option would be to provide custom ports for scanning. Nmap enables you to probe specific ports with “SYN/UDP” packets. It is generally recommended to examine commonly used ports, e.g., TCP-22 (SSH) or TCP-3389 (windows remote desktop), or UDP-161 (SNMP).
Ex: (root@kali:~# nmap -sP -PS 22,3389 10.10.10.1–10).
Ex: (root@kali:~# nmap -sP -PU 161 10.10.10.1–10).
Perform a scan without ping
The “-PN” flag lets Nmap assume that the host is online regardless if it can ping the host or not, it should consider the host as up. Disabling the host discovery process with “-PN” causes Nmap to try the requested scanning functions against every target IP address specified.
Ex: (root@kali:~# nmap -PN 10.10.10.1–10).
TCP SYN ping
This choice sends an empty TCP packet with the “SYN” banner set to the destination port 80. The “SYN” banner proposes to the remote framework that you are endeavoring to build up a connection. Regularly the destination port will be shut, and an “RST” packet will be sent back. If the port is open, the objective will make the second stride of a TCP three-way-handshake by responding with a “SYN/ACK” packet.
The device running Nmap then tears down the nascent connection by responding with an “RST” instead of sending an “ACK” packet, which would finish the three-way-handshake and build up a full connection. The “RST” packet is sent by the device running Nmap because of the surprising “SYN/ACK,” not by Nmap itself. Nmap does not mind whether the port is open or shut. Either the “SYN/ACK” or “RST” response discussed previously tells Nmap that the host is available and responsive.
Ex: (root@kali:~# nmap -PS 10.10.10.1–10).
TCP ACK ping
The TCP “ACK” ping is very similar to the “SYN” ping. The distinction, as you could probably figure, is that the TCP “ACK” banner is set rather than the “SYN” banner. The “ACK” packet implies recognizing information over a built-up TCP association, yet no such association exists. So, remote hosts ought to consistently react with an “RST” packet, uncovering their existence in the process.
Ex: (root@kali:~# nmap -PA 10.10.10.1–10).
UDP ping
Another host disclosure choice is the UDP ping, which sends a UDP packet to the given ports.
For most ports, the packet will be vacant; however, some use a protocol-specific payload that is bound to evoke a reaction. The port rundown accepts a similar arrangement as with the recently examined “-PS” and “-PA” choices. If no ports are determined, the default is 40125. An exceptionally different port is used, of course, since sending to open ports is frequently unfortunate for this specific sweep type. Upon hitting a shut port on the objective machine, the UDP probe should evoke an “ICMP port unreachable” packet consequently. It connotes to Nmap that the device is up and accessible.
Different kinds of ICMP errors like “host unreachable,” “network unreachable,” or “TTL exceeded” are characteristic of a down or inaccessible host. An absence of response is additionally deciphered along these lines. In the event that an open port is reached, most services mainly overlook the empty packet and neglect to return any response. That is why the default probe port is 40125, which is immensely unlikely to be in use.
Ex: (root@kali:~# nmap -PU 10.10.10.7).
SCTP Init ping
This alternative sends an SCTP packet containing a negligible “INIT” packet. The “INIT” tells the remote framework that you are endeavoring to build up an association. Ordinarily, the destination port will be shut, and an “ABORT” packet will be sent back. On the off chance that the port happens to be open, the objective will make the second stride of an SCTP four-way-handshake by responding with an “INIT-ACK” packet.
If the machine running Nmap has a practical SCTP stack, at that point, it tears down the beginning connection by reacting with an “ABORT” packet as opposed to sending a “COOKIE-ECHO” packet, which would be the following stage in the four-way-handshake. The “ABORT” packet is sent by the part of the machine running Nmap in light of the unforeseen “INIT-ACK,” not by Nmap itself. Nmap does not mind whether the port is open or shut. Either the “ABORT” or “INIT-ACK” response discloses to Nmap that the host is accessible and responsive.
Ex: (root@kali:~# nmap -PY 10.10.10.1–10).
ICMP echo ping
Notwithstanding the unordinary TCP and UDP host disclosure types talked about already, Nmap can send the standard packets used by the universal ping program. It can send an ICMP type 8 (echo request) packet to the target IP addresses, anticipating a type 0 (echo reply) consequently from accessible hosts. As noted toward the start of this section, numerous hosts and firewalls currently block these packets, as opposed to responding as required by RFC 1122.
Therefore, ICMP-only scans are once in a while dependable enough against unknown targets over the Internet. In any case, for system administrators monitoring an internal system, this can be a useful and productive methodology. Use the “-PE” operator to enable this echo request behavior.
Ex: (root@kali:~# nmap -PE 10.10.10.1–10).
ARP ping
ARP ping sweeps are one of the best methods for distinguishing hosts in your local area network. To perform ARP ping, use the following command: (root@kali:~# nmap -PR 10.10.10.1–10).
Traceroute
Nmap’s traceroute algorithm is designed to perform a traceroute on many targets in parallel, without duplicating work for routes. It accomplishes this by starting the TTL as near as possible to the target’s actual distance (number of IP hops) and counting downwards until an already-known hop is encountered.
Ex: (root@kali:~# nmap – -traceroute 10.10.10.7).
Advanced scanning options
TCP SYN scan
“SYN” scan is the default and most common sweep choice for valid justifications. It very well may be performed rapidly, filtering a considerable number of ports every second on a fast network not blocked by restrictive firewalls. It is likewise moderately unpretentious and stealthy since it never finishes TCP connections. This method is regularly alluded to as half-open scanning because you don’t open a full TCP association. You send a “SYN” packet, as though you are going to open a genuine connection, and after that, wait for a response.
A “SYN/ACK” shows the port is listening, while an “RST” is demonstrative of a non-listener. On the off chance that no response is received after a few retransmissions, the port is set apart as filtered. The port is likewise checked filtered if an ICMP unreachable error is obtained. The port is similarly viewed as open if a “SYN” packet without the “ACK” banner is received in response. It can be because of an amazingly uncommon TCP highlight known as an asynchronous open or split handshake association.
Ex: (root@kali:~# nmap -sS 10.10.10.7).
TCP connect scan
TCP connect scan is the default TCP scan type when the “SYN” scan isn’t a choice. It is the situation when a client does not have raw packet benefits. Rather than composing raw packets as most other scan types do, Nmap asks the basic working framework to build up an association with the objective machine and port by issuing the connect system call. It is a similar high-level system framework call that internet browsers, P2P clients, and most other network-empowered applications use to build up a connection.
Ex: (root@kali:~# nmap -sT 10.10.10.7).
UDP scan
While most mainstream benefits on the Internet keep running over the TCP convention, UDP services are broadly deployed also. DNS, SNMP, and DHCP are three of the most widely recognized. Since UDP scanning is by and large increasingly slow and troublesome than TCP, some security auditors overlook these ports. It is a slip-up, as exploitable UDP services are prevalent, and assailants positively don’t ignore the entire convention. The UDP scanning method works by sending a UDP packet to each focused-on port.
If an “ICMP port unreachable” (type 3, code 3) error is returned, then we assume that the port is shut. Other ICMP unreachable errors (type 3, codes 0, 1, 2, 9, 10, or 13) mark the port as filtered. At times, a service will react with a UDP packet, demonstrating that it is open. On the off chance that no response is received after retransmissions, the port is delegated “open|filtered.” It implies the port could be open, or maybe packet channels are obstructing the communication. Version detection “-sV” parameter can be utilized to help separate the open ports from the filtered ones.
Ex: (root@kali:~# nmap -sU 10.10.10.7).
TCP Null scan
A Null scan is a progression of TCP packets that contain an arrangement number of 0 and no set banners. In a business environment, there will never be a TCP packet that doesn’t include a banner. Since the Null scan does not provide any set of flags, it can some of the time enter firewalls and edge routers that filter incoming packets with specific banners.
Ex: (root@kali:~# nmap -sN 10.10.10.7).
TCP FIN scan
The standard utilization of a “FIN” packet is to end the TCP association — regularly after the data transfer is complete. Rather than a “SYN” packet, Nmap starts a “FIN” check by utilizing a “FIN” packet. Since there is no previous correspondence between the scanning host and the objective host, the objective reacts with an “RST” packet to reset the association. However, resetting the connection reveals its presence.
Ex: (root@kali:~# nmap -sF 10.10.10.7).
Xmas scan
Xmas scans get their name from the arrangement of banners that are turned on inside a packet. These scans are intended to control the “PSH,” “URG,” and “FIN” banners of the TCP header. At the point when seen inside Wireshark, we can see that substituting bits are enabled, or “Flickering,” much like you would illuminate a Christmas tree. Indeed, even with the non-compromising name, we should treat Xmas filters with caution similarly as we would with any system scan. This scan uses a loophole with the TCP RFC to differentiate between open and closed ports.
Perform a fast scan
Fast scan determines that you wish to scan fewer ports than the default. Ordinarily, Nmap scans the most widely recognized 1,000 ports for each scanned protocol. With the “-F” flag, this is decreased to 100.
Ex: (root@kali:~# nmap -F 10.10.10.1–10).
Scan specific ports
This option determines which ports you need to scan and supersedes the default option. Single port numbers are entered individually, as are ranges separated by a hyphen.
Ex: (root@kali:~# nmap -p 22 10.10.10.1–10).
Ports can likewise be specified by name as indicated by what the port is alluded to in the Nmap services.
Ex: (root@kali:~# nmap -p http 10.10.10.1–10).
When scanning a combination of conventions like TCP and UDP, you can indicate a specific protocol by preceding the port numbers using the letter “T:” for TCP, “U:” for UDP, “S:” for SCTP, or “P:” for IP Protocol.
Ex: (root@kali:~# nmap -sU -sT -p U:53,T:80 10.10.10.1–10).
You can also use wildcards like “*” or “?” to perform a custom scanning technique. For example, let’s use “*” with the “-p” option to scan all possible ports of a specific target.
Ex: (root@kali:~# nmap -p “*” 10.10.10.7).
Version detection
Operating system detection
One of Nmap’s best-realized highlights is remote OS detection, utilizing TCP/IP stack fingerprinting. Nmap sends a progression of TCP and UDP packets to the remote host and looks at virtually every piece in the responses. After performing many tests like TCP initial sequence numbers (ISN) inspecting, TCP options support and ordering, IP ID examining, and the underlying window size check — the Nmap looks at the outcomes to its “nmap-os-db” database of more than 2,600 known OS fingerprints, and prints out the OS subtleties if there is a match.
Each fingerprint incorporates a free-form printed depiction of the OS, and a grouping that gives the vendor name, underlying OS, Operating System generation, and device type. Most fingerprints additionally have a Common Platform Enumeration (CPE) portrayal.
Ex: (root@kali:~# nmap -O 10.10.10.1–10).
Comprehensive OS detection
This alternative empowers extra progressed and forceful choices. Presently this enables OS discovery “-O,” version checking “-sV,” script scanning “-sC” and traceroute “ –traceroute.” The fact of the matter is to empower a complete arrangement of sweep choices without individuals to remember a vast provision of banners. Nonetheless, in light of the fact that script scanning with the default set is viewed as intrusive, you ought not to utilize the “-A” option against target systems without authorization.
Ex: (root@kali:~# nmap -A 10.10.10.1–10).
Attempt to guess an unknown OS
At the point when Nmap can’t identify an ideal OS match, it once in a while offers up near-matches as conceivable outcomes. The match must be extremely close for Nmap to do this as a matter of course. Both of these identical choices make Nmap guess more aggressively. Nmap will, in any case, disclose to you when an imperfect match is printed and show its certainty level for each guess.
Ex: (root@kali:~# nmap -O – -osscan-guess 10.10.10.1–10).
Service version detection
Point Nmap at a remote device, and it may disclose to you that ports 25/TCP, 80/TCP, and 53/UDP are open. Utilizing its Nmap-services database of around 2,200 well-known services, Nmap would report that those ports most likely compare to a mail server (SMTP), web server (HTTP), and name server (DNS) respectively. This query is typically precise — by far, most of the daemons tuning in on TCP port 25 are, indeed, mail servers. Be that as it may, you should not wager your security on this! Individuals can and do run services on peculiar ports. Version detection can be enabled and controlled with the following “-sV” option.
Ex: (root@kali:~# nmap -sV 10.10.10.1–10).
Troubleshooting version scan
This option causes Nmap to print out broad troubleshooting data regarding what version scanning is doing. It is a subset of what you receive with “- -packet-trace.”
Ex: (root@kali:~# nmap -sV – -version-trace 10.10.10.1–10).
Perform an RPC scan
This particular type of sweep searches for machines answering RPC (Remote Procedure Call) services. RPC enables remote commands to be kept running on the device under specific conditions, which can be risky. Since RPC services can keep running on a wide range of ports, it is difficult to tell from an ordinary output which one may run RPC. It’s a good practice to run one of these scans once in a while to find out if and where you have these services running.
Ex: (root@kali:~# nmap -sR 10.10.10.1–10).
Timing and performance
Nmap offers a more straightforward methodology, with six timing formats. You can indicate them with the “-T” operator and their number (0–5) or their name. The format names are paranoid (0), sneaky (1), polite (2), normal (3), aggressive (4), and insane (5). The initial two are for IDS avoidance. Polite mode hinders the sweep to utilize less data transfer capacity and target machine assets. Normal mode is the default; thus, “-T3” sits idle. Aggressive mode speeds up the scans by making the supposition that you are on a sensibly quick and dependable system. At last insane mode expect that you are on an uncommonly fast network or are eager to sacrifice some accuracy for speed.
Paranoid (0): Intrusion detection system evasion.
Ex: (root@kali:~# nmap -T0 10.10.10.7).
Sneaky (1): Intrusion detection system evasion.
Ex: (root@kali:~# nmap -T1 10.10.10.7).
Polite (2): Slows down the scan to utilize less bandwidth and target machine resources.
Ex: (root@kali:~# nmap -T2 10.10.10.7).
Normal (3): It is a default speed.
Ex: (root@kali:~# nmap –T3 10.10.10.7).
Aggressive (4): Speeds the scanning process, assumes you are on a reasonably fast and reliable network.
Ex: (root@kali:~# nmap –T4 10.10.10.7).
Insane (5): Speeds the scanning process, assumes you are on an extraordinarily fast network.
Ex: (root@kali:~# nmap –T5 10.10.10.7).
Firewall evasion techniques
Fragment packets
This strategy was viable, particularly in the past times; anyways, you can use it on the off chance that you found a firewall that isn’t appropriately configured. The Nmap provides the ability to fragment the packets while examining with the “-f” option so it can sidestep the packet examination of firewalls.
Ex: (root@kali:~# nmap -f 10.10.10.1–10).
Specify a specific MTU
You can likewise determine your offset size with the “- -mtu” (Maximum Transmission Unit) option. It is like the packet fragmentation procedure that we have mentioned previously. During the scanning process, the Nmap will make packets with size dependent on the number that we specify. In this example, we provided the number 32, so the Nmap will send 32-byte packets making confusion to the firewall.
Ex: (root@kali:~# nmap – -mtu 32 10.10.10.1–10).
Randomize target scan order
This choice advises Nmap to rearrange each group of up to 16384 hosts before it scans them. This can make the scans more subtle to different system monitoring frameworks, particularly when you join it with slow timing alternatives.
Ex: (root@kali:~# nmap – -randomize-hosts 10.10.10.1–10).
Send scans from spoofed IPs
In this type of scanning method, you instruct Nmap to spoof packets from different hosts.
So in the firewall logs, the scanning attempt will be made not only by our IP address but also by the decoy IP addresses. It will be much harder for network administrators to determine which system started the scan. There are two options that you can utilize in this type of scan:
· To generate a random number of decoys, use the “nmap -D RND:10 [target]” command.
· To manually specify the IP addresses of the decoys, use the “nmap -D decoy1,decoy2,decoy3,etc” command.(root@kali:~# nmap -D decoy-ip1, decoy-ip2, decoy-ip3, [your-own-ip] [ remote-host-ip])
Ex: (root@kali:~# nmap -D 10.10.10.1,10.10.10.20,10.10.10.23,10.10.10.4 10.10.10.7).
Scan target from different IP
In certain conditions, Nmap will be unable to decide your source address. In this circumstance, use the “-S” option with the IP address of the interface you wish to send packets through. Another conceivable utilization of this banner is to spoof the sweep to make the objectives feel that another person is scanning them.
Ex: (root@kali:~# nmap -e eth0 -Pn -S 10.10.10.6 10.10.10.7).
Spoof source port number
A typical mistake that numerous administrators are doing when arranging firewalls is to set up a standard to permit all approaching traffic that originates from a particular port number. The “ – -source-port” or “-g” options of Nmap can be utilized to abuse this misconfiguration. Standard ports that you can use for this sort of scan are 20, 53, and 67.
Ex: (root@kali:~# nmap -g 53 10.10.10.7).
Append random data to sent packets
Numerous firewalls are investigating packets by taking a gander at their size to recognize a potential port scan. It is because multiple scanners are sending packets that have specific sizes. In request to maintain a strategic distance from that sort of discovery, you can utilize the option “- -data-length” to add extra information and to send bundles with unexpected size in comparison to the default.
Ex: (root@kali:~# nmap – -data-length 200 10.10.10.7).
While port scanning isn’t illegal in and of itself, at least according to US federal law, malicious hackers may use Nmap’s features to look for vulnerabilities to exploit. Even if you’re doing a vulnerability scan for benign reasons, certain uses of the software, particularly without permission, will get you fired or into legal trouble.
Some Nmap scans are relatively light touch and may not trigger alerts, it’s always a good idea to get your scans reviewed by the relevant people in your company. Many Nmap features, such as OS fingerprinting, necessitate root access. When in doubt about the legality of anything you want to do, consult a lawyer who specializes in computer fraud and abuse, particularly if you’re working alone and don’t have access to an organization’s legal team.