nmap is a comprehensive network analysis tool for system and network administrators. Port scanning is a typical application for nmap. The aim is to find out whether a port is open, which application is running behind it and whether there are security gaps and vulnerabilities.
A simple port scanner will generally divide all ports into two or three states (open, closed, filtered). A port scanner like nmap pays attention to more details and knows a total of six port states.
If you want to use nmap effectively for port scanning, you should deal with these port states and know what each state means and how it should be interpreted. Only then can a qualified port scan be carried out.
The "Open" state means that an application or service is ready to accept TCP connections or UDP packets on this port. The aim of port scanning is to find "open ports". As a system administrator, you want to tap the listening application behind it for vulnerabilities. An attacker will attempt to exploit it.
In order to operate communication connections, however, open ports are required. However, every open port also represents a certain potential hazard. Every responsible system administrator therefore endeavors to limit the number of open ports in order to keep the attack surface as small as possible. For this reason, open ports are additionally protected or connection options are restricted.
You can only get an open port closed by switching off the responsible application or service. Or you can configure a packet filter so that connection attempts are rejected (not blocked).
The "Closed" state means that no application and no service on this port listens or listens to incoming data packets and connection attempts. The port is practically not used. No communication connections are possible on it.
A closed port is only closed as long as an application listens to this port and accepts connections and packets. To ensure that ports cannot be used accidentally, system administrators usually still block ports with a firewall (port filter).
However, a tool like nmap is able to bypass the filter and check whether the port is actually closed.
To protect open and closed ports, system administrators use a port filter. For example, they prevent connection attempts by port scans. Since a port scan only determines the status of a port, but should not establish a real connection because it does not know the underlying application, it can only send test packets to a port. The filter prevents these test packets from getting through. Usually these packets are discarded.
In this case, the port scanner does not get an answer. Then neither the status "open" or "closed" can apply to this port. There is a "filtered" or "blocked" state for this.
The filter used can be a classic firewall, a router rule or host-based firewall software. This means that many automated port scans can be kept away from the system.
For a pentester or hacker, filtered ports are a nuisance. Because a port scanner does not receive a response on a filtered port, the scanner must wait for a timeout before it can assume the "filtered" state. In addition, these ports must be checked several times to ensure that the packets have not been lost on the way (traditional packet loss). This has the effect of slowing down the port scan.
For this reason, nmap uses a variety of methods before a port scan to check whether the target system can be reached. Only then is a port scan carried out, in which a port that does not respond can be assumed to be "filtered".
Der Zustand "Ungefiltert" bedeutet, dass der Port zugänglich ist, aber nicht festgestellt werden konnte, ob er offen oder geschlossen ist. Dieser Zustand wird vom ACK-Scan erkannt, der verwendet wird, um eventuelle Firewall-Regeln zu umgehen.
Um festzustellen, ob ein ungefilterter Port offen ist, muss man ihn mit anderen Scan-Methoden wie dem Window-Scan, SYN-Scan oder FIN-Scan prüfen.
The state "Open | Filtered" means that the port cannot be clearly defined as open or closed. This occurs with scanning methods in which open ports do not give an answer. The lack of an answer can also indicate a filter.
The scan methods UDP, IP protocol, FIN, NULL and Xmas scan determine this state.
The state "Closed | Filtered" means that the port cannot be clearly defined as closed or filtered. The state arises when response packets do not come back as expected. For example, from hosts that are not RFC-compliant.
The FIN, NULL and Xmas scan methods are susceptible to this.
The number of ports ranges from 1 to 65,535. A port scan for all ports can take a long time and is usually also unnecessary. For this reason nmap scans by default only around 1,000 of the most used ports that are listed in the "nmap-services" database. With the option "-F" (for fast, German) you can limit the port scan to the 100 most used ports.
Basically, the more ports that are scanned, the longer it will take. If you scan not just a host, but an entire subnet, the number of port scans multiplies, and with it the duration of the scan and the network load. As an attacker on a protected and monitored system or network, you also become suspicious. Because a port scan for several thousand ports is not normal network traffic.
If you know in advance which ports are interesting, it makes sense to limit the port scan to individual ports. There is the option "-p".
The "-p22" option is used for port 22.
For the ports 22, 25 and 80 the option "-p22,25,80" is used.
For the ports from 1 to 100 the option "-p-100" is used.
For the ports from 80 to 88 use the option "-p80-88".
The option "-p60000-" is used for all ports over 60,000.
If you want to scan all ports from 1 to 65,535 use the option "-p-".
nmap is very flexible when it comes to specifying the scan target. This can be a domain name, an IP address or an entire subnet.
A port scan should not be applied to an entire subnet. Scanning an entire subnet can take a long time if the hosts have filtered ports. The port scan on a single host is more effective and does not take that long.
The output of nmap can be adapted to certain requirements. As a rule, you will choose the screen output (without option). If you want to write this output to a file, select the option "-oN". If you want to search the output with GREP, then select the option "-oG". If you want to have an XML file, choose the option "-oX".
All these options have in common that they can write the output to a file and therefore a file name has to be specified.
By default, nmap also pings the host once before each port scan. The reason for this is that a port scan for a host only makes sense if it can actually be reached. You can determine this with a ping scan. If you know that the host can be reached, you can do without the ping scan (-PN) and thus save a lot of time and bandwidth. It also prevents discovery by trying to reach systems that don't exist. Therefore, doing without the ping scan can make sense.
Why? If a host has a ping filter, this host is excluded from the port scan, although a port scan would have been successful. If the port scan does not require host detection or you want to bypass the ping filter, you can switch off the ping scan with the option "-PN" (no ping).
This way you can also hide your own intent, because a ping scan followed by a port scan is not normal network traffic.
A port scan makes sense if you have identified a target and want to check for other vulnerabilities. This port scan then begins with the selection of the correct scan method. nmap offers a large selection for this, the use of which must be carefully considered in order to obtain the desired information.
Most port scan methods are exotic in nature and are only used in certain situations. You will probably never enjoy the full use of all port scan methods.
Nevertheless, every port scan method has its authorization. It should be noted that remote network environments are not identical and sometimes only slightly different procedures are required to obtain the desired information or to discover vulnerabilities.
Sometimes it takes experience and a bit of cleverness to bypass filters and avoid detection by an IDS.
nmap -sP 192.168.0.1
The TCP ping scan is actually not a classic port scan, but rather a useful extension to a classic ping.
The TCP ping scan does not provide a representation of the port states. The aim of this nmap command is to check the accessibility of a host. How the ping scan works depends on where the host is located.
If the host is in the same subnet, the TCP ping scan works very traditionally with ARP requests (layer 2 of the OSI layer model). To do this, nmap only sends an ARP request and then outputs the available hosts that responded with an ARP reply. If you choose the subnet correctly, you can use it to determine all hosts in a local network. This TCP ping scan then shows all devices with an IPv4 address, MAC address and possibly host names in the subnet relatively reliably.
The ping scan is very inconspicuous in local networks because ARP requests occur to a large extent and the ARP requests triggered in this way are lost in the crowd.
If the host is on a different network. For example on the Internet. Then ARP stops working. It is necessary to establish a connection on higher protocols (layer 3 of the OSI layer model).
To do this, nmap first sends an ICMP echo request (ping) to the target system. If there is a response with an ICMP echo replay, nmap recognizes the target system as reachable. This would complete the ping scan.
Packet filters typically block such ICMP echo requests. Because this is known, nmap does not give up at this point and tries with a TCP ping. To do this, nmap sends a TCP-SYN packet on port 443 and a TCP-ACK packet on port 80 to the target system. Typically, the target system will respond with SYN / ACK (on port 443) and RST (on port 80). This should make the target system fairly certain to be reachable.
nmap -sT 192.168.0.1
With the full connect scan, nmap tries to establish a real connection with a port. The complete three-way handshake is run through. You want to know whether a connection to an application works before you check that application for vulnerabilities. Depending on the status of the port, the port scan will produce a different result.
OPEN: SYN -> SYN+ACK -> ACK
CLOSED: SYN -> RST (The target system replies with an RST packet)
FILTERED: SYN -> no response (The SYN packet is discarded at the target system)
The three-way handshake provides for SYN and SYN / ACK in the first two steps. An ACK follows, whereby the connection is confirmed and thus established. Normally, a TCP connection would be terminated with another handshake. In this case nmap forces an RST packet to end the connection immediately.
The full connect scan looks like a normal connection setup for the target system. Usually there will be no suspicion that the system is being spied on open ports. However, full connections are usually recorded in log files. If they are evaluated, you can understand the preparations for a subsequent attack. The attacker thus reveals himself or his intentions.
Another disadvantage is that a single full-connect scan naturally takes longer because the entire connection has to be established. Other scanning methods that only send a single packet are faster.
One advantage is that some services send service information on their own. For example, an OpenSSH server sends its SSH banner string. The version of OpenSSH is also there, for example.
The full connect scan is the standard scan. It is automatically applied when nmap is called up by an unauthorized user. Under Windows the system administrator and under Linux the user "root" would be allowed to use nmap without restrictions.
It is also used for IPv6 targets because other scanning methods do not work here.
nmap -sS 192.168.0.1
The SYN-Scan is the fastest and most used scan method. It allows a reliable differentiation between the states closed and filtered. If the network is fast enough, you can scan several thousand ports in a few seconds.
The SYN scan is also known as a halfopen or stealth scan. It is based on the fact that the three-way handshake is only initiated, but not confirmed with ACK, but canceled early with RST.
OPEN: SYN -> SYN+ACK -> RST
CLOSED: SYN -> RST (The target system replies with an RST packet)
FILTERED: SYN -> no response (the SYN packet is discarded at the target system)
By not immediately confirming the TCP connection with ACK, but immediately terminating with RST, the scan speed is about 30 to 40% faster than with the full connect scan.
The SYN scan often goes unnoticed because, as a rule, only full connections are logged during use. It is disadvantageous for the attacker or pentester that the SYN scan can be recognized by an IDS, because the process is rather atypical for a "normal connection".
Almost all RST packets sent by nmap also contain a set ACK bit. The reason is that a TCP packet is usually always the answer or confirmation of a received packet.
The TCP-FIN / XMAS / NULL scan are scanning methods that only make sense if you suspect a firewall that is blocking the ports. In order to examine the systems behind it anyway, these special scanning methods are used. Unfortunately, the results of these port scans depend on a particular behavior of the target host. Some systems do not behave as desired, which is why the results must always be questioned.
The TCP FIN scan simulates the termination of a connection:
nmap -sF 192.168.0.1
The TCP-XMAS scan sends a packet with set FIN, PSH and URG flags to the destination at the same time:
nmap -sX 192.168.0.1
The TCP NULL scan sends a packet to the destination without any TCP flags set:
nmap -sN 192.168.0.1
Such port scans are of course difficult to recognize as such, because unexpected TCP packets arrive here. However, this also means that XMAS and NULL SCAN can lead to unexpected reactions. You have to expect that old devices will crash.
OPEN: FIN/XMAS/NULL -> no response
CLOSED: FIN/XMAS/NULL -> RST
FILTERED: FIN/XMAS/NULL -> no response
When scanning systems that work RFC-compliant (RFC 793), any packet that does not contain a SYN, RST or ACK bit results in an RST having to be sent back when the port is closed no response if the port is open. Nmap takes advantage of these three types of scans to find out whether a port is open or closed.
With a FIN / XMAS / NULL scan, you can often get past firewalls, which is why it is definitely part of a pentest. In the context of an attack, this makes it very easy to find out which ports may be open if the status of ports could not be found by a normal port scan. The disadvantage is that you cannot differentiate between OPEN and FILTERED.
Stateless firewalls and packet-filtering routers try to prevent incoming TCP connections (while allowing them to the outside) by blocking all TCP packets with the SYN bit set and the ACK bit cleared. That happens quite often. This rule is simply ignored by the FIN, XMAS and NULL scans.
nmap -sU 192.168.0.1
Some system administrators, who are otherwise very careful, occasionally forget that in addition to TCP, there is also connectionless UDP (User Datagram Protocol). UDP packets are often not filtered because experience has shown that many system administrators do not expect any attacks here.
OPEN: no response or response via UDP
CLOSED: ICMP-response "unreachable"
FILTERED: no response
Since UDP does not require a three-way handshake, only any UDP packet is sent to the port here. A disadvantage for the pentester and attacker is that the UDP scan is very slow. The reason is that the state of a port can only be defined when a response comes back. If not, then a timeout must be waited for.
Scanning UDP ports is also very difficult for another reason. To get the status of a port you need an answer. However, UDP is a connectionless protocol. A packet sent via TCP usually always receives an answer. However, a packet sent via UDP does not necessarily do so. This means that if no response comes back, then you do not know whether the UDP packet has arrived at all. Open UDP ports only respond if the protocol at the application level provides for this.
To make matters worse, nmap sends empty UDP packets by default because it cannot know which application is listening behind the port to be scanned. And that's why there is rarely a response here that clearly identifies the port as "open". And only when an ICMP port unreachable message comes back is the port clearly recognizable as "closed". Other ICMP error messages are interpreted as "filtered". If there is no response, "open | filtered" is therefore assumed.
The problem is that it cannot be clearly determined whether the correct protocol should simply have been used or whether the packet was blocked by a firewall.
nmap -sA 192.168.0.1
The TCP-ACK scan differs fundamentally from all other port scan methods. This is NOT about determining open ports. This method is only used to determine whether the firewall rules used are stateful or not and to determine which ports are filtered.
The disadvantage is that it cannot distinguish between open and closed ports. You have to determine this with another port scan method.
nmap -sW 192.168.0.1
A window scan is comparable to an ACK scan. The difference is that it can differentiate between open and closed ports on some computers.
nmap -sM 192.168.0.1
This scan method is similar to a FIN scan, but contains a set ACK bit. So you might get past packet filters. However, it works less often than with the FIN scan.
nmap -sI 192.168.0.1
The idle scan is the most inconspicuous, complex and therefore slowest of all scanning methods.
nmap -sO 192.168.0.1
Technically, the IP protocol scan is not a port scan, but is used to determine which IP protocols (TCP, ICMP, IGMP, etc.) are supported on the target computer. This scan goes through protocol numbers and not port numbers.
With the option "-p" you can specify the protocol numbers to be scanned.
This scanning method is considered obsolete. It uses a faulty FTP server as a proxy. Because most FTP servers fix this, it rarely works. But if it does, it's one way to get around the firewall limitation.