内容摘要：上周三凌晨两点，我们运维组被一阵急促的告警声吵醒。某台对外服务的边缘节点CPU飙到98%，流量曲线像被人拽着头发往上提。排查了四十分钟，最后定位到一个老旧的Struts2接口——半年前就该下线，结果因

上周三凌晨两点，网络我们运维组被一阵急促的安全告警声吵醒。某台对外服务的漏洞边缘节点CPU飙到98%，流量曲线像被人拽着头发往上提。排查排查了四十分钟，总结最后定位到一个老旧的网络Struts2接口——半年前就该下线，结果因为某个内部系统还在调用，安全一直挂着。漏洞攻击者利用OGNL表达式注入，排查已经拿到了服务器权限，总结正在往外拖数据库备份文件。网络

这事不新鲜。安全但每次都是漏洞出了事才回头翻日志，翻完发现漏洞早就在那儿躺着。排查我干这行七年，总结真正靠主动扫描提前拦住的攻击，比例不到三成。剩下的，要么是运气好被WAF挡了，要么就是像这次一样，半夜爬起来擦屁股。

说说我们这轮排查的具体做法。没用什么高大上的平台，就是三件事：资产清点、流量抓包、人工验证。

资产清点最枯燥，也最要命。我们组四个人，花了整整一周，把公司所有公网IP段跑了一遍nmap，再对照CMDB和云厂商的API，最后整理出一份清单。结果发现有23台机器不在任何台账里——有的是测试环境忘了关，有的是离职同事自己开的云主机，还有两台是外包团队偷偷部署的爬虫节点。这些机器上跑的什么版本、有没有打补丁，没人知道。其中一台Redis直接监听0.0.0.0，连密码都没设。

流量抓包这块，我们在核心交换机上做了端口镜像，用Zeek跑了三天。重点看两种东西：一是异常的外连请求，比如内网机器往陌生境外IP发大量数据；二是HTTP请求里带奇怪参数的。还真抓到几条有意思的——有个后台接口的file参数，传../../../../etc/passwd居然返回了文件内容。开发说这接口是内部用的，没做鉴权。内部个鬼，公网能直接访问。

人工验证是最花时间的。扫描器报出来的漏洞，误报率大概四成。比如某个Spring Boot Actuator端点，扫描器说存在敏感信息泄露，实际去看，返回的是{ "status":"UP"}，没任何危害。但另一个扫描器没报的——一个GraphQL接口，允许未授权查询用户手机号和邮箱——是我们手工测出来的。扫描器不认识GraphQL的查询语法，直接跳过了。

这轮排查一共确认了17个真实漏洞。按危险程度排：3个RCE，2个SQL注入，4个未授权访问，剩下的都是信息泄露和配置错误。RCE里有一个是Jenkins的CVE-2024-23897，攻击者能读任意文件；另一个是某国产OA系统的前台文件上传，传个jsp就能拿shell。这两个的补丁其实早就发布了，但没人去升级。问就是“业务不能停”、“等下次发版”。

我的判断很直接：漏洞排查不是技术问题，是管理问题。你工具再强，流程再顺，只要开发、运维、安全三方各管各的，就永远在救火。我们后来定了个规矩——每周三下午，开发负责人和安全组一起过一遍新暴露的资产和未修复的漏洞。谁不来的，下周他的服务上线前必须做渗透测试，费用自己扛。执行两个月，漏洞平均修复时间从21天降到了6天。

还有个细节值得说。我们内部有个漏洞提交平台，以前提一个漏洞奖励50块，没人提。后来改成：提一个有效漏洞，奖励200块，并且当月绩效加0.5分。结果一周内收到40多条提交，其中12个是真实漏洞。有个实习生甚至发现了我们都没注意到的SSRF——某个图片加载接口，传内网地址能探测端口。钱不多，但让每个人都开始留意身边的东西。

排查完了，报告写了，漏洞修了。但我知道，下个月还会有新的。这行就这样，没有一劳永逸。能做的是把周期缩短，把响应变快，把责任落到具体的人头上。凌晨两点被叫醒的滋味，我实在不想再尝了。