Nmap 生产落地案例

五、生产落地案例

说明：以下案例均为在自有网络或已获书面授权的目标上开展的工作，仅作方法参考。

案例一：企业内网资产盘点与暴露面收敛。背景是一家企业的内网经过多年演进，资产台账与实际部署严重脱节，存在大量"没人知道是谁开的"服务端口。做法是先由网络管理方出具书面确认，明确扫描范围为公司内网几个网段、时间窗口为周末夜间；扫描分三步走，先用主机发现建立在线资产基线，再对在线主机做常见端口的服务识别，最后只对确认为关键业务的主机做全端口扫描。关键配置上，全程使用 -T3 到 -T4 的保守速率、脚本只用 safe 与 discovery 类、输出统一用 -oA 保存三种格式，并在扫描前把扫描源 IP 报备给安全团队。效果是梳理出了一批台账之外的服务，收敛了一批不必要的暴露面，并把扫描脚本固化成了每季度执行的例行任务。踩到的坑有三个：一是首轮扫描用了较快的时序模板，在跨网段链路上丢包严重，把若干实际开放的端口误判为 filtered，后来降低速率重扫才得到准确结果；二是发现有若干设备对版本探测请求异常敏感、出现过短暂无响应，之后把这些设备加入排除清单并改为人工核查；三是初期没有保留 XML 输出，导致后续想做资产变更对比时无据可依，此后把"每次扫描必须 -oA 落盘并按日期归档"写进了流程。

案例二：上线前的授权安全测试中的端口与服务梳理。背景是一个自有系统在新机房部署完成，需要在正式对外提供服务前做一次安全核查，授权文件明确了目标网段、测试时间与允许的测试手法。做法是先用 Nmap 对目标主机做端口与服务识别，产出暴露面清单，再把清单交给后续的漏洞验证环节做针对性检查；同时用 NSE 的 safe 类脚本检查 TLS 证书与常见配置问题。关键配置上，明确不使用 brute 与 intrusive 类脚本，扫描速率设为保守值，避免影响尚未上线的服务；扫描结果保留 XML 以便与上线后的状态做对比。效果是发现了若干不该对外开放的服务端口与若干证书配置问题，在上线前完成整改。踩到的坑有两个：一是有一台设备的管理端口只对特定源地址开放，从扫描机看不到，导致初次盘点漏掉了它，后来通过从多个网段分别扫描并交叉核对才补齐；二是初期的扫描报告只记录了"开放了什么"，没有记录"应该开放什么"，导致整改阶段无法判断哪些是多余的，此后把"预期开放清单"作为扫描的前置输入，扫描输出与预期清单做差集，整改目标就非常清晰。

这两个案例的经验可以归纳成一条工作方法：把 Nmap 的扫描结果与"预期的资产与端口清单"做差集，而不是只看扫描结果本身。只列出现状，报告的读者无法判断什么是问题；只有和预期做对比，才能直接得到需要处置的清单。配套的三件事是——书面的授权与明确的范围文件、保守的扫描速率与安全的脚本分类、以及按日期归档的 XML 原始数据。