VMware ESXi and vSphere Cluster Management

Determine Service Versions with Nmap

Learn how Nmap service version detection works, how to use -sV, interpret results, assess confidence, and validate findings safely.

Nmap can do more than show which network ports respond. Its service version detection feature probes reachable ports and analyzes the responses to estimate which protocol, application, product, and software version are operating there.

What Service Version Detection Does

A port is a numbered network endpoint used by a TCP or UDP service. A service is the network-accessible application or protocol listening on that port. Basic port scanning answers a reachability question: “Is something responding here?”

Service version detection asks a more specific question: “What is responding here?” Nmap sends service-specific probes and compares the replies with known response patterns, called fingerprints. This can identify a protocol, product, implementation, and sometimes a precise version or version range.

Accurate identification helps with:

  • Asset and service inventory.
  • Security validation and exposure review.
  • Comparison with vendor support information and vulnerability databases.
  • Patch-management and remediation prioritization.
  • Identification of unexpected or unauthorized services.

A detected version is evidence for further investigation, not automatic proof that a vulnerability exists. Configuration, patch state, authentication requirements, backported fixes, and actual network exposure must also be checked.

Using the -sV Option

The -sV option enables Nmap service and version detection. The basic command structure is:

nmap -sV TARGET

For example, this scans one approved host:

nmap -sV 192.168.5.102

Replace the example address with an in-scope IP address or hostname. Nmap first considers the ports selected by the scan and then sends additional probes to ports that respond. The result depends on reachable ports, service behavior, filtering, network conditions, and Nmap's fingerprint coverage.

Limit Detection to Specific Ports

If the permitted port list is already known, narrowing the scan can reduce unnecessary traffic and scan time:

nmap -sV -p 21,53,80,443 192.168.5.102

This performs version detection on the listed ports only. A defined range is also possible:

nmap -sV -p 1-1024 192.168.5.102

Use a port range only when the authorization scope permits it. Service detection generally takes longer than a basic port scan because Nmap performs additional probes and may wait for replies or retries.

Reading Service Version Output

A typical result includes a table similar to this:

PORT    STATE  SERVICE  VERSION
22/tcp  open   ssh      OpenSSH 9.2p1 Debian 2+deb12u3
80/tcp  open   http     nginx 1.24.0
23/tcp  open   telnet   Linux telnetd

The columns provide different kinds of evidence.

PORT — Shows the port number and transport protocol, such as 22/tcp. A port is a numbered endpoint; TCP and UDP are separate transport protocols.

STATE — Describes what Nmap could determine about the port. Open means a reachable service is accepting connections or responding to probes. Closed means the host is reachable but no service is listening on that port. Filtered means filtering prevents Nmap from determining the state reliably.

SERVICE — Nmap's classification of the protocol or common service associated with the response, such as ssh, http, dns, or ldap. It is a classification, not necessarily the vendor's exact product name.

VERSION — Details inferred from responses, such as the product, implementation, version, protocol details, or operating-system-related text. The field may be incomplete or absent.

A question mark indicates uncertainty. For example, an entry such as http? or a product followed by ? is a tentative identification and should not be treated as confirmed.

What Nmap May Identify

Protocol — Examples include FTP, SSH, Telnet, HTTP, DNS, LDAP, and RPC. Knowing the protocol helps determine how the service should be tested and managed.

Application or product — Nmap may identify a web server, DNS server, mail server, file-transfer server, or a specific implementation.

Version — A reliable fingerprint may provide a version number or a version range. Some services reveal only partial information.

Hostname or domain metadata — Service responses may expose hostnames, domain-related information, server time, or other metadata.

Device or operating-system clues — Response behavior and service text may suggest a device type or operating-system family. These are clues, not definitive identification.

From Version Results to Vulnerability Assessment

A vulnerability assessment is an authorized process for identifying, validating, and prioritizing security weaknesses. Use Nmap results as one source of evidence in that process.

  1. Record the target and scan date.
  2. Record the port and transport protocol, such as 443/tcp.
  3. Record the detected service classification.
  4. Record the product, version, and any relevant metadata separately.
  5. Assign a confidence level, especially when the output is generic, incomplete, or marked with a question mark.
  6. Compare the result with vendor advisories, supported-version information, and appropriate vulnerability databases.
  7. Validate whether the installed software is actually affected. Check configuration, authentication requirements, patches, backported fixes, and network exposure.
  8. Report the evidence, uncertainty, impact, and recommended remediation.

For example, an HTTP result containing a web-server product and version string is a useful starting point for patch-status review. The banner alone does not confirm a specific vulnerability. A distributor may have backported a fix without changing the upstream version string, or a vulnerable feature may be disabled or inaccessible.

Confidence and Validation

Specific product and version returned — Nmap found a relatively strong fingerprint match. Compare it with approved inventory and vendor information before making a security conclusion.

Generic service identified — The protocol is probably recognizable, but the exact product or version is not known. Use inventory or service-owner confirmation to improve identification.

Question mark or uncertain result — The response resembles a known service but may be customized, unusual, or incomplete. Validate through an authorized secondary method.

Filtered port — Firewalls or other controls prevented a reliable determination. Report the limitation rather than assuming the port is open or closed.

No version returned — The service may hide its banner, use an unrecognized response, or be affected by TLS, a proxy, or access controls. Record the service as version unknown.

Limitations and Interpretation Cautions

  • A banner is information returned by a service that may reveal its identity, implementation, or version. Banners can be absent, altered, generic, or intentionally misleading.
  • Firewalls, proxies, TLS encryption, access controls, packet loss, latency, and unusual application behavior can reduce detection accuracy.
  • A service may run on a nonstandard port. Nmap can still attempt identification when that port is included in the scan.
  • A port number alone does not prove which software is running. For example, an HTTP service does not have to use port 80.
  • Inferred operating-system or device information should be treated as a clue, not definitive identification.
  • A false positive is an identification or security conclusion that appears valid but is incorrect. Confirm important results before using them to drive remediation or escalation.

Scan Duration and Result Quality

Version detection can take longer than a basic port scan because Nmap sends additional protocol probes and waits for responses. Network latency, retries, filtered ports, and services that do not respond promptly can increase the duration.

Narrowing the scan to approved ports, known open ports, or an in-scope range often improves efficiency. Detection intensity can also affect the balance between speed and thoroughness. Use the least intrusive setting that meets the assessment objective rather than treating aggressive scanning as the default.

Troubleshooting Common Results

Port identified but no product version

The service may not disclose a banner, may not match a known fingerprint, or may be behind a proxy, TLS layer, or access control. Record the service as identified but the version as unknown. Use approved inventory sources or service-owner confirmation, and do not infer a precise version from the port number.

A question mark appears in the result

Nmap has made a tentative fingerprint match. Treat the identification as low confidence and validate it through an authorized secondary method before using it as the basis of a security finding.

The port is filtered

Firewall rules, packet filtering, or other network controls may block probes or replies. Report that the state cannot be reliably determined from this scan. If permitted, confirm whether testing from another approved network location is appropriate, or ask the firewall owner to assist.

The scan takes much longer than expected

Additional probes, network latency, retries, and filtered services commonly explain the difference. Limit scanning to authorized targets and relevant ports, allow sufficient time for the scan, and do not sacrifice validation quality solely to finish faster.

Practical Workflow

  1. Confirm written authorization and the exact target, ports, timing, and constraints.
  2. Run a basic port scan if the reachable-port set is not already known.
  3. Run nmap -sV against the approved target or approved port list.
  4. Read the port, state, service, and version fields independently.
  5. Mark uncertain, filtered, and unknown-version results clearly.
  6. Compare plausible versions with supported-version information and vendor advisories.
  7. Validate patch status, configuration, authentication, and exposure before concluding that a vulnerability is exploitable.
  8. Document evidence, confidence, limitations, and remediation priorities.

Exam-Relevant Notes

  • -sV enables Nmap service and version detection.
  • Port discovery identifies reachable endpoints; version detection probes those endpoints to identify the software behind them.
  • open indicates a responding service, closed indicates a reachable host with no listener, and filtered means filtering prevents reliable determination.
  • The SERVICE field is Nmap's service classification; the VERSION field contains inferred product and version details.
  • Question marks and blank fields indicate uncertainty or missing evidence.
  • Nmap output supports investigation but does not, by itself, prove exploitability.
  • Always interpret results within authorization, scope, network controls, and the limitations of banners and fingerprints.

Related lesson: Determine Service Version.