网络系统漏洞整改报告

上周三凌晨两点，网络运维群里弹出一条告警：某台对外业务服务器CPU飙到100%，系统持续了十七分钟。漏洞值班同事以为是整改正常流量高峰，没太在意。报告第二天上午安全扫描结果出来，网络那台机器上跑着一个三年前就停止维护的系统Struts2框架，远程命令执行漏洞被利用，漏洞攻击者已经留了后门。整改这事儿不复杂，报告但足够典型——一个早就该消失的网络旧组件，因为没人记得它还在跑，系统差点把整个内网拖下水。漏洞

漏洞本身没什么好说的整改，CVE编号一查就有，报告补丁两年前就发了。问题出在资产台账上。这台服务器登记的是“测试环境-已停用”，实际却连着生产数据库。运维换过两拨人，交接文档里压根没提这茬。我们后来翻监控记录，发现它已经连续运行了四百多天，中间重启过一次，还是因为机房空调故障。没人登录，没人更新，也没人关掉。它就那么安静地跑着，直到被扫到。

整改第一步不是打补丁，是先把所有“幽灵资产”揪出来。我们用了三天时间，把全网段做了一次主动探测加流量镜像分析。结果比预想的多——十七台机器处于“三不管”状态：资产系统里标记为下线，交换机端口却亮着；或者IP归属某个已解散的项目组，但服务还在监听端口。其中五台跑着Windows Server 2008，两台还在用SSHv1协议。这些机器有个共同点：没人认领。问谁谁都说“不是我负责的”，但真要去关停，又有人跳出来说“那个服务好像还在用”。

这种扯皮在整改里最耗时间。我的做法是先隔离，再确认，最后处理。隔离就是把这些机器从核心网络里划出去，单独放一个VLAN，只允许跳板机访问。确认环节拉上业务方一起看流量——如果连续三天没有正常业务请求，直接关机；有请求的，问清楚谁在用，限期迁移或升级。那台Struts2服务器就是关机后第二天，有个外包团队打电话来问“怎么连不上了”，我们才知道他们还在用它跑一个报表导出任务。让他们改用新接口，对方一开始嫌麻烦，直到我们把攻击者留下的webshell截图发过去，他们才闭嘴。

补丁管理这块，我观察到一个挺普遍的现象：大家喜欢打“大补丁”，就是那种月度累积更新，一次性推几百兆。但真正被利用的漏洞，往往藏在某个不起眼的组件里。比如这次事件之后，我们专门查了所有Java应用，发现七个系统还在用log4j 1.x。这玩意儿早就不维护了，但因为它藏在某个老jar包里，平时没人注意。我的建议是，别光看操作系统补丁，把中间件、框架、第三方库都列出来，按“是否直接暴露”“是否有已知EXP”“是否还在维护”三个维度打分，优先处理那些“既暴露又没补丁”的。

访问控制这块也有得聊。那台被攻破的服务器，SSH端口对全网开放，密码是八个数字。攻击者根本没用什么高级手法，就是爆破进去的。我们后来强制所有Linux机器改用密钥登录，禁用密码认证，同时把22端口限制到跳板机。Windows那边开了RDP的，全部加网络级认证，再套一层VPN。有人抱怨麻烦，我说你嫌麻烦可以，写个申请单，说明为什么必须对公网开放，我帮你走审批。到现在没人写。

整改报告写到这儿，其实核心就一句话：漏洞从来不是技术问题，是人的问题。没人认领的资产、没人看的日志、没人管的旧组件，才是真正的风险点。我们最后列了个清单，十七台幽灵资产里，关停九台，迁移五台，剩下三台实在动不了的，加了微隔离策略，只允许特定IP访问特定端口。那个Struts2服务器直接格式化了，硬盘留着当证据。后门样本送去做溯源，发现攻击者是从一个东欧IP进来的，用的工具包是网上随便下的。挺讽刺的——我们花几十万买的WAF没拦住，因为流量根本没走WAF，那台机器压根不在防护范围里。

现在每周五下午，我会花半小时翻一遍资产变更记录和漏洞扫描报告。没什么技术含量，就是看看有没有新冒出来的“孤儿机器”，或者哪个漏洞连续三周没修。这活儿枯燥，但比半夜被叫起来应急强。上次那个外包团队后来请我们吃了顿饭，说报表导出任务已经迁到新平台了，速度还快了不少。我说你们早该迁了。他们笑笑，说这不是没人催嘛。

很赞哦!（5528）