nmap - Service Enumeration
Service Version Detection
It is recommended to perform a quick port scan first, which gives us a small overview of the available ports. This causes significantly less traffic, which is advantageous for us because otherwise we can be discovered and blocked by the security mechanisms. We can deal with these first and run a port scan in the background, which shows all open ports (-p-). We can use the version scan to scan the specific ports for services and their versions (-sV).
A full port scan takes quite a long time. To view the scan status, we can press the [Space Bar] during the scan, which will cause Nmap to show us the scan status.
Scanning Options
Description
10.129.2.28
Scans the specified target.
-p-
Scans all ports.
-sV
Performs service version detection on specified ports.
Another option (--stats-every=5s) that we can use is defining how periods of time the status should be shown. Here we can specify the number of seconds (s) or minutes (m), after which we want to get the status.
$ sudo nmap 10.129.2.28 -p- -sV --stats-every=5sWe can also increase the verbosity level (-v / -vv), which will show us the open ports directly when Nmap detects them.
Scanning Options
Description
10.129.2.28
Scans the specified target.
-p-
Scans all ports.
-sV
Performs service version detection on specified ports.
-v
Increases the verbosity of the scan, which displays more detailed information.
Banner Grabbing
Once the scan is complete, we will see all TCP ports with the corresponding service and their versions that are active on the system.
Scanning Options
Description
10.129.2.28
Scans the specified target.
-p-
Scans all ports.
-sV
Performs service version detection on specified ports.
Primarily, Nmap looks at the banners of the scanned ports and prints them out. If it cannot identify versions through the banners, Nmap attempts to identify them through a signature-based matching system, but this significantly increases the scan's duration. One disadvantage to Nmap's presented results is that the automatic scan can miss some information because sometimes Nmap does not know how to handle it. Let us look at an example of this.
Scanning Options
Description
10.129.2.28
Scans the specified target.
-p-
Scans all ports.
-sV
Performs service version detection on specified ports.
-Pn
Disables ICMP Echo requests.
-n
Disables DNS resolution.
--disable-arp-ping
Disables ARP ping.
--packet-trace
Shows all packets sent and received.
If we look at the results from Nmap, we can see the port's status, service name, and hostname. Nevertheless, let us look at this line here:
NSOCK INFO [0.4200s] nsock_trace_handler_callback(): Callback: READ SUCCESS for EID 18 [10.129.2.28:25] (35 bytes): 220 inlane ESMTP Postfix (Ubuntu)..
Then we see that the SMTP server on our target gave us more information than Nmap showed us. Because here, we see that it is the Linux distribution Ubuntu. It happens because, after a successful three-way handshake, the server often sends a banner for identification. This serves to let the client know which service it is working with. At the network level, this happens with a PSH flag in the TCP header. However, it can happen that some services do not immediately provide such information. It is also possible to remove or manipulate the banners from the respective services. If we manually connect to the SMTP server using nc, grab the banner, and intercept the network traffic using tcpdump, we can see what Nmap did not show us.
Tcpdump
Nc
Tcpdump - Intercepted Traffic
The first three lines show us the three-way handshake.
1.
[SYN]
18:28:07.128564 IP 10.10.14.2.59618 > 10.129.2.28.smtp: Flags [S], <SNIP>
2.
[SYN-ACK]
18:28:07.255151 IP 10.129.2.28.smtp > 10.10.14.2.59618: Flags [S.], <SNIP>
3.
[ACK]
18:28:07.255281 IP 10.10.14.2.59618 > 10.129.2.28.smtp: Flags [.], <SNIP>
After that, the target SMTP server sends us a TCP packet with the PSH and ACK flags, where PSH states that the target server is sending data to us and with ACK simultaneously informs us that all required data has been sent.
4.
[PSH-ACK]
18:28:07.319306 IP 10.129.2.28.smtp > 10.10.14.2.59618: Flags [P.], <SNIP>
The last TCP packet that we sent confirms the receipt of the data with an ACK.
5.
[ACK]
18:28:07.319426 IP 10.10.14.2.59618 > 10.129.2.28.smtp: Flags [.], <SNIP>
Last updated