内容摘要：网络安全风险排查整改情况报告 3月17日凌晨两点，运维值班同事被一条告警电话叫醒——对外服务的订单查询接口在十分钟内出现了大量异常返回，状态码以500为主，夹杂部分200但响应体为空。起初以为是数据库

网络安全风险排查整改情况报告

3月17日凌晨两点，网络运维值班同事被一条告警电话叫醒——对外服务的安全订单查询接口在十分钟内出现了大量异常返回，状态码以500为主，风险夹杂部分200但响应体为空。排查起初以为是整改数据库连接池被打满，排查后发现连接数正常，情况慢查询日志也没有明显波动。报告真正的网络问题出在一个边缘节点上：该节点上的WAF规则库已经三个月没更新，攻击者利用一个早已公开的安全SQL注入变种绕过了旧规则，直接把恶意载荷打到了后端。风险

这次事件暴露出一个很实际的排查问题：我们花了大力气在核心机房部署了层层防护，却忽略了边缘节点的整改“保质期”。第二天一早，情况安全团队拉了最近半年的报告资产清单，发现类似“部署后没人管”的网络节点有11个，分布在三个不同的云厂商环境里。其中4个节点的系统补丁停留在去年9月，2个节点的日志采集器已经停止上报超过60天。说白了，不是没有防护，是防护过期了没人知道。

排查工作从资产梳理开始。我们没走常规的“填表上报”路线，而是直接用扫描器对全网段做了一次存活探测，再和CMDB里的记录做比对。结果对不上号的资产有23台，其中7台是测试环境遗留，3台是离职员工未交接的跳板机，剩下的是业务部门自己通过云控制台开的临时实例。这些机器有个共同点：不在任何监控面板上，也没人认领。安全组规则里，22端口对0.0.0.0/0开放的有5台，3306端口对外开放的有2台。有一台甚至跑着Redis，未设密码，bind 0.0.0.0。运维同事看到结果后说了句：“这要是被挖矿的扫到，半天就能把CPU跑满。”

整改没有搞一刀切。对那5台暴露22端口的机器，先确认业务依赖，能关的直接关，不能关的加白名单。Redis那台比较麻烦，业务方说是个内部缓存，但代码里写死了公网IP。临时方案是先加密码并限制来源IP，长期方案是推动业务改配置走内网。补丁方面，对那4台停留去年9月的节点，安排窗口期做了滚动更新，更新前先快照，更新后跑了半小时冒烟测试。日志采集器停掉的2个节点，查下来是磁盘满了导致filebeat挂掉，清理后恢复，顺手加了个磁盘使用率超过85%就告警的规则。

WAF规则库的问题最直接。我们联系了厂商，拿到最新规则包，但发现直接全量更新会影响一个老业务的正常请求——那个业务还在用非常规的URL编码方式。最后是分了两批：先更新边缘节点，观察一天；再更新核心节点，同时给那个老业务加了例外规则。这件事让我意识到，安全设备不是越新越好，得和业务的实际流量特征匹配。盲目追新规则，可能把正常请求也给拦了。

整改过程中还发现一个管理上的漏洞：云控制台的子账号权限太松。有三个离职员工的账号没及时禁用，虽然他们未必有恶意，但账号如果被撞库成功，后果不好说。现在改成了统一走SSO，离职流程里加了一步“安全组确认”。另外，临时实例的创建现在需要审批，不能随便开公网。

到3月25日，所有排查出的高风险项都处理完了。但说实话，这种“出事再查”的模式挺被动的。下一步打算把资产存活探测和基线检查做成周常任务，自动比对差异。WAF规则库的更新也定了周期，每月第一个周三做一次评估。边缘节点不再放养，纳入统一监控。安全这事，靠人盯人迟早出问题，得让系统自己会喊疼。