网络安全漏洞隐患排查报告

上周三凌晨两点十七分，网络我盯着终端上那条红色告警记录，安全后背发凉——公司内网一台文件服务器被植入了挖矿程序，漏洞CPU占用率飙到97%，隐患而它已经在后台悄悄运行了至少11天。排查排查日志发现，报告攻击者用的网络正是三个月前安全通告里就标记过的Apache Shiro反序列化漏洞。没人打补丁，安全因为“业务系统不能随便重启”。漏洞

这不是隐患孤例。过去一个月，排查我们对集团下属7家子公司做了漏洞隐患排查，报告共发现高危漏洞23个，网络中危41个。安全最讽刺的漏洞是，其中6个漏洞在厂商发布补丁后超过180天仍未修复。安全部门不是没催过，但运维同事的回复几乎一致：“等下次停机窗口再说。”可下次窗口往往要等业务淡季，而攻击者从不看日历。

排查过程中有个细节让我印象深刻。某子公司的OA系统，管理员账号密码是“Admin@123”，且开启了远程登录权限。问负责人，他说“这是供应商交付时设的，一直没改过”。我们尝试用这个密码登录，三秒就进去了——系统里还躺着近五年的人事合同和工资明细。这哪是漏洞，这是把家门钥匙挂在门框上。

另一个常见问题出在第三方组件上。研发团队为了赶进度，普遍喜欢从开源仓库直接拉依赖包，但很少有人追踪这些组件的版本更新。我们扫描了一个内部CRM系统，发现它引用的某个日志库存在目录穿越漏洞，而修复版本在漏洞公开后两周就发布了。开发组长一脸茫然：“我们根本不知道用了这个库。”——工具链的可见性缺失，比漏洞本身更致命。

当然，也有做得好的地方。一家子公司的安全负责人自己写了脚本，每天凌晨自动检查所有服务器的补丁状态，并在内部群推送提醒。他们的漏洞数量是全集团最少的，而且连续两次排查都未发现持久化后门。问其经验，他说“没什么窍门，就是把补丁当日常保洁，别等脏了再扫”。这话糙，但理不糙。

这次排查还暴露了流程上的断裂。安全团队发现漏洞后，会提交工单给运维，但工单系统里没有“是否影响业务连续性”这个字段，导致运维无法评估能否立即修复。于是很多高危漏洞卡在“待评估”状态，一卡就是几个月。后来我们建议加了个简单选项：“可离线修复”或“需在线热补”，流程通畅了不少。技术问题，往往最后是管理问题。

最让我睡不着觉的，是一个边界路由器上的弱口令。那台设备是供应商远程维护用的，密码是厂商默认的，而且开放了SSH端口。如果被攻破，整个内网流量都能被劫持。我们当场改了密码并限制了源IP，但没人能保证其他分公司没有类似“后门”。排查报告写得再厚，也不如连夜改掉一个密码来得实在。

隐患清单打印出来有三页纸，但核心问题就一句话：我们总在假设攻击者不会来，而他们赌的就是我们懒得动手。修复漏洞不需要天才，只需要在没人看的时候，把该拧的螺丝拧紧。下个月复查，我打算直接登录那些设备看看——别到时候又发现，报告躺在邮件里，而漏洞还醒着。