Introduction to Nmap: Network Discovery and Port Scanning

Learn to install and use Nmap on Windows and Linux for authorized host discovery, TCP and UDP scanning, result interpretation, timing, version detection, and reporting.

Nmap is an open-source utility for network discovery, host identification, and port scanning. It helps administrators and security teams build an asset inventory, map an authorized network, verify expected services, and perform approved security assessments.

Networking concepts for Nmap

A host is a network-connected device or system that can be addressed on a network. An IP address identifies that host at the network layer. A DNS name, such as server.example.test, is a human-readable name that can resolve to an IP address.

A port is a numbered communication endpoint. TCP and UDP each have their own port numbers from 0 through 65535. A service is an application or process that listens for TCP connections or UDP datagrams. When a service is accepting traffic on a port, Nmap commonly reports that port as open.

Term	Meaning
TCP	A connection-oriented transport protocol commonly used by web, remote administration, and database services.
UDP	A connectionless transport protocol used by DNS and other datagram-based services.
Host discovery	Techniques used to determine whether targets appear active, before or apart from port scanning.
Port state	Nmap's classification of how a port responded, such as open, closed, or filtered.

Common conventions include TCP 80 for HTTP, TCP 443 for HTTPS, TCP 22 for SSH, and UDP 53 for DNS. These are conventions, not guarantees: an administrator can run a service on a nonstandard port. The port number alone does not confirm the application identity.

Local networks and CIDR

A local network is a group of connected devices that can communicate through the same private network or through permitted routing. A target range describes multiple possible IP addresses. CIDR notation expresses a network and its prefix length, such as 192.0.2.0/28. The /28 indicates the network size; it represents a small range suitable for a controlled lab example. Always confirm the exact scope before scanning a range.

Installing and verifying Nmap

Windows

Install Nmap using an approved Windows installer or software-management system.
During installation, allow the installer to add Nmap to the system PATH if that option is offered.
Open a new Command Prompt or PowerShell session.
Verify the installation:

nmap --version

If Windows reports that nmap is not recognized, reopen the terminal first. If the problem remains, confirm that Nmap is installed and that its installation directory is in PATH. A graphical interface may be available with some Windows packages, but command-line usage is easier to document and automate.

Linux

Use the package manager for your distribution. For example, Debian-based systems commonly use:

sudo apt update
sudo apt install nmap

RPM-based systems may use a command such as:

sudo dnf install nmap

After installation, verify the executable:

nmap --version

Some scan methods use raw packets and may require elevated privileges. Use an approved administrative shell only when necessary and permitted. If elevated access is unavailable, TCP connect scanning is often a compatible alternative.

Command structure and target selection

The basic structure is:

nmap [options] target

You can provide one IP address, one DNS name, or multiple authorized targets. Begin with one lab host and a small number of ports. A larger target range increases scan duration, traffic, and the number of results that must be reviewed.

nmap 192.0.2.10
nmap scanme.nmap.org
nmap 192.0.2.0/28

The first command scans one documentation-range example address. Substitute it only with an authorized target. The second demonstrates the Nmap-provided public test target; use it only according to that target's current published usage policy. The third targets a small example subnet and must be replaced with a range you are explicitly authorized to assess.

Basic TCP scans

A default Nmap scan checks a set of commonly used TCP ports and reports reachable hosts, port states, and service names inferred from port conventions. On a privileged system, Nmap commonly uses a SYN scan by default. Without the required privileges, it may use a TCP connect scan or require you to select one explicitly.

nmap 192.0.2.10
nmap -p 80,443 192.0.2.10
nmap -p 1-1024 192.0.2.10

The second command limits testing to selected web-service ports. The third scans a defined TCP range. Narrow scans are easier to authorize, faster to complete, and less disruptive than broad scans.

Port states

State	What it generally indicates	Common causes	Recommended validation step
open	An application appears to be accepting connections or datagrams.	A listening service and a permitted response.	Identify the service and compare it with the expected asset configuration.
closed	The host responded, but no service is listening on that port.	A reachable host with an unused port.	Check whether the result matches the host's intended configuration.
filtered	Nmap cannot determine whether the port is open because probes are blocked or dropped.	Firewalls, ACLs, packet filters, or silent filtering.	Validate firewall policy and test only approved paths or vantage points.
unfiltered	The port is reachable, but Nmap cannot determine whether it is open or closed with the selected method.	A response that does not reveal the port's listening state.	Use an appropriate authorized scan method or host-side verification.
open\|filtered	The port may be open, but Nmap received no response that distinguishes it from filtering.	Common with UDP and silent firewalls.	Use service-aware validation, logs, or confirmation from the system owner.
closed\|filtered	Nmap cannot distinguish a closed port from a filtered one.	Responses are ambiguous for the selected probe.	Review filtering and repeat only when operationally approved.

These states are evidence-based classifications, not absolute facts. Firewalls, host availability, packet loss, routing, and the network path can change what Nmap observes. A missing response does not prove that a host or port does not exist.

Host discovery and network mapping

Host discovery asks which targets appear active. Port scanning asks which ports on a host appear reachable and what services may be present. They are related but different activities.

To list responding hosts in a small authorized range without performing a normal port scan, use -sn:

nmap -sn 192.0.2.0/28

This produces a host-discovery result for each target that responds to the selected discovery probes. Firewalls may block discovery, so a host can be active even when it does not appear in the result.

In an approved environment where discovery is known to be unsuitable or unnecessary, -Pn skips host discovery and treats targets as available for scanning:

nmap -Pn -p 80,443 192.0.2.10

Skipping discovery can increase scan time and traffic, so use it only for a justified, authorized purpose. Discovered hosts and their observed services can become the basis of a network inventory or map. Record expected assets separately from observed assets so that missing or unexpected systems are visible.

TCP scan approaches

Characteristic	TCP	UDP	Practical implication
Connection model	Connection-oriented; responses follow TCP connection behavior.	Connectionless; applications may or may not respond to an unexpected datagram.	UDP results are often slower and less conclusive.
Common scan choices	TCP connect or SYN scanning.	UDP scanning with `-sU`.	Select a method that matches the approved test and available privileges.
Typical interpretation	Responses often distinguish open and closed more directly.	No response commonly produces open\|filtered.	Validate ambiguous UDP results with service knowledge or host records.

A TCP connect scan uses the operating system's normal TCP connection mechanism:

nmap -sT 192.0.2.10

A SYN scan evaluates responses to initial TCP connection packets without completing the application connection in the usual way. It commonly requires elevated privileges:

sudo nmap -sS 192.0.2.10

Choose between these approaches according to authorization, operating-system permissions, network controls, and operational impact. Neither scan type should be treated as invisible or risk-free.

UDP scanning

UDP has no connection handshake equivalent to TCP. Some UDP services respond only to valid application requests, while firewalls may silently drop probes. Nmap may therefore need to wait for timeouts, making UDP scans slower.

Start with a short list of relevant ports rather than all 65,536 UDP ports:

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

UDP port 53 is commonly associated with DNS, 123 with NTP, and 161 with SNMP, but the actual deployment may differ. An open|filtered result means Nmap could not distinguish an open service from filtering. ICMP destination-unreachable responses, application responses, packet loss, and timeouts all influence the conclusion.

Timing, delays, and scan performance

Scan speed depends on the number of targets and ports, network latency, packet loss, filtering, retries, and the selected scan method. Nmap timing templates provide predefined behavior from conservative to aggressive. Faster settings can reduce duration but may increase traffic, monitoring noise, and the chance of misleading results.

Control	Effect on scan behavior	When to use it	Trade-off
`-T2`	Uses a conservative timing profile.	Sensitive, busy, or high-latency authorized environments.	Longer scan duration.
`-T3`	Uses a moderate general-purpose profile.	Routine lab or controlled internal scans.	May still be unsuitable for fragile systems.
`-T4`	Uses a faster profile with more operational intensity.	Stable, explicitly approved environments.	More traffic and potentially less reliable results on lossy networks.
`--scan-delay 100ms`	Waits at least the specified interval between probes.	Reducing load or supporting reliable testing on sensitive targets.	Can substantially increase completion time.

nmap -T2 --scan-delay 100ms 192.0.2.10

Slower settings can improve reliability in sensitive or high-latency environments. Faster settings may cause missed responses or misleading classifications when a target or network cannot keep up. Repeat a narrowly scoped scan only when permitted, and compare the consistency of the results.

Service and version identification

A port number is not proof of the application behind it. Version detection sends additional probes to open or potentially open ports to identify the product and, when possible, its version:

nmap -sV -p 80,443 192.0.2.10

Version information can improve asset management, service verification, and remediation planning. It also increases traffic and may interact with application protocols, so keep it within the approved scope. Treat the result as evidence to validate, not as an unquestionable identity claim.

Understanding typical output

A normal result commonly contains these fields:

Target identity: The IP address and, when available, the resolved DNS name.
Host status: Whether Nmap considers the target up or down based on its probes.
Latency: An estimate of response time between the scanner and target.
Port/protocol: The port number and transport protocol, such as 443/tcp or 53/udp.
State: The classification such as open, closed, filtered, or open|filtered.
Service: A conventional or probe-inferred service name.
Version information: Product details obtained when version detection is enabled and successful.

Distinguish a port-based service label from a confirmed application identity. Compare observed ports with expected asset records, investigate unexpected exposure with the system owner, and record the command, target scope, date, vantage point, and interpretation.

Saving and documenting results

Save scan output for documentation, comparison, and reporting. Retain the target scope and authorization context with the output, not just the result file. Handle scan data according to organizational policy because it can reveal sensitive infrastructure details.

Format	Option	Best use case	Notes
Normal text	`-oN filename`	Human-readable reports and review.	Easy to read in a terminal or text editor.
XML	`-oX filename`	Structured processing, tools, and repeatable reporting.	Preserves structured scan data for later comparison.
Grep-friendly	`-oG filename`	Simple text filtering and scripting.	Useful for selected fields, but less complete than XML.

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

For each assessment, preserve the timestamp, exact command, target list or range, scan options, scanner location, authorization reference, and relevant environmental notes. Normal and XML output can complement each other: one supports human review and the other supports structured comparison.

Troubleshooting

Nmap cannot be found

If the shell reports that Nmap is not recognized or cannot be found, confirm that it is installed, reopen the terminal, and verify the executable path or PATH configuration.

Permission or raw-socket errors

The selected scan may require elevated privileges, or local security controls may restrict the required operations. Use an approved elevated shell where appropriate, or select a compatible method such as -sT.

The host appears down or all ports are filtered

Check the address and routing, confirm the target with its owner, and consider firewalls, packet filters, ignored discovery probes, and the approved network path. Filtering or lack of response is not proof that the host or port is absent.

UDP scanning is slow

Limit the scan to relevant approved ports. UDP commonly depends on timeouts and limited ICMP responses, and rate limiting can add delay. Do not interpret every timeout as evidence of an open service.

The detected service differs from the expected name

The service may be running on a nonstandard port, the conventional port label may not match the application, or version detection may have limited evidence. Compare with asset records and validate through approved service checks or the system owner.

Repeated scans differ

Congestion, packet loss, temporary filtering, load balancing, aggressive timing, or a changing service state can produce different results. Repeat only within scope, reduce the scan rate, compare saved outputs, and corroborate findings with operational records.

Practical learning sequence

Verify the installation with nmap --version.
Run a default scan against one authorized training host.
Scan only ports 80 and 443, then compare the result with the expected web-service configuration.
Perform host discovery across a small authorized lab range with -sn.
Run a limited UDP scan against relevant approved ports and explain any open|filtered results.
Repeat a narrowly scoped scan with -T2 and --scan-delay 100ms in a sensitive test environment.
Save normal and XML output, then document the command, scope, date, authorization, and findings.

For the course announcement, see We Have A New Course Nmap Introduction.