Nmap for Authorized Infrastructure Validation (Not Hacking)

Every deploy makes a promise about the network: "this box only exposes SSH and HTTPS," "the database is never reachable from outside the app tier." Nmap is how you turn that promise into a test that either passes or fails. Nobody has to take the security group's word for it. One rule before anything else: only scan systems you own or are explicitly authorized to assess. Point Nmap at a lab, a VM you control, or your own infrastructure. This is authorized infrastructure validation — a defensive check on exposure you're responsible for, not "hacking." Start with what's actually listening The most basic useful run is a host scan: nmap 192.168.56.10 This does host discovery and a default TCP scan of the common ports. The output lists each port as open, closed, or filtered. open means something accepted the connection. filtered usually means a firewall or security group silently dropped the packet — which is exactly the signal you want when validating that a rule is doing its job. If you expected a wall of filtered and instead see open, that's your finding. When you already know what should be exposed, scan for exactly that and nothing else: nmap -p 22,80,443 host Narrowing to the declared ports keeps the scan fast and the output readable. The question you're answering isn't "what's out there" — it's "does observed reality match what I declared?" Confirm what's really on the port An open port tells you a socket is listening. It does not tell you what. For that, add version detection: nmap -sV -p 22,80,443 host -sV probes each open port and reports the service and, when it can, the version banner. This matters because ports lie. A service you assumed was nginx on 443 might be something a teammate stood up last week. Read the SERVICE and VERSION columns and ask: is this the thing I expected, at the version I expected? A mismatch here is often the first sign of drift or a forgotten container. A methodology, not just commands Running Nmap ad hoc gives you trivia. Running it as a pipeline gives you a regression test for your network posture. The loop I use after every deploy: Declared Configuration → Expected Exposure → Observed Exposure → Compare → Correct → Retest. Declared Configuration — the source of truth: the security group, firewall rules, or Terraform that says what's allowed. Expected Exposure — translate that into a concrete list of ports that should answer. For a web tier: 22 (from bastion only) and 443. Observed Exposure — what Nmap actually sees. Compare — diff the two. Every open port that isn't in the expected list is a finding. Correct — fix the rule, the container publish, or the config. Retest — scan again. The finding must be gone. No retest, no fix. A concrete finding Say the declared config for a web host is SSH and HTTPS only. Expected exposure: 22, 443. You run: nmap -sV -p 22,443,3306 web-host.internal And 3306 comes back: PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH ... 443/tcp open https ... 3306/tcp open mysql MySQL ... 3306 is MySQL, and it was never in the declared config. Observed doesn't match expected — that's the finding. The hypothesis writes itself: a container published 3306:3306 to the host instead of binding to an internal network, or a security group rule is broader than intended. Correct it (bind the DB to the app network, tighten the rule), then rerun the exact same scan. When 3306 comes back filtered or absent, the loop closes. That Declared → Observed → Retest discipline is the core of the full Nmap network validation walkthrough, which builds this into a repeatable post-deploy check. A note on scan types and privileges Some scan types need elevated privileges. A SYN scan (-sS), for example, crafts raw packets and requires CAP_NET_RAW — run unprivileged, Nmap quietly falls back to a slower connect scan. In a container, grant only that capability: docker run --rm --cap-add NET_RAW instrumentisto/nmap -sS -p 22,443 host Never reach for --privileged. It hands the container the full capability set and effectively removes the kernel's isolation between it and the host — a wildly oversized trade for one raw-socket permission. --cap-add NET_RAW grants exactly what the scan needs and nothing more. If you're wiring Nmap into container-based checks, the Docker-based service discovery lesson covers the disposable-toolbox pattern in depth. Wrap up Nmap earns its place in a DevOps toolkit not as an offensive tool but as an assertion engine: it makes "the firewall should only allow X" something you can prove after every change. Work through the Nmap network validation lesson to turn this loop into a habit — and the site has free, hands-on Kali networking learning paths aimed squarely at DevOps engineers who'd rather test their infrastructure than trust it.