关于开展网络安全漏洞排查和整改的情况

上个月做了一次内部扫描，关于改结果挺意外。开展一个对外测试环境里跑着三年前的网络老版本Nginx，配置文件里还留着测试用的安全弱口令，访问日志显示有人从境外IP尝试过路径遍历。漏洞这事没上报，排查也没人管，和整直到扫描器把告警推到我面前。情况

类似的关于改情况不止一处。我们这次排查覆盖了公司全部对外暴露的开展资产，包括Web服务、网络API网关、安全VPN入口和几个边缘节点。漏洞用的排查工具不复杂——Nmap做端口发现，Nessus扫已知漏洞，和整加上手工验证。真正花时间的是梳理资产清单，很多服务上线时登记的信息早就过期了，运维换了几拨人，文档没跟上。

漏洞数量按严重级别分了四档。高危的有六个，主要集中在未授权访问和SQL注入。其中一个后台管理接口可以直接绕过登录，用构造的Cookie拿到管理员权限。这个接口是两年前一个外包团队留下的，代码没进主仓库，部署脚本也没记录。发现它纯属运气——扫描器碰巧命中了路径字典里的一个冷门目录。

中危漏洞二十多个，大多是信息泄露和配置错误。比如某个内部服务的Swagger文档没关，接口参数和返回结构全暴露在外。还有几个服务开了CORS通配符，配合XSS可以窃取用户Token。这些漏洞单看危害有限，但组合起来能形成完整攻击链。我试着串了一条：从信息泄露拿到接口结构，利用未授权接口写入恶意数据，再通过CORS把数据外带。整个过程不需要任何0day。

整改分了两条线走。能立即修的，比如关掉调试接口、加固Nginx配置、更新依赖库版本，当天就推了热修复。需要改代码的，比如那个后台鉴权逻辑，走了紧急变更流程，三天内上线。剩下几个涉及架构调整的，比如VPN的认证方式从静态密码换成证书加动态令牌，排了两周的计划。

有个细节值得记一笔。修复过程中发现，部分漏洞其实早就有内部员工在非正式渠道提过，但没走工单系统，也没人跟进。信息在聊天记录里沉底了。这次排查后我们定了个规矩：任何安全相关的反馈，无论大小，必须开Ticket，有编号，有负责人，有截止时间。不依赖个人记忆，也不靠“下次注意”这种空话。

外部攻击面收敛了不少。原来暴露在公网的37个端口，现在只留了必要的12个。其余要么走内网跳板，要么加了IP白名单。扫描频率也从季度改成月度，关键资产每周扫一次。误报还是有的，但比漏报强。

回头想，这次排查最大的收获不是修了多少漏洞，而是把资产台账和变更流程重新拉了一遍。很多安全问题本质上是管理问题——不知道有什么，不知道谁在管，不知道改过什么。工具能扫出漏洞，但扫不出流程漏洞。那部分得靠人盯，靠制度卡。

下一步打算把扫描集成到CI/CD里，代码合并前自动跑一遍依赖检查和静态分析。另外在推动日志集中采集，现在各服务的日志格式不统一，出事了查起来费劲。这些事不新鲜，但得有人做。不做，下次扫描还是能扫出一堆“历史遗留”。