How to use Nmap safely and read the results

But Nmap maps a network; it does not find vulnerabilities with a magic button. Its first job is to show you what answers on a network.

Beginner material often treats discovery, port scanning, service detection, and enumeration as interchangeable. But each answers a different question:

• Discovery finds reachable hosts.
• Port scanning identifies reachable ports.
• Service detection identifies applications and versions.
• Enumeration gathers the detail needed for a decision.

A list of 100 commands is not a beginner’s guide. (If your goal is locking down the machine you scan, start with our Linux server hardening checklist.); it’s a filing cabinet with worse typography. This Nmap for beginners guide follows one workflow. Authorize, install, discover, scan, interpret and enumerate. Then report the result and choose the next tool.

In this article

• Nmap maps exposure, not vulnerabilities
• Scan only systems you’re authorized to test
• Install a reproducible Nmap setup
• Start with host discovery, not a giant scan
• [Port states are observations, not verdicts](#porthttpsnmaporgbookmanhtml-states-are-observations-not-verdicts)
• Build the scan in layers
• -A is a bundle, not a beginner default
• Choose NSE scripts by question
• Save the command with the result
• Turn open ports into questions
• Choose alternatives by job
• Use this repeatable Nmap workflow

Nmap maps exposure, not vulnerabilities

For a beginner who needs explainable evidence, Nmap is a strong default starting point. And its man page describes an open-source tool that uses raw IP packets to identify available hosts, services, versions, operating systems, and filtering characteristics.

So Nmap maps exposure. It shows what responds and how it responds.

An open SSH port might be an expected administration path, a badly exposed management interface, or a service protected by strong controls. But Nmap cannot decide which one it is.

Nmap is a standard first step in testing an API with curl and most other manual security work. It was first released on September 1, 1997, in a Phrack 51 article titled “The Art of Port Scanning.” It runs on Windows, Linux, and macOS. The official book offers deeper study. The practical lesson is simpler: connect each observation to the next question.

Scan only systems you’re authorized to test

So define the target and your permission before you install a scanner.

Scanning your own home lab, an authorized company asset, or an expressly provided practice target differs from probing an arbitrary public host. Scanning creates traffic and may affect fragile equipment or trigger monitoring systems. ROIhacks’ guidance on learning Nmap safely treats authorization as a prerequisite.

Use Nmap only against systems you own or have explicit permission to test. Record the target, scope, time window, and permitted scan types before you start.

For practice, the Nmap project provides scanme.nmap.org as a learning target. Use it only for the practice permitted by the Nmap project. A public address requires permission.

A useful authorization gives you an owner, a maintenance window, expected services, and a contact for unusual results. That context turns a port list into an investigation.

Install a reproducible Nmap setup

Choose the installation that makes your first scan easy to repeat.

On Debian or Ubuntu, the package manager is the simplest route:

sudo apt update
sudo apt install nmap

Package versions may trail upstream releases. HackerTarget recorded Nmap 7.98 as the latest stable release it tested in January 2026; check the official Nmap documentation for current releases.

Use a package when convenience matters more than having the newest fingerprints and scripts. Build from source when you have a specific reason to need newer capabilities and can maintain the installation:

sudo apt update
sudo apt install g++ libssl-dev wget
wget https://nmap.org/dist/nmap-7.98.tar.bz2
bzip2 -cd nmap-7.98.tar.bz2 | tar xvf -
cd nmap-7.98/
./configure
make
sudo make install

The commands above follow HackerTarget’s tested source-build path; the versioned download address may change, so verify the release before copying it.

Docker gives you an isolated, repeatable environment but adds container setup. Windows users can choose the official installer for a native experience. WSL2 provides a Linux-style workflow. Linux generally offers the smoothest Nmap experience, so the examples here use Linux commands.

Pick one path, record its version, and move on. Package archaeology is rarely the lesson you came for.

Start with host discovery, not a giant scan

Suppose 192.168.1.10 is an authorized lab host on your private network. Begin by checking which addresses respond:

sudo nmap -sn 192.168.1.0/24

-sn performs host discovery without a port scan. It answers a narrow question: which addresses responded to these probes?

You may see output shaped like this:

Nmap scan report for 192.168.1.10
Host is up.
Nmap done: 256 IP addresses (3 hosts up) scanned

The three-host result and 3.29-second duration are from an example in HackerTarget’s tutorial, not a guaranteed result for your network. Wireless behavior, firewall rules, routing, and sleeping devices all affect discovery.

Treat discovery as a lead, not an inventory. A failed response does not establish that a host is absent, because filtering and host behavior can suppress probes. If an authorized asset inventory gives you a known address, scan that address directly as well.

Once the lab host appears, narrow the next scan to 192.168.1.10.

Port states are observations, not verdicts

Filtered does not mean closed, and open does not automatically mean dangerous.

State	What Nmap observed	What remains unknown
open	Nmap received a response indicating that an application is listening.	Whether the service is approved, correctly configured, or vulnerable
closed	The host is reachable, but no service is listening; an RST commonly answers.	Whether the port will remain closed
filtered	A firewall or ACL prevented Nmap from determining the state.	Whether a service exists behind the filter
open|filtered	Nmap couldn’t distinguish an open port from a filtered one.	Which state applies
closed|filtered	Nmap couldn’t distinguish a closed port from a filtered one.	Which state applies

A rejecting firewall sends a response and may make a port appear closed. A dropping firewall commonly produces filtered. UDP scans often produce open|filtered, because silence is difficult to interpret.

Synthetic output for illustrating the columns; it is not a result from 192.168.1.10:

PORT   STATE     SERVICE
22/tcp open      ssh
23/tcp filtered  telnet
80/tcp closed    http

An open state is an exposure observation; a finding requires an expected-state, configuration, version, or testing comparison.

This guide can teach you to collect and interpret exposure evidence. It cannot tell you whether a service is approved or exploitable. Those conclusions require asset records, configuration evidence, and testing beyond Nmap.

Build the scan in layers

Run the simplest command that answers your current question.

sudo nmap 192.168.1.10

A default TCP scan covers Nmap’s 1,000 most common ports. That’s a sensible first pass because it gives you useful coverage without immediately producing a wall of output.

With suitable privileges, make the TCP method explicit:

sudo nmap -sS 192.168.1.10

-sS performs a TCP SYN scan. Without the required raw-packet privileges, use a TCP connect scan:

nmap -sT 192.168.1.10

Without raw-packet privileges, Nmap uses TCP connect scanning, which generally creates a completed connection and may be slower or more visible.

Now identify the applications and versions behind open ports:

sudo nmap -sV 192.168.1.10

Version detection interrogates discovered services and attempts to identify the application and version. A line such as 22/tcp open ssh becomes more useful when Nmap can identify the implementation behind it.

If the common-port result raises a reasonable question about an unusual service, expand the range:

sudo nmap -p- 192.168.1.10

-p- scans all 65,535 TCP ports. It creates more traffic and output, so use it when the decision warrants broader coverage. Pair it with version detection when you need the expanded result to be actionable:

sudo nmap -p- -sV 192.168.1.10

OS detection uses TCP/IP fingerprinting:

sudo nmap -O 192.168.1.10

The result is an OS estimate whose quality depends on the responses and network path. Treat it as evidence to verify, particularly when the result affects remediation.

UDP requires a separate scan:

sudo nmap -sU 192.168.1.10

UDP scanning is slower and harder to interpret because many services don’t answer unexpected probes. Use it when the asset or inventory makes UDP relevant.

-A is a bundle, not a beginner default

“Why use -A first?” Because it combines several jobs before you know which job you need.

sudo nmap -A TARGET

-A enables OS detection and version detection. It also runs the default scripts and traceroute. In a controlled lab, it’s useful for studying how those features interact. In routine work, it can bury the basic observation under extra output.

You may get OS guesses, version probes, default scripts and a traceroute in one result. That makes it harder to identify which observation answers which question. It can also create more traffic and more impact on the target.

Nmap’s timing templates run from -T0 through -T5, from paranoid to insane. Faster timing can trigger intrusion-detection alerts. It can also affect fragile devices. Use the default timing until you understand the target and the consequences of changing it.

Using aggressive options to compensate for unclear scope is reckless. The stopping rule is straightforward: clarify the authorization before increasing scan intensity.

Choose NSE scripts by question

The Nmap Scripting Engine, or NSE, extends Nmap with Lua scripts for discovery and vulnerability-detection tasks. The official NSE documentation lists the current library, which has grown beyond older script-count descriptions.

The default script set uses -sC:

sudo nmap -sV -sC TARGET

The default set sends additional probes. Read the script descriptions before using it against production equipment, even when the scan is authorized.

For a specific script, determine from its documentation whether it performs banner collection, authentication attempts, or vulnerability checks. Then select it by name only after reviewing its behavior:

sudo nmap -sV --script <script-name> TARGET

Replace <script-name> with a documented script you have chosen deliberately. A script result still needs confirmation through service details, configuration review, or an authorized assessment.

You don’t need to memorize the library. You need to know why you selected the script.

Save the command with the result

Save output as you work so another person can reproduce the scan.

For readable notes:

sudo nmap -sV -oN scan.txt TARGET

For XML used by other tooling:

sudo nmap -sV -oX scan.xml TARGET

For the major formats together:

sudo nmap -sV -oA baseline TARGET

-oN writes normal human-readable output. -oX writes XML. -oA baseline creates:

baseline.nmap
baseline.xml
baseline.gnmap

Keep the command, target, timestamp, operator and authorization reference with the files. Add the purpose too. Use an actual date in a descriptive basename, for example:

lab-host-TARGET-YYYY-MM-DD

Replace YYYY-MM-DD with the scan date. Store the results with controlled access because service inventories reveal network structure.

Turn open ports into questions

Start with the observation, then work through the context:

1. Confirm the service and version. Use -sV, then verify important details through the service owner or another authorized control.
2. Ask whether the service should be reachable. SSH on port 22 may be expected administration. HTTP on port 80 may serve an internal application. SMTP on port 25 may belong to a mail system.
3. Identify the owner and expected configuration. An unrecognized service deserves escalation because nobody can explain its purpose.
4. Choose the next investigation. Move to configuration review, authenticated assessment, application testing, firewall validation, or vulnerability management according to the question.

Port numbers provide leads. They don’t provide a verdict.

Filtered is not proof of safety; it means this scan could not answer the question. An open port is an exposure observation, while a security finding needs context such as an unauthorized service, a weak configuration, an outdated version, or a confirmed test result.

Stop using Nmap when the next question concerns authentication, application behavior, patch status, or configuration. Those questions belong to the owner or a tool designed to answer them.

Choose alternatives by job

Picking the right tool depends on the job, which is why we wrote a guide to choosing pentesting tools.

Nmap is the right starting point when you need explainable, detailed results. Other tools solve different problems.

Tool	Best fit	Trade-off
Nmap	Service detection and OS detection. NSE and detailed investigation	Broad scans take time and need interpretation
Masscan	Very fast, broad port discovery	Less service context and greater scope risk
RustScan	Fast discovery that can feed results into Nmap	Adds another tool and configuration layer
Online scanners	Reconnaissance without local installation	Less control over the scanning environment

ScanSearch describes Masscan as a tool for very broad discovery, including internet-scale work. Keep that use case inside explicit authorization and carefully bounded scope. Speed increases the cost of a mistake.

Netalith’s comparison describes RustScan’s role as fast port discovery followed by Nmap for detail. Online scanners trade local setup for less control over where and how probes run.

Use another scanner when scale or speed is the problem and you can control the scope. Choose Nmap when the result must explain what was observed and support a defensible next action.

Use this repeatable Nmap workflow

The baseline commands are only one part of the full ladder:

1. Authorize: record the target and permission. Note the scope, timing and scan limits.
2. Install: choose a documented Nmap environment and record its version.
3. Discover: find responsive hosts when the address range is uncertain.
4. Scan: inspect common TCP ports, then expand to all ports when justified.
5. Interpret: read open, closed, and filtered as probe results.
6. Enumerate: identify services, versions, ownership, and expected configuration.
7. Report: save the command, output, timestamp, and evidence.
8. Choose the next tool: move to configuration review, application testing, vulnerability management, or a faster scanner when the question demands it.

OS detection, UDP scanning, and NSE are deliberate follow-ups. They don’t belong in every first scan.

Use this reporting template:

Target:
Authorization:
Command:
Time:
Observed states/services:
Owner:
Next question:

If you can’t fill those fields, you’re still scanning; you’re not yet investigating.