Determine Service Versions with Nmap

Learn how Nmap service version detection works, how to use -sV, interpret scan output, and validate identified services responsibly.

What service version detection does

An open port tells you that a network endpoint is accepting traffic, but it does not reliably identify the exact software using that port. For example, an open TCP port 80 may host different web servers, a proxy, an application framework, or a custom service.

Service version detection is Nmap probing used to identify the protocol, product, and version associated with reachable network services. Nmap sends service probes—protocol-specific requests—and compares the responses with its service-probe database. The observed response characteristics form a service fingerprint.

Accurate identification supports authorized asset inventory, patch verification, vulnerability assessment, configuration review, and vulnerability research. It helps an administrator compare exposed software with internal records and approved vendor or vulnerability-management sources.

What Nmap can identify

Depending on the service response, Nmap may report the following information:

Information type — Example — Reliability and validation note

Protocol: FTP, DNS, HTTP, SSH, or LDAP. Usually strong when the response matches a protocol-specific probe.

Application or product: A web server, DNS server, mail server, or remote-access daemon. Validate unusual or generic matches.

Version: A product release, version range, or implementation detail. A version string is evidence, not automatically proof of patch status.

Hostname or domain detail: A banner, certificate name, virtual host, or service-advertised domain. Confirm that the value belongs to the intended host.

Device-type clue: A possible router, printer, server, or network appliance. Treat this as an inference unless confirmed by authorized records.

Operating-system family clue: Responses from directory, file-sharing, RPC, or authentication services may suggest an operating-system family. Service detection does not prove a complete operating-system version.

Some information is directly identified from a response, such as a banner that names a product. Other information is inferred from response patterns. Keep those categories separate in assessment notes.

Using the `-sV` option

The -sV option enables Nmap service and version detection. It can be used with an IP address, an authorized hostname, or an approved target range.

nmap -sV 192.0.2.25

This command performs a default port scan and then probes discovered open ports for service information. The reserved documentation address 192.0.2.25 is an example; substitute only an in-scope target.

nmap -sV example.internal

When the scope is known, combine -sV with an explicit port list or range:

nmap -sV -p 80,443,8080 192.0.2.25
nmap -sV -p 1-1024 192.0.2.25

The first command focuses on selected web-related ports. The second limits version detection to ports 1 through 1024. Explicit port selection can reduce scan time and keep testing within the approved scope.

Saving results for documentation

nmap -sV -oN service-version-scan.txt 192.0.2.25

Normal-format output is useful for an assessment record. Protect scan files because banners and hostnames may contain sensitive infrastructure information.

Reading service-version output

A typical result may look similar to this:

PORT     STATE  SERVICE  VERSION
21/tcp   open   ftp      Example FTP server 2.4
53/tcp   open   domain   Example DNS service
80/tcp   open   http     Example Web Server 1.8.2
389/tcp  open   ldap     Example Directory Service

Field — Meaning — Example interpretation

PORT: The port number and transport protocol, such as 21/tcp or 53/udp. TCP and UDP are different transports, so the same number can represent different services.

STATE: Nmap's assessment of reachability. open means an application is accepting connections; closed means the host responded but no application is listening; filtered means a filter prevents Nmap from determining the state; open|filtered means Nmap cannot distinguish an open service from filtering.

SERVICE: Nmap's service designation, such as ftp, domain, or http. Without strong probe evidence, this field can be a port-based or conventional-port guess.

VERSION: Probe-based product, vendor, version, and supplemental details when Nmap can identify them. This is generally more informative than the service name alone.

Version detection is most useful for reachable open services. A filtered port may hide a service, while a closed port normally has no application available for version probing.

Protocol notation

The suffix after the slash identifies the transport protocol. For example, 80/tcp is TCP port 80, while 53/udp is UDP port 53. Do not assume that a TCP result describes the corresponding UDP service.

Uncertain and incomplete matches

Nmap may show a generic label, a question mark, or no product version. An uncertain result means the evidence was ambiguous or did not match a known probe signature. It is a hypothesis, not a confirmed identification.

A report can also state that service detection was performed and may identify incomplete or uncertain matches. Preserve that context when exporting or sharing results.

Observed result — Likely meaning — Recommended next step

Product and version detected: Nmap found a recognizable response. Compare it with asset records and vendor advisories, then validate patch status.

Service detected but no version: The service responded, but it did not expose a usable release identifier. Record the service without claiming a version and validate through authorized administrative sources.

Question mark or uncertain service label: The response was insufficient, ambiguous, nonstandard, or modified by a middlebox. Treat the result as a hypothesis and document the uncertainty.

Filtered port: A firewall, access rule, routing issue, or segmentation prevents a reliable determination. Confirm the approved testing path; do not report the service as absent.

Generic or tcpwrapped-style result: A wrapper or access control accepted and then restricted the probe, or the response was too generic. Use authorized configuration evidence for confirmation.

Interpreting common findings

An FTP entry may identify both the FTP protocol and the server implementation. A DNS entry may identify a DNS product without providing a complete release number. An HTTP entry may reveal a web-server product and version. RPC, directory, file-sharing, and authentication-related services can provide useful environmental clues, but they should not be treated as definitive operating-system identification.

Prioritize clearly versioned services for patch and advisory review. Keep generic and uncertain detections marked as uncertain. Correlate findings with authorized asset-management data rather than treating a scan as the sole source of truth.

Validate before declaring a vulnerability

A detected version can be compared with vendor advisories, internal asset records, and approved vulnerability-management sources. However, do not conclude that a host is vulnerable from a version string alone.

A banner may be incomplete, altered, or intentionally misleading.
A proxy, load balancer, or intermediary may answer on behalf of another system.
A backported patch may fix a vulnerability in an older packaged version without changing the apparent upstream version number.
A service version identifies exposed software, not necessarily the complete target operating-system version.

If a result appears vulnerable but the owner reports that the system is patched, check vendor and distribution-specific advisories, then validate with authorized patch-management or configuration evidence. Report the detected version separately from the confirmed vulnerability determination. This prevents a false positive—an incorrect identification or vulnerability conclusion based on misleading or incomplete evidence.

Scope, duration, and scan efficiency

Service detection takes longer than a basic port scan because Nmap sends additional probes. Duration and detection quality are affected by network latency, packet loss, filtering, service behavior, and the number of open ports.

Limit testing to approved hosts and relevant ports when the scope is known.
Use an explicit port list or range, such as -p 80,443,8080 or -p 1-1024.
Allow sufficient time for slow or filtered services to respond.
Run scans during an approved assessment or maintenance window when application impact and monitoring concerns matter.
Do not interpret a partial scan as a complete inventory.

Scanning a specified range does not guarantee that every service will identify itself. It only controls which ports Nmap considers for scanning and probing.

Troubleshooting service detection

Nmap identifies a service but not its product version

The service may not expose a version, a proxy or security control may suppress identifying data, or the response may not match a known probe. Record the service without claiming a release number. Validate through authorized configuration records or vendor-approved administrative interfaces.

The output contains a question mark

Nmap may have received insufficient or ambiguous data, encountered a custom implementation on a nonstandard port, or observed a response modified by a middlebox. Review the evidence, validate with approved sources, and document the uncertainty.

Expected ports are filtered

Firewall rules, network segmentation, routing, or the assessment system's network location may block probes. Confirm the authorized testing path and coordinate with network administrators when appropriate. A filtered result does not prove that the service is absent.

The scan takes longer than expected

Many ports, numerous reachable services, latency, packet loss, filtering, and slow application responses can all increase duration. Narrow the target or port scope where authorization permits, and preserve enough time for reliable results.

Documenting results

For each assessment, record the target, date and time, exact command, reachable ports, identified protocols and products, version evidence, confidence, and validation status. Note whether each value was directly reported by the service or inferred from response behavior.

A useful record distinguishes detected by Nmap from confirmed by asset or patch evidence. This makes later remediation, inventory updates, and vulnerability review more reliable.

Practical workflow

Confirm ownership or written authorization and define the approved target and port scope.
Run a basic port scan or use a known approved port list.
Run nmap -sV against the approved target.
Review PORT, STATE, SERVICE, and VERSION for reachable services.
Mark generic, missing, or question-mark results as uncertain.
Compare identified products with authorized asset records and current vendor or vulnerability-management information.
Validate apparent vulnerabilities using patch and configuration evidence before reporting them as confirmed.
Save and protect the output as assessment documentation.