Version Detection (-sV)
Requires Privileged Access: NO
Identifies TCP Ports: NO
Identifies UDP Ports: NO
Most of nmap's scanning methods are based around the identification of port numbers. However, the version detection scan is most interested in the software applications running on a remote device.
For version detection to work properly, nmap relies on the nmap-service-probes file to provide a series of probes and the expected responses. If the nmap-service-probes support file is not available, the version detection scan will not run.
Although other 3rd-party applications have implemented methods of version detection, the process used by the version detection scan is unique to nmap.
USAGE NOTE: On nmap 3.81 using both Linux and Windows, I was able to specify the version detection (–sV) option on the command line with the list scan (-sL), the ping scan (-sP), and the IP protocol scan (-sO). Technically speaking, the list scan, ping scan, and IP protocol scan will not run with other scan types on the command line. The version scan parameter was accepted on the command line with these individual scan types, but the version scan did not run and no error message was displayed. To see if the version scan was even active, I removed the nmap-service-probes file and received an error message.
Version Detection Operation
The version detection scan runs in conjunction with another scan type that will identify open ports. If another scan type is not specified on the command line, nmap will run a TCP SYN scan (for a privileged user) or a TCP connect() scan (for non-privileged users) prior to running the version detection scan.
If open ports are found, the version detection scan will begin the probing process with the remote device. The version detection scan communicates directly with the remote application to uncover as much information as possible.
In this example, the default TCP SYN scan runs prior to the version detection scan to identify the open port:
Source Destination Summary -------------------------------------------------------------------------------------- [192.168.0.8] [192.168.0.10] TCP: D=80 S=54490 SYN SEQ=3420003014 LEN=0 WIN=1024 [192.168.0.10] [192.168.0.8] TCP: D=54490 S=80 SYN ACK=3420003015 SEQ=1473373778 LEN=0 WIN=65535 [192.168.0.8] [192.168.0.10] TCP: D=80 S=54490 RST WIN=0After the TCP SYN scan identifies port 80 as open, the version detection process begins. The process shown in this example is for this specific example. Other ports and application will operate differently.
Source Destination Summary -------------------------------------------------------------------------------------- [192.168.0.8] [192.168.0.10] TCP: D=80 S=39330 SYN SEQ=4090323855 LEN=0 WIN=5840 [192.168.0.10] [192.168.0.8] TCP: D=39330 S=80 SYN ACK=4090323856 SEQ=166204426 LEN=0 WIN=65535 [192.168.0.8] [192.168.0.10] TCP: D=80 S=39330 ACK=166204427 WIN<<2=5840 [192.168.0.8] [192.168.0.10] HTTP: C Port=39330 GET / HTTP/1.0 [192.168.0.10] [192.168.0.8] HTTP: R Port=39330 HTTP/1.1 Status=OK-1494 bytes of content \ [192.168.0.8] [192.168.0.10] TCP: D=80 S=39330 ACK=166205875 WIN<<2=8736 [192.168.0.10] [192.168.0.8] HTTP: Continuation of frame 2398;468 Bytes of data [192.168.0.8] [192.168.0.10] TCP: D=80 S=39330 FIN ACK=166206344 SEQ=4090323874 LEN=0 WIN<<2=11632 [192.168.0.10] [192.168.0.8] TCP: D=39330 S=80 ACK=4090323875 WIN<<0=65517The scan output displays the application information for each open port, although not all version numbers in this example were identified. The open ports were located by a TCP SYN scan that ran prior to the version scan.
In this example, an open TCP port 520 was located by the SYN scan but the version scan did not recognize the service. A fingerprint was created and nmap provided an URL to use for submission of the unknown service (the URL has been intentionally obfuscated in this document for security reasons).
# nmap -sV -v 192.168.0.10 Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-04-11 12:41 EDT Initiating SYN Stealth Scan against 192.168.0.10 [1663 ports] at 12:41 Discovered open port 80/tcp on 192.168.0.10 Discovered open port 3389/tcp on 192.168.0.10 Discovered open port 3306/tcp on 192.168.0.10 Discovered open port 445/tcp on 192.168.0.10 Discovered open port 135/tcp on 192.168.0.10 Discovered open port 139/tcp on 192.168.0.10 Discovered open port 520/tcp on 192.168.0.10 The SYN Stealth Scan took 1.54s to scan 1663 total ports. Initiating service scan against 7 services on 192.168.0.10 at 12:41 The service scan took 100.01s to scan 7 services on 1 host. Host 192.168.0.10 appears to be up ... good. Interesting ports on 192.168.0.10: (The 1656 ports scanned but not shown below are in state: closed) PORT STATE SERVICE VERSION 80/tcp open http Apache httpd 2.0.53 ((Win32)) 135/tcp open msrpc Microsoft Windows msrpc 139/tcp open netbios-ssn 445/tcp open microsoft-ds Microsoft Windows XP microsoft-ds 520/tcp open efs? 3306/tcp open mysql? 3389/tcp open microsoft-rdp Microsoft Terminal Service 1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at http://www.insecure.org/cgi-bin/xxxxxxxx: SF-Port520-TCP:V=3.81%D=4/11%Time=425AA8E8%P=i686-pc-linux-gnu%r(RPCCheck, SF:24,"\x80\0\0\(r\xfe\x1d\x13\0\0\0\0\0\0\0\x02\0\x01\x86\xa0\x01\x01\x97 SF:\|\0\0\0\0\0\0\0\0\0\0\0\0"); MAC Address: 00:30:48:11:AB:5A (Supermicro Computer) Nmap finished: 1 IP address (1 host up) scanned in 102.375 seconds Raw packets sent: 1757 (70.3KB) | Rcvd: 1664 (76.5KB) #The version detection scan can include the --version_trace option, which provides a packet-by-packet display of the probing and fingerprinting process. This option is similar to the --packet_trace option, except the --version_trace option displays only a subset of the frames seen with the ––packet_trace option.
The version detection scan is one of the scans that runs automatically when the Additional, Advanced, and Aggressive scan (-A) is selected. The –A option provides an easy way to launch the version detection process in conjunction with other "discovery" scans.
Version information is valuable information! Version scanning for service information provides easier management of patches and updates. A network security manager can scan every host in an organization to verify that software is at the correct versions. Stations showing older software revisions are identified and further action can be taken.
The version information scan can also assist in locating software that is not complaint with organizational standards. This is also an easy method of verifying the licenses of application services. Nmap can find all of the devices running a specific version of server software to determine if the quantity meets the organization's licensing agreements.
Disadvantages of Using Version Detection
The version scan is very invasive because of the probing that must occur to prompt the service for information. The fingerprint comparison must have information from the application to compare to the fingerprint in the nmap-service-probes file, and this process transmits a number of packets between the source and destination.
The version scan also opens sessions with the remote applications, which will often display in an application's log file. These sessions are almost always necessary, and can't be avoided if the version scan is going to decisively determine the application type and version.
Version detection will only work with TCP or UDP port scans. The ping scan (-sP), the list scan (-sL) and the IP protocol scan (-sO) will not run on the same command line with version detection.
The version scan isn't foolproof. The version detection is only as good as the nmap-service-probe file, but this support file is constantly under revision. If nmap is unable to match an appropriate fingerprint, check to see if an URL and fingerprint is provided for uploading into the nmap database. Your services can assist in making the next version of nmap even better!
When to use Version Detection
The name and version of a service can provide the security team with information that it can use to keep the network applications patched and up-to-date. The server team can use version scans to confirm that a series of upgrades have been completed successfully. If unknown stations are found during a ping scan, the version scan can help determine what applications these 'rogue' stations are providing!
The version detection also shows what other scans might provide when polling network devices for version information. If the security team understands what other people can see, they can revise their security strategies to create a safer computing environment.