Nmap Tutorial: Network Discovery, Port Scanning, and Scan Results

Learn how to install and use Nmap for authorized host discovery, TCP and UDP port scanning, service detection, timing, output, and result interpretation.

What Nmap Does

Nmap is an open-source command-line utility for network discovery, network mapping, port scanning, and service enumeration. It sends selected network probes to authorized targets and analyzes the responses.

Administrators and defenders commonly use Nmap to build an asset inventory, discover network services, validate firewall exposure, map a network, and troubleshoot connectivity. A scan can help answer questions such as “Which hosts respond on this subnet?” and “Is the expected web service reachable on this server?”

Hosts, addresses, ports, protocols, and services

A host is a networked device, such as a server, workstation, router, or virtual machine. An IP address identifies a network interface at a particular point in a network. A port is a numbered transport-layer endpoint. TCP and UDP each have their own port space, so TCP port 53 and UDP port 53 are separate endpoints.

A protocol defines how network systems communicate. A service is an application listening on a port, such as a web server, SSH server, or DNS server. Nmap combines host, address, port, and service observations into a preliminary network map. It does not replace authoritative asset records or system-owner confirmation.

For background, review What Is Nmap, IP addressing, and the TCP/IP suite.

Networking Prerequisites

IP addresses, subnets, and CIDR

An IPv4 address contains 32 bits and is commonly written as four decimal octets, such as 192.0.2.10. A subnet groups addresses that share a network prefix. CIDR notation expresses the prefix length after a slash: 198.51.100.0/24 describes a subnet with 24 network-prefix bits.

Understand whether a target is a single host, a local subnet, a routed internal network, or a remote network before scanning it. Private address ranges are often used in labs and internal networks; see private IP addresses for context.

TCP, UDP, and port ranges

TCP is connection-oriented. A client normally establishes a connection before exchanging application data. UDP is connectionless: applications send datagrams without a TCP-style connection handshake. DNS, monitoring, and some streaming applications use UDP.

Ports are commonly grouped as follows:

Well-known ports: 0–1023, traditionally associated with widely used system services.
Registered ports: 1024–49151, commonly assigned to applications and vendors.
Dynamic or ephemeral ports: 49152–65535, often used temporarily by client applications. Operating-system ranges can vary.

A listening service accepts or processes traffic on a port. A port number alone does not prove which application is running there; service detection uses additional probes to make a best-effort identification.

Command-line basics

On Linux, open a terminal and run commands with a shell. On Windows, use Command Prompt or PowerShell. You should be comfortable changing directories, reading command output, and knowing whether your account has administrative privileges. Nmap itself can run on Linux, Windows, and other supported operating systems.

Installing Nmap

Linux

On Debian-based distributions, install the package with:

sudo apt update && sudo apt install nmap

Other distributions use different package managers and package names. For a focused walkthrough, see installing Nmap on Linux. Kali Linux is a Linux environment commonly used for security training, but Nmap also works on other Linux distributions and on Windows.

Windows

Download and run the official Nmap Windows installer through your organization’s approved software process. Accept the required components, follow the installer prompts, and open a new Command Prompt or PowerShell session if the installer changes the system path. See installing Nmap on Windows.

Verify the installation

Run this command locally:

nmap --version

The output should identify the installed Nmap release and build information. If the command is not found, check that installation completed, that the executable directory is on the system path, and that you opened a new terminal after installation.

Nmap Command Structure

The general pattern is:

nmap [options] target

A target can be a single IP address, hostname, address range, CIDR subnet, or a file containing targets. Examples include:

nmap 192.0.2.10
nmap lab-server.example.internal
nmap 192.0.2.10-20
nmap 198.51.100.0/24
nmap -iL approved-targets.txt

Begin with a narrow, known test host. Expand to a broader authorized subnet only after confirming scope, routing, expected traffic, and operational constraints.

Category	Purpose	Representative options	Use considerations
Host discovery	Find hosts that appear reachable	`-sn`, `-Pn`	Firewalls and routing can hide hosts or make them appear down.
Port selection	Choose which ports to examine	`-p 22,80,443`, `-p 1-1024`	More ports increase coverage, traffic, and duration.
Scan technique	Choose how probes test TCP or UDP	`-sT`, `-sS`, `-sU`	Privileges, target behavior, and network policy matter.
Service detection	Probe for likely product and version	`-sV`	Results are best-effort and can be incomplete.
Timing	Adjust speed, delays, retries, and timeouts	`-T2`, manual timing controls	Fast settings can increase load or reduce reliability.
Output and verbosity	Save or explain results	`-oN`, `-oX`, `-v`	Protect files because they can expose infrastructure details.

Host Discovery and Network Mapping

Host discovery uses probes to determine whether hosts appear active or reachable. A ping-style discovery scan does not normally perform a full port scan. For an authorized practice subnet, use:

nmap -sn 198.51.100.0/24

The result is a preliminary list of hosts that responded to the discovery methods available from your scanning location. It is not a definitive inventory. Firewalls may block probes, routers may prevent a path from working, and a host may be powered off or disconnected.

“Host appears down” means that Nmap received no qualifying response from its discovery probes. It can mean the host is offline, but it can also mean that discovery traffic is filtered, the address is wrong, or routing or VPN connectivity is broken. A host being unreachable from your scan location is different from proving that no host exists at that address.

When authorized and appropriate, a port scan can be attempted without preliminary host discovery using -Pn. This can test hosts that block discovery, but it may take longer and should not be used to bypass an authorization or access-control boundary. Related topics include discovering whether a host is online and disabling the ping sweep.

TCP Port Scanning

TCP scanning identifies ports where applications may accept connections. A basic authorized scan of one lab host is:

nmap 192.0.2.10

To validate selected expected services, specify ports explicitly:

nmap -p 22,80,443 192.0.2.10

To examine a range:

nmap -p 1-1024 192.0.2.10

A TCP connect scan uses the operating system’s normal connection mechanism and is represented by -sT. It is generally available without raw-packet privileges, but it completes connections in the normal networking stack. A SYN scan, represented by -sS, examines connection-start responses without completing a normal application connection. It commonly requires elevated privileges and can still create observable network and system effects.

Use the scan technique allowed by your operating system, account, and testing policy. A scan method is not “invisible”; firewalls, endpoint controls, logs, and monitoring systems may record it.

UDP Port Scanning

UDP differs from TCP because there is no standard connection handshake. An open UDP service may respond only to a correctly formatted application request, while a closed port may return an ICMP error. Firewalls may drop both probes and responses. Consequently, UDP scans can be slower and less certain than TCP scans.

Start with known, required UDP ports rather than a broad sweep:

sudo nmap -sU -p 53,123 192.0.2.10

Port 53 is commonly associated with DNS and port 123 with Network Time Protocol, but the actual application must be verified. A lack of response does not reliably prove that a UDP service is absent. Limit scope, account for timeouts and retries, and coordinate with the system owner.

Characteristic	TCP	UDP
Transport behavior	Connection-oriented	Connectionless datagrams
Typical evidence	Connection responses such as SYN/ACK or reset	Application response, ICMP error, or no response
Scan certainty	Often clearer for common services	Often more ambiguous
Typical duration	Usually faster	Can be slower because of timeouts and retries
Good starting practice	Scan expected ports, then expand as authorized	Select a small set of known UDP ports first

See UDP scanning and UDP fundamentals for related material.

Understanding Port States

State	Meaning	Common cause	Recommended next step
Open	Nmap has evidence that an application accepts connections or packets.	A service is listening and reachable.	Identify the service, confirm ownership, and compare exposure with policy.
Closed	The host is reachable, but no application is listening on that port.	The port is unused or the service is stopped.	Confirm whether this is expected; do not confuse it with filtered.
Filtered	Filtering prevents Nmap from determining whether the port is open.	A firewall drops or blocks probes or responses.	Check firewall policy and, if authorized, test from an approved network location.
Unfiltered	The port is reachable, but the scan method cannot determine open or closed.	Some TCP probe behavior or filtering combinations.	Use an appropriate scan method or validate with the service owner.
Open\|filtered	Nmap cannot distinguish an open port from a filtered one.	Common with UDP and probes that produce no response.	Use an application-aware test or authorized follow-up scan.
Closed\|filtered	Nmap cannot distinguish a closed port from a filtered one.	Some less common scan conditions.	Review scan type and network controls before drawing conclusions.

A port state describes the evidence observed by Nmap. It is not the same as a confirmed service identity. A port labeled “http” may be using a conventional port-number association rather than actually running HTTP.

Service and Version Detection

Use -sV to send additional probes to likely open ports and identify a probable service name, product, and version:

nmap -sV -p 22,80,443 192.0.2.10

This is active probing. It may generate more traffic than a basic port scan and can be noticed by monitoring systems. Version detection is useful for authorized inventory, patch-management follow-up, and validating that a firewall change exposed the intended application.

Detection is best-effort. Proxies, load balancers, custom services, suppressed banners, and unusual configurations can produce incomplete or inaccurate fingerprints. Treat the result as evidence, then validate it against package records, configuration management, authenticated administration tools, or the system owner. See service version detection.

Reading Nmap Output

A typical result contains a scan header, target status, latency, a port table, a summary of scanned ports, and final timing statistics.

Output field	What it indicates	Interpretation caution
Starting Nmap and target	The tool version, scan type, and target supplied.	Confirm that the resolved address is the intended authorized system.
Host is up	The target responded to a discovery or scan probe.	It does not mean every port or service is reachable.
Latency	Approximate response delay from the scanner.	Latency varies with routing, load, and transient network conditions.
PORT	Protocol and port number, such as `22/tcp`.	TCP and UDP ports are separate; a port number alone identifies no application.
STATE	Open, closed, filtered, or another Nmap state.	State describes scan evidence, not absolute application truth.
SERVICE	A conventional or detected service label.	Without `-sV`, this may be based mainly on the port number.
VERSION	Product and version information from active probing.	It can be incomplete, hidden, or incorrect.
Not shown	A summary of ports omitted from the table, often because they share a closed or filtered state.	Omitted ports were still subject to the scan’s scope and method; they were not necessarily ignored.
Nmap done and statistics	Targets completed, elapsed time, and other final statistics.	A completed scan can still contain false negatives or ambiguous results.

Distinguish several failure modes. A DNS resolution error concerns the hostname-to-address step. A host-discovery issue concerns whether the target appeared reachable. “All ports filtered” is a meaningful observation about unclear reachability, not proof that no service exists. A scan failure may result from invalid options, local permissions, or an interrupted command. A successful port result is evidence about a particular protocol, port, source location, and time.

Use the results to create an inventory with fields such as target address, hostname, observation time, protocol, port, state, detected service, version, scan options, and owner. A finding should include the expected state and the observed state.

Port Selection and Scope

Nmap can scan one port, a comma-separated list, a range, or a selected set of common ports:

nmap -p 22 192.0.2.10
nmap -p 22,80,443 192.0.2.10
nmap -p 1-1024 192.0.2.10
nmap --top-ports 100 192.0.2.10

Broader coverage increases the chance of finding an unexpected service, but it also increases duration, traffic, and operational impact. A targeted scan is appropriate for validating a firewall change or checking expected services. It is not proof that all other ports are closed. Start narrowly, then expand only when the authorized objective requires it. See specifying port ranges.

Timing, Delays, and Performance

Scan speed should reflect latency, packet loss, target capacity, IDS or IPS sensitivity, and the operational importance of the systems. Timing templates provide predefined speed and aggressiveness profiles. For example:

nmap -T2 -p 22,80,443 192.0.2.10

A conservative template is a useful starting point for sensitive or production systems. Manual controls can also adjust delays between probes, packet rates, retries, and host timeouts. See timing options and adjusting delays between probes.

Control	Effect on scan	Potential benefit	Potential risk
Timing template	Changes general delays, retries, and timeouts.	Simple way to choose a conservative or faster profile.	Fast profiles may miss responses or create more load.
Probe delay	Spaces requests apart.	Reduces burst traffic and may suit sensitive networks.	Significantly increases scan duration.
Rate limit	Caps the packet or probe rate.	Controls traffic volume and operational impact.	Too low a rate can make scans inefficient.
Retries	Repeats probes that receive no clear response.	Improves reliability on lossy networks.	Increases traffic and time, especially for UDP.
Host timeout	Stops waiting for a target after a specified period.	Prevents one unreachable host from delaying the whole job.	Short values can create false negatives.

Test timing changes on a small authorized scope first. Faster does not always mean better: a fast scan can overload a fragile service or miss results, while a slower scan can improve reliability and reduce disruption.

Saving Results and Record Keeping

Save both human-readable and structured output when the assessment requires review or comparison:

nmap -oN scan-results.txt -oX scan-results.xml 192.0.2.10

Normal output is convenient for people. XML is useful for structured processing and importing into approved reporting workflows. Grepable or other machine-readable formats may be appropriate when supported by the Nmap version and downstream tooling. Name files with the date, scope, and purpose, for example 2026-08-18-lab-web-firewall-check.xml.

Keep the command line, Nmap version, source location, target scope, timestamp, and authorization reference with the result. Protect scan records because they can reveal internal addresses, exposed services, software versions, and network structure. See saving Nmap output.

A Safe, Repeatable Scan Workflow

Confirm authorization. Record the approved targets, protocols, ports, source systems, timing limits, and stop conditions.
Define and verify scope. Check addresses, hostnames, subnet boundaries, routing, VPN access, and maintenance constraints.
Start small. Run installation verification, host discovery, or a targeted port scan against a designated lab host.
Perform required checks. Use TCP or selected UDP scans, then add service detection only where the objective requires it.
Control performance. Use conservative timing for production and monitor for unexpected load or policy alerts.
Interpret and validate. Distinguish port states from service identities and confirm significant findings with system owners.
Document securely. Save the command, output, scope, timestamp, and limitations in an approved location.
Remediate or investigate. Compare observed exposure with policy, close unintended services, correct firewall rules, update software, or investigate unexpected assets.

Troubleshooting Common Problems

The host appears down

Possible causes include an offline host, an incorrect address, blocked discovery probes, or a routing or VPN problem. Verify authorization, the target address, local connectivity, and routing. Where authorized, compare normal discovery with a scan using -Pn, remembering that this can increase scan time.

All ports are filtered

A firewall or access-control device may be dropping probes, or the scan may be using the wrong network path. Confirm the expected firewall policy and test from an approved network location. Do not interpret filtered as service absent.

A UDP scan is slow

UDP applications may not respond to probes, so Nmap may wait for timeouts and retries. Packet loss and rate limiting can add delay. Reduce the port set to known required UDP ports and review conservative timing and retry settings.

A hostname cannot be resolved

Check for a misspelled hostname, DNS configuration problems, or a name resolvable only from another network. Use approved local DNS troubleshooting tools or scan the confirmed IP address after verifying that it is in scope.

Service detection is unexpected or incomplete

A proxy, load balancer, custom banner, suppressed version response, or nonstandard application may be responsible. Treat Nmap’s identification as evidence, then validate it through authorized inventory data or owner confirmation.

Permission or raw-socket errors occur

Some scan types require elevated privileges. Use an approved account with the necessary permissions, or choose a scan method supported by the current privilege level. Local endpoint security or operating-system policy may also restrict packet operations.

Exam-Relevant Notes

An open port indicates evidence of a reachable listening application; it does not by itself identify the product or prove a vulnerability.
A closed port is reachable but has no listener. A filtered port cannot be classified because filtering prevents a clear response.
-sT uses the operating system’s TCP connection mechanism; -sS uses SYN-based probing and commonly requires elevated privileges; -sU performs UDP scanning.
-sV performs active service and version detection. A service label shown without it may be a port-number-based guess.
-sn performs host discovery without a normal port scan. A host-discovery failure is not proof that the host is absent.
UDP no-response results are often reported as open|filtered; lack of a response does not reliably prove that no service exists.
A limited port scan cannot prove that unscanned ports are closed.
Fast timing can increase traffic, load, and false negatives. Conservative timing generally improves operational safety but takes longer.
A scan result is time-, source-location-, protocol-, and policy-dependent. Record those conditions with the result.

For further study, explore interpreting scan results, port states, and starting Nmap.