处置网络安全漏洞和网络安全事件

凌晨三点，手机突然开始震动。网络运维群里弹出一条告警：某台对外API服务器CPU飙到98%，安全出站流量异常。漏洞络安点开监控图，和网一条几乎垂直的全事曲线——典型的挖矿木马特征。这是处置上周我亲身经历的事。从发现到清除，网络我们用了不到四十分钟，安全但复盘时发现，漏洞络安漏洞早在半年前就存在：一个未授权的和网Redis实例，暴露在公网，全事没设密码。处置

处置漏洞和处置事件，网络是安全两件事，但大多数人把它们混为一谈。漏洞是“门没锁”，事件是“有人已经进屋翻东西了”。门没锁的时候，你还有时间决定是换锁还是先拿东西堵住。有人进屋了，你就得先考虑人还在不在屋里、丢了什么、他还会不会回来。

先说漏洞处置。很多人一听到“漏洞”两个字，第一反应是打补丁。但补丁不是万能的。去年某大型企业内网爆发漏洞，IT部门连夜打了三百多台服务器的补丁，结果业务系统崩了——因为补丁和某个老旧的中间件不兼容。漏洞处置的第一步不是修，是评估。这个漏洞暴露在哪个网络区域？攻击面多大？有没有临时缓解措施？比如那个Redis未授权漏洞，你完全可以先用防火墙限制源IP，再慢慢计划升级。别一上来就重启服务，业务中断的代价可能比漏洞本身还大。

漏洞的生命周期管理有个容易被忽略的点：验证。你打了补丁，不代表漏洞就没了。有些补丁需要重启才生效，有些补丁只修复了部分攻击路径。我见过一个案例，管理员给Tomcat打了补丁，但忘了删掉示例目录里的test.jsp，结果攻击者还是能通过那个文件上传webshell。所以修复完必须复测，用扫描器或者手工验证，别信“应该好了”。

再说事件处置。事件来了，第一件事不是分析，是遏制。拔网线、封IP、禁用账号，先把血止住。我见过一个新手工程师，发现webshell后兴奋地开始分析代码，结果攻击者还在线上，眼睁睁看着他把数据库拖走了。遏制之后才是取证和清除。取证要注意顺序：内存里的进程、网络连接、临时文件，这些易失性数据优先保存。硬盘可以慢慢做镜像，但内存一断电就没了。

清除阶段最怕的是“留一手”。攻击者往往不止一个后门。你删了webshell，可能还有计划任务、隐藏账号、SSH公钥。我习惯的做法是：对照入侵时间线，把那个时间段内所有新增的文件、账号、服务、计划任务全部列出来，一个一个排查。别嫌麻烦，漏掉一个等于白干。

恢复阶段有个坑：很多人直接从备份恢复，但备份里可能已经包含了攻击者的后门。所以恢复之前，先确认备份的时间点早于入侵时间。如果做不到，那就只能从干净的系统重装，再手动迁移数据。慢，但安全。

最后说点个人观察。很多团队把漏洞管理和事件响应分成两个组，漏洞组只管扫和修，事件组只管应急。结果漏洞组扫出来的高危漏洞，事件组根本不知道；事件组发现的新攻击手法，漏洞组也没反馈到扫描规则里。这俩应该是一个闭环。每次事件处置完，必须回头问一句：这个入口是怎么进来的？对应的漏洞为什么没提前发现？扫描策略要不要调整？

还有个现实问题：人。处置漏洞和事件，最终靠的是人。工具再好，半夜三点能爬起来看告警、能冷静判断先封IP还是先备份的人，才是关键。我见过太多团队买了昂贵的SOAR平台，结果告警一多就没人看了。流程可以自动化，但决策不能。至少目前不能。

那台被挖矿的服务器，最后我们不仅清了木马，还顺手把整个VPC的安全组规则重写了一遍。Redis加了密码，绑了内网，监控加了连接数告警。四十分钟的应急，换来的是后面半年没再出过类似的事。值了。