VMware ESXi and vSphere Cluster Management

Introduction to Nmap: Network Discovery and Security Scanning

Learn Nmap on Linux to discover hosts, scan TCP and UDP ports, identify services, interpret results, use NSE safely, and document authorized security assessments.

Nmap is a command-line utility for network discovery, port scanning, service identification, and authorized security auditing. This guide uses Kali Linux in examples, but Nmap is also available for Debian, Ubuntu, Fedora, Windows, macOS, and other operating systems.

What Nmap Does

Nmap sends network probes and interprets the responses. Its findings describe what was observable from a particular scanner, network path, and point in time.

Host discovery: determines whether a target appears reachable or active.
Port scanning: tests numbered TCP or UDP endpoints.
Service enumeration: identifies applications listening behind open ports.
OS fingerprinting: makes a probabilistic operating-system or device-type guess from network behavior.
Vulnerability assessment: evaluates software or configuration for security weaknesses. Nmap can support this work, especially through selected NSE scripts, but a port scan alone is not a vulnerability assessment.

Legitimate uses include asset inventory, exposure validation, troubleshooting, lab learning, and authorized security assessments. An open port is not automatically a vulnerability: its risk depends on the service, owner, purpose, authentication, patch level, firewall policy, and business need.

Installation and Initial Setup

First check whether Nmap is already installed:

nmap --version

On Debian-, Ubuntu-, or Kali-based systems, install it with:

sudo apt update && sudo apt install nmap

Confirm the installation and inspect concise built-in help:

nmap --version
nmap -h

Some scan types use raw packets and normally require elevated privileges. A TCP SYN scan, ARP discovery, UDP scanning, and OS detection commonly benefit from or require administrative access. TCP connect scanning can work without raw-packet privileges.

Use the least privilege that meets the objective. Running as root unnecessarily increases the impact of command mistakes and can expose sensitive local capabilities. Use sudo for a specific command when policy permits, and do not bypass local administrative controls.

Nmap Command Structure

The general structure is:

nmap [scan options] [target-selection options] [port options] [timing options] [detection options] [output options] targets

Options can change both scan behavior and the quality or detail of the evidence. Common groups include:

Scan type: -sS TCP SYN, -sT TCP connect, -sU UDP, and -sn discovery only.
Target selection: individual addresses, hostnames, CIDR ranges, address ranges, -iL input files, and --exclude.
Port selection: -p for selected ports, ranges, or all TCP ports.
Timing: -T0 through -T5, plus controls for retries, rates, and timeouts.
Detection: -sV service/version detection, -O OS detection, traceroute, and NSE scripts.
Output: normal terminal output, saved text, XML, grepable-compatible output, or a combined set.

Targets and Scope Control

A target may be a single approved host, hostname, several addresses, an address range, a CIDR network, or a file containing approved targets.

# One host
nmap 192.0.2.10

# Several hosts
nmap 192.0.2.10 192.0.2.20 server.example.test

# A controlled address range
nmap 192.0.2.10-20

# A CIDR network
nmap 192.0.2.0/24

# Targets from a file
nmap -iL approved-targets.txt

# Exclude a system from an approved range
nmap -sn 192.0.2.0/24 --exclude 192.0.2.1

In CIDR notation, the suffix gives the network prefix length. For example, 192.0.2.0/24 represents a network with 24 network bits and 8 host bits. Validate the address, DNS resolution, route, exclusions, and written authorization before launching a scan. The documentation range 192.0.2.0/24 is used here as an example; replace it only with an authorized scope.

Host Discovery

Host discovery asks whether a target appears up without performing a normal port scan. The command -sn enables discovery-only mode:

nmap -sn 192.0.2.0/24

Nmap can use several probe types:

Method	Network context	Response evidence	Reasons it may fail or be filtered
ICMP echo or timestamp	Routed networks	ICMP response	Host firewall, router policy, cloud controls
TCP SYN probe	Routed networks	SYN/ACK or RST	Filtering, rate limits, closed paths
TCP ACK probe	Routed networks	RST or filtering behavior	Stateful firewalls and packet filters
ARP discovery	Local Ethernet	ARP response	Nonlocal target, VLAN boundary, local-link controls

A known host may appear down because ICMP and discovery probes are filtered, the address is wrong, routing is broken, or the host is offline. For an authorized host that is known to filter discovery, skip host discovery with -Pn:

nmap -Pn -p 22,80,443 192.0.2.10

Use -Pn carefully: it treats targets as available and may spend time scanning systems that are actually offline.

TCP Port Scanning Fundamentals

A port is a numbered transport-layer endpoint. A service is an application or daemon listening on that endpoint. TCP normally uses a three-step connection process: the client sends SYN, the server replies SYN/ACK, and the client sends ACK. Nmap can infer port state from this exchange without necessarily completing an application session.

Option	Protocol or mechanism	Typical privilege requirement	Primary purpose	Key limitations
`-sS`	TCP SYN behavior	Usually elevated	Efficient TCP scanning	Needs raw-packet access; filtering can obscure results
`-sT`	Full TCP connect()	Usually unprivileged	Fallback TCP scan	Completes connections and may create more application-visible events
`-sU`	UDP probes	Often elevated	Find UDP services	Slow and frequently ambiguous
`-sn`	Discovery probes	Varies	Find apparently active hosts	Does not enumerate ports

Focused TCP examples:

# Default commonly scanned TCP ports
sudo nmap -sS 192.0.2.10

# Selected ports
sudo nmap -sS -p 22,80,443 192.0.2.10

# A port range
sudo nmap -sS -p 1-1024 192.0.2.10

# All TCP ports
sudo nmap -sS -p- 192.0.2.10

# Connect scan when raw packets are unavailable
nmap -sT -p 22,80,443 192.0.2.10

Interpret states as observations:

State	Meaning	Common cause	Recommended follow-up
Open	A service appears to accept connections	Listening application responded	Run focused service detection and verify ownership
Closed	The host is reachable, but no service is listening	Definitive TCP reset	Check whether the result matches the expected configuration
Filtered	Filtering prevents a decision	Firewall or no usable response	Review routing, policy, logs, and use conservative retries
Unfiltered	Reachable, but open or closed is not determined by that scan	Often an ACK-scan result	Use an appropriate SYN or connect scan
Open\|filtered	Evidence cannot distinguish open from filtered	Common with UDP or silent TCP behavior	Use service detection or complementary evidence
Closed\|filtered	Evidence cannot distinguish closed from filtered	Limited response behavior	Repeat with validated scope and suitable probes

A result is not a permanent fact. Services change, firewalls apply different policies, routes fail, and ephemeral applications come and go.

UDP Scanning

UDP has no TCP-style handshake. A UDP service may respond to a valid application probe, while a closed port may return ICMP port unreachable. Firewalls may drop both requests and replies. Consequently, UDP results often take longer and are less conclusive.

sudo nmap -sU -p 53,123,161 192.0.2.10

Open: a UDP response indicates a service or application behavior.
Closed: an ICMP port-unreachable response indicates no UDP listener.
Filtered: filtering or missing responses prevents a conclusion.
Open|filtered: no response could mean either an open service that stayed quiet or filtering.

Start with prioritized ports rather than all 65,535 UDP ports. Combine Nmap evidence with service detection, system logs, configuration records, or owner confirmation.

Service and Version Detection

Port numbers are conventions, not proof. An HTTP service can run on a nonstandard port, and a familiar port can host an unexpected application. The -sV option actively probes open ports and compares responses with service signatures.

nmap -sV -p 22,80,443 192.0.2.10

Output may include a service name, product string, version, protocol details, platform hints, and a confidence level. Treat these as evidence rather than certainty: banners can be changed, proxies and load balancers can answer on behalf of servers, and detection may be incomplete. Version-detection intensity affects the number of probes, duration, and intrusiveness. Begin with ordinary focused detection; increase intensity only when justified and authorized.

OS Detection and Traceroute

OS fingerprinting compares characteristics of network-stack responses with known fingerprints. It is probabilistic, not an authenticated inventory source.

sudo nmap -O 192.0.2.10
sudo nmap --traceroute 192.0.2.10

Useful OS results may include guesses, accuracy percentages, device types, and network distance. Filtering, NAT, proxies, middleboxes, unusual stacks, and insufficient open and closed port evidence can reduce confidence. Do not make a remediation decision from an uncertain OS guess alone.

Traceroute estimates the path between scanner and target. It can help investigate routing, topology, and connectivity, but firewalls and asymmetric paths may make the path incomplete or misleading.

Nmap Scripting Engine Basics

The Nmap Scripting Engine, or NSE, is a framework for scripts that perform discovery, enumeration, and authorized security checks. Categories include broad groups such as default, safe, discovery, version, and more intrusive categories. “Safe” does not mean risk-free, and scripts in intrusive or vulnerability-related categories require careful review.

Run a named, reviewed discovery script only against an approved target:

nmap --script dns-service-discovery 192.0.2.10

Some scripts accept arguments. Read the local documentation first:

nmap --script-help dns-service-discovery
ls /usr/share/nmap/scripts
nmap --script-updatedb

Script output may add names, protocols, metadata, or security observations. Review each script's purpose, network behavior, required arguments, and likely impact before execution. Do not treat exploitation workflows as routine introductory scanning.

Performance, Timing, and Reliability

Faster is not automatically better. Speed, network impact, stealth assumptions, and accuracy trade off against one another. Timing templates range from very slow and conservative to very aggressive:

Timing approach	Speed	Network impact risk	Accuracy considerations	Appropriate context
Very conservative, such as `-T1` or `-T2`	Slow	Lower	Allows more time for delayed responses	Fragile devices, production networks, uncertain links
Moderate, such as `-T3`	Balanced	Moderate	Good general starting point	Controlled authorized assessments
Aggressive, such as `-T4`	Fast	Higher	Can increase packet loss and false negatives	Stable, well-understood lab or network
Very aggressive, such as `-T5`	Very fast	Highest	More likely to miss or disturb targets	Rarely appropriate for introductory work

nmap -T2 -sV 192.0.2.10

Retries, host timeouts, rate controls, packet loss, and restrictive filtering all affect reliability. Tune gradually: narrow the host and port scope, separate discovery from enumeration, use conservative timing, and only then consider carefully justified rate changes. Aggressive timing can trigger monitoring and affect network devices.

Output, Reporting, and Result Management

Standard output normally shows host status, a port table, service columns, and a scan summary. Save evidence for repeatability and comparison:

# Normal text, XML, and grepable-compatible output
nmap -sV -oA inventory-2026-08-18 192.0.2.10

Output type	Nmap option	Best use	Handling considerations
Normal text	`-oN file.txt`	Human review and readable records	Preserve the command and scope separately or in the report
XML	`-oX file.xml`	Parsing, reporting, and comparison workflows	Protect host, service, and infrastructure details
Grepable-compatible	`-oG file.gnmap`	Simple text processing and legacy workflows	Less expressive than XML for complex reporting
Combined	`-oA basename`	Creates normal, XML, and grepable-compatible files	Use meaningful names and secure all generated files

Use names containing an asset or engagement identifier, date, and phase. Record the exact command, scope, exclusions, scanner location, timing, assumptions, and relevant authorization. Reports are sensitive operational data because they reveal addresses, services, versions, and network structure.

Practical Authorized Workflow

Phase	Objective	Example activity	Evidence to record
Approval and scope	Define permission and boundaries	Obtain rules of engagement and maintenance window	Owner, dates, addresses, exclusions, limits
Validation	Prevent accidental scanning	Check DNS, routes, target file, and exclusions	Validated scope and assumptions
Discovery	Find apparently active hosts	`nmap -sn approved-range`	Probe type, responders, nonresponses
Focused enumeration	Identify relevant exposure	Selected TCP ports and prioritized UDP ports	Commands, timing, port states
Identification	Learn what listens behind ports	`-sV` on discovered ports	Product strings, versions, confidence
Justified enrichment	Add context carefully	Limited `-O`, traceroute, or reviewed NSE	Reason, script documentation, output
Reporting	Make findings reproducible	`-oA` with a meaningful name	Normal and XML files, timestamp, scope
Validation and remediation	Confirm significance and change	Owner review, disable or restrict service, rescan	Confirmation, change record, comparison

A sensible sequence is written authorization, scope validation, low-impact discovery, focused TCP scanning, prioritized UDP scanning where relevant, service/version detection, limited OS or NSE enrichment, reporting, owner confirmation, remediation, and rescan.

Interpreting Findings

Review an open port in context. Ask who owns the service, why it is exposed, whether authentication and encryption are strong, whether the software is supported and patched, and whether network controls restrict access.

Unexpected services should be investigated.
Obsolete protocols and insecure management interfaces deserve priority review.
Unnecessary exposure can often be reduced with service disablement or firewall and security-group restrictions.
Supported software should be patched, and authentication should be strengthened where appropriate.
Rescan after changes to confirm the externally observable result.

A false positive is a reported condition that does not reflect the real state. A false negative is a real condition the scan fails to detect. Filtering, packet loss, proxies, changed configurations, and uncertain detection can cause either type of error. Validate important findings with owners, logs, configuration records, authenticated inspection, or another approved source.

Troubleshooting Common Results

A known host is reported as down

Verify authorization, address, DNS, route, VPN, and cloud security controls. Try a discovery method appropriate to the local network. For a known authorized host, compare with -Pn and operational evidence such as console access or owner confirmation. No response does not prove that a host is absent.

Most ports are filtered

Check scope, routing, asymmetric paths, firewall rules, security groups, intrusion-prevention behavior, and packet loss. Use a small port set and conservative timing, then coordinate with the network or system owner and review logs.

The scan is slow

UDP scans, broad port ranges, version probing, restrictive filtering, retransmissions, and slow links all increase duration. Reduce scope, separate scan phases, and tune gradually rather than immediately selecting aggressive timing.

Service detection is unexpected

A nonstandard service may be listening on the port, or a proxy, load balancer, banner customization, or configuration change may affect the result. Review complete evidence and validate with the owner or approved authenticated inspection. An inferred version is not a confirmed vulnerability.

OS detection is inconclusive

Filtering, NAT, middleboxes, unusual network stacks, and insufficient open and closed port evidence can prevent a confident match. Treat the result as inconclusive and use service evidence or asset-management data instead.

Nmap reports insufficient privileges

The requested scan may require raw-packet access. Follow local policy and use the appropriate administrative privilege, or use -sT when a full TCP connect scan meets the objective.

Legal, Ethical, and Operational Safety

Define rules of engagement before scanning organizational systems. Notify stakeholders, choose a maintenance window, rate-limit where appropriate, identify fragile devices, and establish escalation or rollback procedures. Expect security-monitoring alerts and preserve a way to stop or narrow the activity.

Never use Nmap to bypass access controls, conceal unauthorized activity, or explore systems outside the approved scope. Practice with intentionally vulnerable labs, personal systems, or designated training targets.

Key Terms

Target: an approved host, range, hostname, or target-list entry.
Port: a numbered TCP or UDP transport endpoint.
TCP SYN scan: a scan that interprets SYN/ACK, RST, and absent responses without completing a normal application connection.
TCP connect scan: a scan using the operating system's full TCP connection mechanism.
UDP scan: a scan dependent on UDP application responses, timeouts, and ICMP behavior.
Timing template: a preset controlling delays, parallelism, retries, and timeouts.
XML output: structured output intended for parsing, reporting, and comparison.

Exam-Relevant Notes

-sn discovers hosts without a normal port scan; -Pn skips discovery and treats targets as up.
-sS is the common privileged TCP SYN scan; -sT uses full TCP connections.
UDP is slower and commonly produces open|filtered.
-sV identifies likely service applications and versions; port numbers alone are not reliable identification.
-O is probabilistic OS fingerprinting, not authoritative inventory.
-oA saves normal, XML, and grepable-compatible output together.
Filtered means Nmap cannot determine accessibility because responses are blocked or unavailable.
Always interpret results within scope, network position, timing, and the scan date.

Continue with the Nmap Introduction Ebook as a reference while practicing only in an authorized environment.