网络漏洞修复整改报告

上周五下午三点十七分，网络运维群炸了。漏洞监控系统弹出红色告警——我们对外业务的修复API网关被扫描出Apache Log4j2远程代码执行漏洞（CVE-2021-44228）。这不是整改那个已经公开半年的老洞吗？我盯着屏幕愣了两秒，然后骂了一句脏话。报告漏洞扫描器在凌晨就发现了异常流量，网络但值班同事把它当成了误报，漏洞直接忽略了。修复

问题出在内部测试环境。整改有个新入职的报告工程师为了赶项目进度，从Maven仓库拉了一个旧版依赖包，网络里面带着log4j-core-2.14.1。漏洞开发机连着内网，修复但测试环境绑定了公网IP做演示用——就这么个巧合，整改把老漏洞暴露了出去。报告扫描日志显示，攻击者尝试了三次构造恶意JNDI注入请求，都被WAF拦截了，但漏洞本身是实打实存在的。

修复动作分三步走。第一步，切断暴露面。当晚九点，我们把测试环境从公网摘除，改为仅限公司VPN访问。这个操作花了四十分钟，因为要同步修改DNS解析和防火墙规则，中间还误伤了两个正常使用的内部系统——运维同事在改策略时把端口范围写窄了，导致财务部的报销系统连不上数据库。好在财务同事已经下班，否则又是一场跨部门口水战。

第二步，彻底清理依赖。我们没直接升级到最新版log4j，而是让开发组把项目里所有用到日志组件的代码全部改成了log4j-to-slf4j桥接，底层换成Logback。这个决定有点激进，但考虑到log4j后续被曝出的多个CVE，与其反复打补丁，不如直接换掉底层实现。代码迁移花了三天，期间测试环境一直处于锁定状态，业务方催了两次，我们顶住了压力。

第三步，建立漏洞响应SOP。这次事故暴露出的最大问题不是技术，是流程。扫描器报警没人复核，值班手册里只写了“告警升级条件”没写“忽略条件”。我们重新梳理了告警分级规则，把“公网可达资产上的高危漏洞”从P2级调高到P0级，并且强制要求所有漏洞告警必须在2小时内有人工确认记录，哪怕是误报也要写理由。另外，新入职员工的开发环境现在默认走代理，禁止直接访问外网Maven仓库，所有依赖统一从内部私服拉取。

整个整改从发现问题到完全闭环用了六天。最后一天复查时，我们重新跑了全量扫描，漏洞列表清零。但说实话，没有人觉得轻松——这次运气好，攻击请求被WAF挡住了，如果对方用的是加密流量绕过检测，后果不敢想。我后来跟那个拉错依赖的新同事聊过，他当时脸都白了，说自己在学校做项目时都是随便从网上拷代码，没人管这些。这让我意识到，光靠制度约束不够，得让每个写代码的人脑子里都绷根弦。现在我们每周五下午有个半小时的安全分享会，不讲大道理，就复盘本周遇到的真实案例，谁踩坑谁来讲。

漏洞修复从来不是打个补丁就完事。真正的整改，改的是人处理信息的方式，是团队对风险的本能反应。下次再看到扫描器弹告警，我希望第一反应不是“是不是误报”，而是“万一是真的呢”。