TechEarl

Nmap Command Examples: Scan Hosts, Ports, and Services

Practical nmap command examples I reach for: host discovery, the default port scan, service and version detection, OS fingerprinting, scoped scans with timing control, and the scripting engine, with notes on when each one needs root.

Ishan Karunaratne⏱️ 10 min readUpdated
Share thisCopied
Nmap command examples for scanning hosts, ports, and services: host discovery with -sn, default SYN scan, service and version detection with -sV, OS fingerprinting with -O, and the Nmap Scripting Engine.

The nmap command example I run first against any host is nmap -sV -T4 192.0.2.10: a default TCP scan with service/version detection at a brisk timing template. That single line tells me which of the top 1000 ports are open and what is listening on each. Everything else on this page is a variation on that theme: change the discovery, change the port set, change how loud or careful the scan is. Below are the nmap command examples I actually use, in the order I usually reach for them, with honest notes on which need root and which behave differently from what the man page implies.

One ground rule before the commands: only scan hosts and networks you own or have explicit written permission to test. Port scanning a network you do not control is, in many jurisdictions, the kind of thing that gets logged and reported.

What does nmap do?

Nmap (Network Mapper) is a free, open-source tool that sends crafted packets to hosts and interprets the responses to discover which hosts are up, which ports are open, what services and versions are listening, and often what operating system the host is running. It is the de facto standard for network discovery and security auditing. The typical workflow is: discover live hosts on a subnet (-sn), scan their ports (the default TCP scan, or -p for a specific set), identify the services behind open ports (-sV), and optionally fingerprint the OS (-O) or run deeper probes through the Nmap Scripting Engine (--script). Most scan types that craft raw packets (SYN scan, OS detection, UDP scan) require root privileges; the connect scan (-sT) is the unprivileged fallback.

Host discovery: who is alive on this subnet

Find live hosts without scanning any ports. This is the ping sweep:

bash
nmap -sn 192.168.1.0/24

-sn (formerly -sP) disables the port scan entirely. Nmap sends a mix of ICMP echo, TCP SYN to 443, TCP ACK to 80, and an ICMP timestamp request, then lists the hosts that answer. Run as root it also does ARP requests on the local segment, which is both faster and harder to block than ICMP.

If you only want the list of IPs and nothing else, skip discovery and just enumerate the targets nmap would scan:

bash
nmap -sL 192.168.1.0/24

-sL (list scan) sends no packets to the hosts at all. It does do reverse-DNS lookups by default, so it is not perfectly silent; add -n to skip DNS and make it fully passive.

The default scan: top 1000 TCP ports

With no scan-type flag, nmap scans the 1000 most common TCP ports:

bash
nmap 192.0.2.10

What it actually runs depends on your privileges. As root, the default is a SYN scan (-sS): nmap sends a SYN, watches for SYN/ACK (open) or RST (closed), and never completes the handshake. As an unprivileged user it falls back to a full TCP connect scan (-sT), which completes the three-way handshake and is therefore more likely to be logged by the target.

To be explicit about the SYN scan (and remember it needs root):

bash
sudo nmap -sS 192.0.2.10

The 1000 ports are not 1-1000. They are the 1000 statistically most common ports from nmap's nmap-services frequency data. To scan a specific port or range, use -p:

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

-p- scans all 65535 ports. It is thorough and slow; do not run it as your first pass against a large range.

Service and version detection

Open is not enough. -sV probes each open port to identify the service and its version:

bash
nmap -sV 192.0.2.10

A typical slice of output:

code
PORT    STATE SERVICE VERSION
22/tcp  open  ssh     OpenSSH 9.6p1 Ubuntu 3ubuntu13.5 (Ubuntu Linux; protocol 2.0)
80/tcp  open  http    nginx 1.24.0 (Ubuntu)
443/tcp open  ssl/http nginx 1.24.0 (Ubuntu)

Version detection works by matching service banners and probe responses against the nmap-service-probes database. Tune how hard it tries with --version-intensity 0 (light, fast) to 9 (try every probe). -sV --version-all is shorthand for intensity 9.

OS fingerprinting

-O guesses the operating system from TCP/IP stack quirks:

bash
sudo nmap -O 192.0.2.10

OS detection needs root because it crafts and reads raw packets, and it needs at least one open and one closed port to fingerprint reliably. The result is a probability-ranked guess, not a fact: nmap will print something like OS details: Linux 5.4 - 5.15 with an accuracy percentage. Treat it as a hint, not gospel, especially across NAT or behind a load balancer.

A common combination is the "aggressive" scan, which bundles version detection, OS detection, default scripts, and traceroute:

bash
sudo nmap -A 192.0.2.10

-A is loud. It is fine for a host you own; it is exactly the wrong choice when you are trying to stay quiet.

Choosing a scan type

FlagScan typeNeeds rootNotes
-sSTCP SYN ("half-open")YesDefault when privileged. Fast, relatively quiet.
-sTTCP connectNoDefault when unprivileged. Completes handshake, more likely logged.
-sUUDPYesSlow; UDP gives no SYN/ACK so nmap infers state from timeouts and ICMP.
-snNo port scan (host discovery)No (ARP needs root)Ping sweep only.
-sVService/version detectionNoLayers on top of a port scan; not a scan type by itself.
-OOS detectionYesNeeds one open and one closed port.
-AAggressive (-sV -O + scripts + traceroute)YesConvenient and noisy.

Timing, scope, and staying out of trouble

Timing templates trade speed for stealth and reliability. -T4 is my default for networks I own:

bash
nmap -sV -T4 192.0.2.10

The templates run -T0 (paranoid, one probe every five minutes, for IDS evasion) through -T5 (insane, for fast LANs where you do not care about dropped results). -T3 is the implicit default; -T4 is faster and fine on modern links; -T0 and -T1 are genuinely for evading detection and will take hours.

Scope a scan by feeding targets from a file rather than the command line:

bash
nmap -iL targets.txt -p 80,443 -oA web-scan

-iL reads one target per line. -oA web-scan writes all three output formats at once: normal (.nmap), grepable (.gnmap), and XML (.xml). The XML is the one to keep; it feeds into reporting tools and into ndiff for comparing two scans over time.

A couple of flags worth knowing for accuracy and politeness:

  • -Pn skips host discovery and treats every target as up. Use it when a host blocks ping but you know it is there; without it nmap may skip a live-but-silent host entirely.
  • -n skips reverse-DNS, which speeds up large scans and avoids hammering the DNS server with PTR lookups.
  • --top-ports 100 scans the 100 most common ports instead of 1000, for a faster first pass.

The Nmap Scripting Engine

NSE runs Lua scripts for deeper enumeration and vuln checks. The default category runs with -sC (or as part of -A):

bash
nmap -sC -sV 192.0.2.10

Run a specific script or category by name:

bash
nmap --script http-title 192.0.2.10
nmap --script "ssl-*" -p 443 192.0.2.10
nmap --script vuln 192.0.2.10

The vuln category probes for known vulnerabilities. It is genuinely useful and genuinely intrusive; some scripts in it can crash fragile services. Read what a script does (nmap --script-help http-title) before pointing it at production. Scripts live in nmap's scripts/ directory; --script-updatedb rebuilds the index after you add your own.

When nmap is the wrong tool

Nmap maps reachable network surface. It does not test web-application logic, SQL injection, or authentication flaws behind an open port; that is a different layer. If port 443 is open and you need to probe the app behind it, nmap hands off to tools like sqlmap (covered in my sqlmap cheat sheet) for injection testing. Nmap also will not enumerate a local filesystem; for that the right tool is the shell, and the find command cheat sheet is the reference I keep open there.

Two more honest limits. A SYN scan against a stateful firewall can report ports as filtered rather than open or closed, which tells you a firewall is dropping packets, not whether the service exists. And UDP scans (-sU) are slow and unreliable by design, because a closed UDP port often simply does not answer, so nmap waits out the retransmission timeout on every silent port; budget the time, and add -sV (which sends protocol-specific payloads) if open ports come back as open|filtered.

FAQ

See also

Sources

Authoritative references this article was fact-checked against.

TagsnmapNetworkSecurityPort ScanningPenetration TestingCLIReconnaissance

Found this useful? Pass it on.

Copied

Ishan Karunaratne

Tech Architect · Software Engineer · AI/DevOps

Tech architect and software engineer with 20+ years building software, Linux systems, and DevOps infrastructure, and lately working AI into the stack. Currently Chief Technology Officer at a healthcare tech startup, which is where most of these field notes come from.

Keep reading

Related posts

Managed WordPress Hosting vs VPS for Agencies

Managed WordPress hosting buys you operational simplicity at a per-site price premium. VPS buys you flexibility and lower per-resource cost at the price of in-house sysadmin time. The honest comparison and the agency-side break-even math.