Nmap for DevOps Engineers

Nmap (“Network Mapper”) is the standard tool for answering a question DevOps engineers ask constantly: what is actually reachable on this host, and is that what I intended? This lesson teaches Nmap as an infrastructure validation tool — a way to confirm that a deployment, firewall rule, or security group exposes exactly the ports you expect, and nothing more.

We won’t treat Nmap as an “attack” tool. We’ll treat it as a measurement instrument: point it at infrastructure you own, read what it reports, and compare that to your intended state.

Why Nmap Belongs in a DevOps Toolbox

When you deploy a service, you have an intended network exposure in your head or in a config file (a security group, a firewall rule, a Kubernetes Service). Nmap tells you the actual exposure as observed from the network. The gap between those two is where incidents live:

A database that was supposed to be internal is answering on a public IP.
A firewall change you thought you applied never took effect.
A deploy opened a debug port (8080, 9229) that should never have shipped.
A load balancer forwards a port you forgot to close.

Nmap turns “I think it’s fine” into “I measured it, and here’s what’s reachable.”

🛠️ DevOps Perspective — Treat expected network exposure like any other spec. You write down which ports should be open, then you assert it — the same way you assert an HTTP endpoint returns 200 in a smoke test. Nmap is how you assert exposure. Wire it into a post-deploy check or a firewall-change runbook and it becomes a repeatable control, not a one-off manual poke.

The Ethics and Legality First

Nmap sends packets to a target and reads the responses. On systems you own or are explicitly authorized to test, that’s routine operations work. Against systems you don’t own, port scanning can be a criminal offense in many jurisdictions and will almost certainly violate acceptable-use policies.

⛔ Production Warning — Only scan systems you own or are explicitly authorized to test. Scanning third-party hosts, cloud IPs you don’t control, or a former employer’s network is often illegal and can get your IP blocked or your account terminated. Every example in this lesson targets <lab-host> — a machine in your own lab, VM, or account. Never substitute a real third party.

🔐 Security Note — Even against your own infrastructure, aggressive scans can trip intrusion-detection systems, page an on-call engineer, or briefly load a fragile service. Tell your team before scanning shared environments, and prefer a lab host or a dedicated test target for practice.

Throughout, <lab-host> means a target you control — for example a VM at 192.168.56.10, a container you started, or scanme.nmap.org (a host the Nmap project explicitly provides for practice). Replace it with your own lab target.

Installing and Checking Nmap

Nmap ships with Kali. On any Debian/Ubuntu system you can install it with apt:

# Confirm Nmap is present and check the version
nmap --version

# If it's missing (non-Kali systems)
sudo apt update && sudo apt install -y nmap

Knowing the version matters because service/version detection and the scripting engine improve over releases.

The Three Questions Nmap Answers

Most infrastructure validation reduces to three questions, in order:

Question	Nmap term	What you learn
Is the host up?	Host discovery	Whether something answers at this address
Which ports respond?	Port discovery	The actual reachable surface
What’s listening there?	Service/version detection	Whether the right software is exposed

We’ll walk each one, then combine them into a single deployment-validation check.

1. Host Discovery — Is Anything There?

Before scanning ports, Nmap tries to decide whether a host is even alive. By default it sends probes (pings, ARP on a local network) and skips hosts that don’t respond.

# Discover which hosts are up in a lab subnet (no port scan: -sn)
nmap -sn 192.168.56.0/24

-sn means “ping scan, no port scan.” This is how you inventory a lab network — for example, confirming which VMs in your test subnet are running.

The catch: many production and cloud hosts drop ICMP pings by design. Nmap will then wrongly conclude the host is “down” and skip it. That’s where -Pn comes in:

# Skip host discovery and scan anyway — treat the host as up
nmap -Pn <lab-host>

🔎 Troubleshooting Tip — If Nmap reports Host seems down for a host you know is running, add -Pn. Cloud firewalls and security groups routinely block ping, which makes default host discovery unreliable. For validating a deployed service, -Pn is usually the right default because you already know the host exists — you just deployed to it.

2. Port Discovery — What’s Reachable?

This is the core of infrastructure validation. You have a list of ports you expect to be open. You ask Nmap what it actually finds.

Say you just deployed a web app to <lab-host> and the spec says it should expose exactly these ports:

22/tcp
80/tcp
443/tcp

SSH for management, HTTP, and HTTPS — nothing else. Here’s how you assert that.

First, scan exactly the expected ports and confirm they’re open:

# Check only the ports the deployment is supposed to expose
nmap -Pn -p 22,80,443 <lab-host>

-p 22,80,443 restricts the scan to those three ports; -Pn skips the ping check. Expected output for a healthy deploy:

PORT    STATE SERVICE
22/tcp  open  ssh
80/tcp  open  http
443/tcp open  https

All three open means the service came up and is reachable. If one shows closed or filtered, your deployment or firewall isn’t done yet.

But confirming the expected ports are open is only half the job. The more important question for security is: is anything else open that shouldn’t be? For that, scan a wider range and look for surprises:

# Scan all 65,535 TCP ports to catch anything unexpected
nmap -Pn -p- <lab-host>

-p- means “every TCP port.” This is slower, but it’s the scan that catches the accidentally-exposed debug port, the leftover database listener, or the metrics endpoint you never meant to publish. For a clean deploy you want to see only your three ports:

PORT    STATE SERVICE
22/tcp  open  ssh
80/tcp  open  http
443/tcp open  https

Nmap done: 1 IP address (1 host up) scanned

If instead you see something like this, you’ve found a problem:

PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
443/tcp  open  https
5432/tcp open  postgresql     <-- unexpected! database exposed
8080/tcp open  http-proxy     <-- unexpected! debug/admin port

Those two extra lines are exactly the kind of finding that turns into an incident. Nmap surfaced them before an attacker — or a bug bounty report — did.

Understanding the three port states is essential:

State	Meaning	DevOps interpretation
`open`	A service is actively accepting connections	Something is listening here
`closed`	Host reachable, but nothing listening on that port	Port is free; no service bound
`filtered`	A firewall dropped the probe; Nmap can’t tell	A firewall/security group is blocking

The difference between closed and filtered is where firewall validation happens, which is the next section.

🔎 Troubleshooting Tip — A default nmap <lab-host> scans the 1,000 most common ports, not all 65,535. That’s fine for a quick check but will miss a service on an unusual port. When you’re auditing for unexpected exposure, use -p-. When you’re validating a known spec, use -p with your exact list.

3. Service and Version Detection — What’s Actually Listening?

A port being open tells you something is there. -sV tells you what — the service and, often, its version.

# Identify the service and version behind each open port
nmap -Pn -sV -p 22,80,443 <lab-host>

Sample output:

PORT    STATE SERVICE  VERSION
22/tcp  open  ssh      OpenSSH 9.6p1 Debian
80/tcp  open  http     nginx 1.25.4
443/tcp open  ssl/http nginx 1.25.4

This matters for validation in two ways:

Right software, right port. You expected nginx on 80/443. If -sV reports something else — say an application server or an old, unpatched version — your deploy didn’t do what you thought.
Version awareness. Exposed versions feed straight into vulnerability management. If -sV reports a version with known CVEs, that’s a patching action item.

🔐 Security Note — Service banners can leak more than you want (exact versions, OS hints). Seeing what -sV exposes from the outside is itself useful: it’s the same information an attacker would gather first. If a banner reveals a precise, outdated version, consider whether you can suppress or update it.

Verifying a Firewall Change

Firewall and security-group changes are a classic “I applied it but did it take effect?” problem. Nmap gives you a before/after measurement.

Suppose you’re closing off port 5432 (Postgres) so it’s no longer reachable from outside. Before the change:

nmap -Pn -p 5432 <lab-host>
# 5432/tcp open postgresql

You apply the firewall rule, then re-scan:

nmap -Pn -p 5432 <lab-host>
# 5432/tcp filtered postgresql

The state changing from open to filtered is your proof the firewall is now dropping traffic to that port. If it still shows open, the rule didn’t apply — wrong security group, wrong direction, or a rule ordering problem.

🛠️ DevOps Perspective — This before/after pattern is the reusable core of firewall-change verification. Capture the scan output in your change ticket as evidence. open → filtered proves the block landed; open → still open tells you to keep digging before you close the change.

For a fuller picture of how firewalls, subnets, and ports fit together, revisit networking fundamentals, which covers the concepts (TCP, ports, CIDR) that Nmap output assumes you understand.

Faster and Quieter Scans

A few flags make Nmap practical in real workflows:

# -F scans only the top 100 ports — a fast smoke test
nmap -Pn -F <lab-host>

# -T4 speeds up timing on a reliable local/lab network
nmap -Pn -T4 -p 22,80,443 <lab-host>

# --open shows only open ports, cutting noise from closed ones
nmap -Pn -p- --open <lab-host>

-T4 is aggressive timing; it’s fine on a fast lab network but can overwhelm fragile or high-latency targets, so don’t reach for it against anything delicate.

⛔ Production Warning — Avoid aggressive timing (-T4/-T5) and full -p- sweeps against fragile production systems during business hours. A hard scan can spike CPU on a small instance or trip alerting. If you must validate production exposure, prefer a targeted -p <known list> scan in a maintenance window, and tell your team first.

Machine-Readable Output for CI/CD

To fold Nmap into automation, emit structured output instead of the human-readable text:

# -oX writes XML; -oG writes greppable output; -oN writes normal text
nmap -Pn -p 22,80,443 -oX deploy-scan.xml <lab-host>

# Quick greppable check in a script
nmap -Pn -p- -oG - <lab-host> | grep -E "open"

A post-deploy job can scan the new host, parse the output, and fail the pipeline if any port outside the expected set is open. That turns “someone should check the firewall” into an automated gate — the same philosophy behind the Docker Production Readiness Auditor and the config checks in the validators toolbox: encode the intended state, then assert it automatically.

🛠️ DevOps Perspective — A deploy-validation scan is a natural CI/CD step after a service is live in a staging or lab environment. Define your expected-ports list next to the deployment config, scan the freshly deployed host, and diff actual-open against expected-open. Any extra open port fails the build. This catches accidental exposure before it reaches users.

Putting It Together: Validate the Deployment

Here’s the full validation flow for our example app, whose spec is 22/tcp, 80/tcp, 443/tcp and nothing else:

# 1. Confirm the expected ports are open
nmap -Pn -p 22,80,443 <lab-host>

# 2. Confirm nothing ELSE is open across all ports
nmap -Pn -p- --open <lab-host>

# 3. Confirm the right services/versions are behind the open ports
nmap -Pn -sV -p 22,80,443 <lab-host>

If step 1 shows all three open, step 2 shows only those three, and step 3 shows the software you expected — the deployment matches its intended exposure. If any step disagrees, you’ve found a deploy or firewall defect before it became a production problem.

🧪 Try It — Spin up a lab target you control (a local VM, a container running nginx, or scanme.nmap.org, which the Nmap project provides for practice). Run all three commands above against it. Then deliberately start an extra service — for example python3 -m http.server 8000 — and re-run the -p- scan. Watch 8000/tcp appear as open. That new line is exactly what “accidentally exposed service” looks like in the wild. Stop the service and confirm the port disappears from the scan.

Where Nmap Fits Among Your Tools

Nmap answers what ports and services are reachable. It pairs with the other diagnostics in this series:

Use tcpdump when you need to see the actual packets, not just port states.
Use the broader toolkit in tools for DevOps engineers to go from “this port is open” to “here’s what the service does.”
Practice the whole loop safely in the first DevOps security lab, where you build a target environment you fully control and scan it end to end.

What You Learned

Nmap is an infrastructure validation tool, not just a security scanner: it measures actual network exposure so you can compare it to your intended spec.
The three core questions — host discovery (-sn, -Pn), port discovery (-p, -p-), and service/version detection (-sV) — map directly to validating a deployment.
To validate a deploy that should expose only 22, 80, and 443, confirm those ports are open, then scan -p- to prove nothing else is reachable, and use -sV to confirm the right software is listening.
Port states matter: open means listening, closed means free, and filtered means a firewall is blocking — the open → filtered transition is how you prove a firewall change took effect.
Structured output (-oX, -oG) lets you wire deploy-validation scans into CI/CD, failing the build when an unexpected port is exposed.
Only scan systems you own or are explicitly authorized to test. Use lab targets, warn your team, and keep aggressive scans away from fragile production.