Port States, Service and Version Detection, and OS Fingerprinting

Version detection

The step that matters most, because this is what makes the CVE databases usable.

What it does. Determines the product and release: not merely "a web server" but "this server software, version 2.4.x", and often the operating-system distribution and the modules or libraries loaded.

How it works. Partly from banners, which frequently include a version string, and partly from behavioural differences: how the service responds to unusual or malformed requests, which options it supports, the exact wording of its errors. Different releases differ in small ways that a probe database records, so a version can often be determined even where the banner has been suppressed or altered.

Why it is the pivot of the whole assessment, and this is the examinable connection:

Open port, then service, then version, then look the version up against CVE and the National Vulnerability Database, then obtain a list of known vulnerabilities with severities, then prioritise.

Every step before version detection narrows the target; the version is what converts reconnaissance into an actionable list. That is why the enumeration chapters that follow spend their effort on getting versions accurately, and why the hardening chapters treat version disclosure as worth reducing even though it is not a defence in itself.

The characteristic errors, which a careful assessor accounts for:

• Back-ported fixes. Long-term-support distributions frequently apply security patches without changing the version string, so a server reporting an old version may be fully patched. Matching versions to CVEs therefore produces false positives, and a finding based on a banner alone is a hypothesis to confirm, not a conclusion.
• Suppressed or falsified banners. Some administrators remove or alter version strings, producing false negatives or misdirection. Behavioural detection often defeats this, which is why banner suppression is a weak control.
• Load balancers and proxies. The banner may describe the intermediary rather than the server behind it.

Operating-system fingerprinting

What it is. Inferring the target's operating system and version from how its network stack behaves, because the standards leave many details to the implementer and different systems make different choices.

What it reads. The default TTL in IP headers, the initial TCP window size, which TCP options are offered and in what order, how sequence numbers are generated, and, most informatively, how the stack handles unusual or malformed packets, where the standard is silent and implementations diverge most. The combination of these values forms a signature matched against a database.

Two approaches:

Active fingerprinting sends deliberately crafted probes designed to provoke differences. It is accurate and it is noisy, because the packets are abnormal and therefore conspicuous to a sensor, exactly as with the inverse scans.

Passive fingerprinting examines traffic the target sends anyway, without sending anything. It is undetectable and less precise, and it is available to a defender monitoring their own network, which is a legitimate use: passively fingerprinting your own traffic reveals devices that are not in the inventory.

Why it matters to an assessment. Vulnerabilities are platform-specific, so the operating system narrows which CVEs apply and which techniques are relevant. It also reveals unexpected devices: a signature indicating an embedded platform among a range of ordinary servers usually means a printer, a camera or an appliance, and those are frequently unmanaged, unpatched and forgotten, which connects back to the inventory argument of the footprinting block.

Its limits. Network devices, load balancers and virtualisation can alter the characteristics; firewalls that normalise traffic deliberately defeat it; and a single unusual result should not be over-read.

Putting the pipeline together

The complete sequence, which is what a vulnerability assessment actually is:

A scanner performs all of it automatically, which is why a vulnerability scanner's report looks the way it does, and why understanding this pipeline explains both its value and its failure modes: it cannot find flaws in software it failed to identify, and it inherits every error in version detection.

A worked example

A tester scans one host with authorisation and works the pipeline.

States: 22, 443 and 8080 open; 25 closed; 3306 filtered.

Service detection: 22 is SSH as expected; 443 is HTTPS; 8080 is not a web server but a Java application server management interface, which the port number alone would not have revealed.

Version detection: SSH reports a current release; the web server reports a version; the application server reports its product and release, and it is three major versions behind.

OS fingerprinting: the stack signature indicates a Linux distribution, consistent with the service banners.

Vulnerability lookup: the application server's version has several published vulnerabilities, one Critical and remotely exploitable without authentication.

The findings, in order:

1. An outdated application server management interface is exposed on 8080, with a Critical known vulnerability. Urgent: patch, and remove the interface from internet exposure entirely, since a management interface should never face the public.
2. Port 3306 is filtered, so a database may be present behind the firewall. Recorded as unknown, not as absent, and worth confirming from inside.
3. The web server's version is disclosed in its banner. A minor hardening note, with the observation that patching, not suppression, is the real control.

Note that the most serious finding came from the port whose service the number would have mislabelled. That is the argument for doing service detection rather than assuming.

What beginners get wrong

• Treating filtered as closed. Closed is an answer meaning nothing is listening; filtered is the absence of an answer, so the service state is unknown. Reporting one as the other is a material error.
• Assuming the port number identifies the service. It is a convention; detection is evidence. Services on unexpected ports are themselves findings.
• Trusting a banner absolutely. Back-ported patches leave old version strings (false positives) and banners can be suppressed or falsified (false negatives). Confirm before reporting.
• Thinking banner suppression protects the host. Behavioural version detection frequently defeats it; patching is the control.
• Ignoring closed ports entirely. They prove the host is alive and show what the firewall is not filtering.
• Over-reading a fingerprint. Intermediaries and virtualisation distort the signature; corroborate with service evidence.

Quick revision

• States: open (a service is listening), closed (host alive, nothing listening, still informative), filtered (dropped, state unknown), plus open or filtered (UDP and inverse scans), closed or filtered, and unfiltered (ACK scan).
• Service detection identifies the application protocol by probing, because port numbers are convention; a service on an unexpected port is a finding.
• Version detection identifies product and release from banners and behavioural differences. It is the pivot: version, then CVE, then severity, then priority.
• Errors: back-ported fixes cause false positives, suppressed banners cause false negatives, intermediaries mislead.
• OS fingerprinting reads TTL, window size, TCP options and handling of malformed packets. Active is accurate and noisy; passive is silent, less precise, and useful defensively for finding unmanaged devices.
• The pipeline: discovery, port state, service, version, platform, CVE lookup, prioritisation.

Test yourself

1. Distinguish closed from filtered, and say why confusing them matters in a report.

Closed means the host answered and nothing is listening on that port; filtered means no usable reply arrived because an intermediate device dropped the probe, so the service's state is unknown. Reporting a filtered port as closed asserts that no service exists when in fact nothing is known, which can conceal an exposed service behind a partially permissive filter.

1. Why is version detection described as the pivot of a vulnerability assessment?

Because CVE records identify flaws in specific products at specific versions, so only once the product and release are known can the findings be looked up against vulnerability databases to yield known vulnerabilities with severities. Every earlier step narrows the target; the version is what makes the result actionable.

1. Why can a correct version string still produce a false positive, and a suppressed one still be defeated?

A false positive arises because long-term-support distributions back-port security fixes without changing the version string, so an apparently old version may be fully patched. A suppressed banner can still be defeated because version detection also uses behavioural differences, such as responses to unusual requests and supported options, which differ between releases.

1. What characteristics does OS fingerprinting read, and what is the difference between the active and passive forms?

It reads default TTL values, initial TCP window size, which TCP options are offered and in what order, sequence-number generation, and especially how the stack handles malformed or unusual packets where the standard is silent. Active fingerprinting sends crafted probes and is accurate but conspicuous; passive fingerprinting only observes traffic the target already sends, so it is undetectable but less precise, and it is useful to defenders for spotting unmanaged devices.

1. Why is finding a service on a non-standard port significant?

Because port assignments are conventions rather than rules, so a service running where it is not expected may indicate a deliberate attempt to traverse restrictive filtering, a management interface that should not be exposed, or an unauthorised service. It also means an assessment that assumed the service from the port number would have mislabelled it and possibly missed the most serious finding.