去年年底接了一个运维外包，客户手里有 12 台老服务器，Windows 和 Linux 混着跑，都是前两任留下的，没人说得清每台机器上到底有哪些服务在对外提供服务。老板只问了我一个问题：这堆机器到底安不安全。我没有直接上漏洞扫描，而是先做了一件事用 Nmap 把这 12 台机器的端口全扫了一遍。结果 38 个端口对外开着，其中 11 个对应的服务早就没人用了，只是配置还留在那儿，进程也还在跑。11 个，多出来的攻击面，谁也说不清什么时候会被人盯上。
想先把扫描工具装上跑起来的，可以看看这两个：狗云DOGYUN（高性价比云服务器，多机房可选）、RackNerd（全球VPS，特价常推）。如果你打算搭一台专门的扫描机，建议 CPU 至少 4 核、内存 8G 以上，硬盘留够 50GNessus 的插件库和扫描结果缓存都很吃空间，我第一次用默认配置装，插件同步直接把系统盘撑到只剩 3G。
先说一句大实话：漏洞扫描不是万能药，它只是帮你把「不知道有哪些问题」变成「知道有哪些问题」，剩下的活还得靠人判断和动手。下面这套流程我在这批机器上完整走了一遍，从端口盘点到漏洞分级再到逐项收敛，中间踩的坑也都写出来了。如果你手上也有一堆没人敢保证安全的老机器，可以照着这个顺序做，比一上来就装扫描器然后对着几百条告警发懵要省事得多。
一、第一步不是扫漏洞，是盘点端口
大部分人一听到「安全检查」，第一反应就是打开 Nessus 点一下「开始扫描」，然后对着报告发呆。我一开始也是这么干的，结果 Nessus 跑了 4 个小时，出来 300 多条告警，高危 47 条，每条都写着「建议尽快修复」。看完更慌了，因为根本不知道哪条是真要命、哪条是误报。
后来我改了顺序，先做端口盘点。这一步花的时间不到一小时，但它决定了后面所有工作的方向。端口是攻击面的入口，一个服务器上对外开着什么端口，就等于门上有几个洞。
最基础的命令谁都敲得出来：
nmap -sV -sC -Pn -T4 192.168.1.0/24 -oN /tmp/scan.txt
这几个参数我解释一下。-sV 是服务版本探测，能识别出 22 端口跑的是 OpenSSH 8.4p1 还是 7.4 这种差别，这一步很关键，因为同一个服务不同版本的默认配置和已知漏洞完全不一样。-sC 是默认脚本集，会顺手做一堆基础的协议探测。-Pn 是跳过 ping 探测这一步我踩过坑，有几台机器禁了 ICMP，不加这个参数 Nmap 会认为主机不在线，直接跳过，等于什么都没扫。
-T4 是把时序模板调到偏 aggressive 那一档，扫描快一点。这个是权衡：调太慢扫一天，调太快对方可能触发 IDS 告警，也可能被限速导致漏扫。我一般用 T4，如果扫的是核心生产网，会降到 T3。
扫完先看一个东西：每个端口对应的是哪个进程。这一步千万别跳过。Nmap 是从外面「敲」门，它看到的是端口开了，但不知道门后面是什么。所以我会把结果跟服务器内部的 ss -tulpn 或 netstat -tulpn 输出对照起来看。
我那 11 个没人用的端口，就是这么找出的。从外面看 22、3306、6379、9200 全开着，进去一查：3306 那个 MySQL 早就迁到 RDS 去了，本机只留了个没删干净的 mysqld 残留实例；6379 的 Redis 是上个运维临时装来做测试的，数据早就迁走了，进程还在那空转；9200 是换 Elasticsearch 时留下的，服务停了三台了，配置却还在。这几个端口对应的进程防火墙规则一查，还全都放行着对外访问。
换句话说，这些服务没有价值，但它们带来的风险是真的。这就是「攻击面收敛」的意思：不是打补丁把漏洞补上，而是把没用的门直接拆掉，风险自然降一大截。
二、端口盘点表怎么填，才不会白干
我给自己定的规矩是：每个对外端口都必须在表里有一行，写清楚四件事这个端口是干什么用的、谁在用、要不要保留、不保留的话什么时候关。少一行都不行。
为什么要这么死板？因为收敛端口这件事，最容易出的岔子不是技术问题，是「我不知道这个端口是谁加的，也不敢关」。一张写清楚的表能解决两个问题：一是下次交接的时候，别人看得懂；二是在关端口之前，你能回头确认这个服务真的没有业务在依赖。
关端口之前，我一般做三件确认工作。
第一，确认没有人在用。看连接的 established 状态，看业务日志里有没有指向这个端口的请求，看近三个月的慢查询日志或者访问日志里有没有相关记录。光是「我印象里没人用」不算数，必须有证据。
第二，确认关掉不影响别的东西。最典型的翻车场景是关掉了自己正在用的 SSH 端口。我第一次做端口收敛的时候，就是在批量关端口的脚本里把 22 也写进去了，执行到第三台的时候脚本因为前面的超时卡住了没返回，我以为没执行到，手动敲命令连了一下自己的机器，直接连不上。还好那台机器有 IPMI 带外管理能进去救，否则就是给自己制造了一场事故。
从那以后我养成了一个习惯：任何批量关端口的操作，先在预生产环境跑一遍，再用带确认的单步脚本在生产上做，绝不写那种一条命令直接改防火墙的批处理。看起来慢，但慢的是你，不是业务。
第三，先从内网限制，再从外网关闭。顺序也很重要。直接 DROP 掉规则，出了问题你连回退都难。更稳的做法是先在安全组或者防火墙里加一条限制来源的规则（只允许内网网段或者特定 IP 访问），观察一两天，确认没有业务报错，再改成完全关闭。灰度思路，任何涉及线上可访问性的变更都该这么干。
三、Nessus 扫出来的漏洞，怎么分出轻重
端口收敛完，剩下的就是真需要处理的服务了。这时候再上 Nessus，报告才有意义因为你已经把那些没用的噪音服务清掉了，剩下的告警是真正跑在业务上的东西。
Nessus 出的报告不能只看一个「High」就慌。它给的是 CVSS 基础分和向量串，要结合实际情况判断。我自己用的判断顺序是三个问题：
一，这个服务是对外暴露的，还是只在内部？同样一个 OpenSSH 的中危漏洞，如果只监听 127.0.0.1，那它的实际风险几乎为零；如果监听 0.0.0.0 且安全组放行了全网，那就是另一回事了。CVSS 是按最坏情况算的，实际暴露面得你自己核。这是我筛掉最多假警报的一步。
二，有没有前置条件？很多高危漏洞是有利用前提的，比如需要本地权限、需要用户先点一个链接、需要特定配置开启。这些在「可利用性」维度上会低一档。我那 47 条高危里，真正需要停机打补丁的只有 6 条不是它只报了 6 条高危，而是另外 41 条要么是只监听本地，要么是那个特性压根没开，要么是同系列产品的误报匹配。
三，这个补丁打上去会不会影响业务？这一步才是运维最纠结的。大版本升级意味着可能不兼容、会重启服务、会改配置。实际操作上我一般优先打「仅安全补丁、不带功能变更」的版本，这种补丁出问题的概率低得多。真要升大版本，我会先在同配置的测试机上跑一轮业务回归用例。
还有个实操细节：先在扫描机上更新插件库再扫。Nessus 的插件几乎每天更新，不更新的话你扫的是漏洞库半年前的版本，那份「干净」的报告是假的。我第一次扫完报告显示只有 12 个漏洞，开心了没两天，同一台机器用新插件重扫，出来 31 个。原因是那台机器上的 OpenSSL 版本被误判了，新插件把它识别对了。
四、扫完之后，怎么让它不白扫
这批 12 台机器，我前后花了两个周末。第一轮扫描加收敛跑完，直接开着的对外端口从 38 个降到 19 个，Nessus 的高危从 47 条降到 6 条，剩下 6 条里有 4 条打了补丁，2 条因为是业务依赖的老版本，只能靠 WAF 规则和前置代理挡着，走计划下线。
但比结果更重要的是后面这一步：把扫描变成周期性的，而不是一次性运动。我给这批机器定了一个规矩每周日凌晨低峰期跑一次增量扫描，端口列表和上次的对比，有新增端口立刻告警。这条规矩上线一个月后，它自己抓出来过一次问题：有个同事为了调试把 Redis 的 6379 端口临时对全网放开了，开完自己忘了关。端口对比脚本当晚就报了新增，凌晨两点给我发消息。
这种「一周一次就能抓到」的机会，靠人力是不可能做到的。这就是自动化的价值所在。
如果你也打算把这套东西落地，我建议按这个顺序推进：先做端口盘点（半天就能出全貌），再做服务识别和冗余清理（这部分收益最大、风险最低），然后才上漏洞扫描和补丁管理（最花时间，也最容易因为业务约束卡住）。别一上来就追求「把所有漏洞清零」，那是不切实际的，也容易在推进过程中把业务搞挂而半途而废。
最后补一个安全提醒：扫描器扫自己所在的网段时，注意别把扫描机自己给搞挂。我见过有人写了个自动化脚本，扫到某台机器时发现 22 端口开放就顺手执行了什么「修复」动作，结果那台机器上的 SSH 服务被重启，脚本的连接直接断掉。扫描归扫描，变更归变更，这两件事最好物理隔离扫描用只读账号跑，变更走单独的审批流程。
喜欢 
顶
难过
囧
围观
无聊
