Nmap for Authorized Infrastructure Validation (Not Hacking)

查看原文 / View Original 编辑 / Edit

Nmap for Authorized Infrastructure Validation (Not Hacking)

使用 Nmap 进行授权基础设施验证（而非黑客攻击）

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. 每一次部署都对网络做出了承诺：“这台机器只暴露 SSH 和 HTTPS 端口”，“数据库永远不会从应用层之外被访问”。Nmap 正是将这种承诺转化为测试（通过或失败）的工具。你无需盲目信任安全组的配置。

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.” 在开始之前，请记住一条铁律：只能扫描你拥有或明确授权评估的系统。将 Nmap 指向实验室环境、你控制的虚拟机或你自己的基础设施。这是授权的基础设施验证——一种针对你所负责的暴露面的防御性检查，而非“黑客攻击”。

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. 最基础且有用的操作是主机扫描：nmap 192.168.56.10。它会执行主机发现并对常用端口进行默认的 TCP 扫描。输出结果会将每个端口标记为 open（开放）、closed（关闭）或 filtered（过滤）。open 意味着有服务接受了连接；filtered 通常意味着防火墙或安全组静默丢弃了数据包——这正是你在验证规则是否生效时想要看到的信号。如果你预期看到的是一片 filtered，结果却看到了 open，这就是你的发现。

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?” 当你已经明确知道哪些端口应该暴露时，只需扫描这些端口：nmap -p 22,80,443 host。将范围缩小到声明的端口可以保持扫描速度并使输出易于阅读。你所要回答的问题不是“外面有什么”，而是“观察到的现实是否与我声明的一致？”

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. 开放端口仅告诉你有一个套接字在监听，但不会告诉你是什么。为此，请添加版本检测：nmap -sV -p 22,80,443 host。-sV 会探测每个开放端口，并报告服务名称以及（如果可能的话）版本横幅。这一点很重要，因为端口会“撒谎”。你以为 443 端口上运行的是 nginx，但它可能是同事上周搭建的其他服务。查看 SERVICE 和 VERSION 列并自问：这是我预期的服务及其版本吗？此处的不匹配往往是配置漂移或遗忘容器的第一个迹象。

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. 临时运行 Nmap 只会给你一些零碎信息。将其作为流水线运行，则能为你的网络态势提供回归测试。我在每次部署后使用的循环是：声明配置 → 预期暴露 → 实际暴露 → 对比 → 修正 → 重测。

  • 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.

  • 声明配置 — 真理来源：定义允许内容的各种安全组、防火墙规则或 Terraform 代码。

  • 预期暴露 — 将其转化为应响应的端口具体列表。例如 Web 层：22（仅限堡垒机访问）和 443。

  • 实际暴露 — Nmap 实际扫描到的结果。

  • 对比 — 对比两者差异。任何不在预期列表中的开放端口都是一个发现。

  • 修正 — 修复规则、容器发布配置或配置文件。

  • 重测 — 再次扫描。必须消除该发现。不重测，就不算修复。

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: 假设 Web 主机的声明配置仅为 SSH 和 HTTPS。预期暴露：22, 443。你运行：nmap -sV -p 22,443,3306 web-host.internal。结果 3306 端口返回：

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. 3306 是 MySQL，它从未出现在声明配置中。实际情况与预期不符——这就是发现。假设显而易见：某个容器将 3306:3306 映射到了主机，而不是绑定到内部网络，或者安全组规则设置得过于宽泛。修正它（将数据库绑定到应用网络，收紧规则），然后重新运行相同的扫描。当 3306 返回 filtered 或消失时，循环闭合。这种“声明 → 观察 → 重测”的纪律是完整 Nmap 网络验证流程的核心，它将其构建为一种可重复的部署后检查。

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. 某些扫描类型需要提升权限。例如，SYN 扫描 (-sS) 会构造原始数据包，需要 CAP_NET_RAW 权限——如果以非特权模式运行，Nmap 会静默回退到较慢的 connect 扫描。在容器中，只需授予该能力：docker run --rm --cap-add NET_RAW instrumentisto/nmap -sS -p 22,443 host。永远不要使用 --privileged。它会赋予容器全部能力集，并有效地移除了内核与主机之间的隔离——为了一个原始套接字权限而付出如此巨大的代价是不值得的。--cap-add NET_RAW 仅授予扫描所需的权限，不多不少。

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. Nmap 在 DevOps 工具箱中占有一席之地，不是因为它是一个攻击工具，而是因为它是一个断言引擎：它让“防火墙应该只允许 X”变成了一种你在每次变更后都能证明的事实。通过 Nmap 网络验证课程将此循环养成习惯——该网站还提供免费的、实操性的 Kali 网络学习路径，专门针对那些宁愿测试基础设施也不愿盲目信任它的 DevOps 工程师。

← 返回新闻列表 / Back to news list