我上周把公司内部服务器的漏洞SSH端口从22改成了22022，以为能躲过扫描。自查结果第二天日志里躺着三千多次暴力破解尝试——全是报告冲着22022来的。改端口没用，漏洞真正的自查漏洞从来不在你藏的地方，而在你忽略的报告地方。

这次自查从最基础的漏洞开始。我拉出所有服务器的自查登录日志，筛出过去三十天的报告失败尝试。不看不知道，漏洞有一台测试机居然开着root密码登录，自查密码是报告"123456"。这台机器挂着公司官网的漏洞数据库备份脚本，每天凌晨三点自动跑。自查你说它危险吗？报告它连公网IP都没有，只在内网。可内网就安全吗？隔壁部门的人都能ping通它。我当场把root登录关了，顺手改了密码。这种漏洞不查不知道，一查吓一跳。

接着查第三方组件。公司用的CMS系统有个插件，去年就爆出SQL注入漏洞，官方早就出了补丁。我一看版本号，还是半年前的。问运维，他说"没人提过要更新"。不是他懒，是流程里根本没这一环。我花了两小时把所有插件过了一遍，三个高危漏洞，两个中危。其中一个能让攻击者直接上传恶意文件。想想都后怕，要是被利用了，整个后台就是人家的后花园。

然后看配置。Nginx的配置文件里有条规则，把/admin路径的访问IP限制写错了，写成192.168.1.0/24，实际公司网段是192.168.2.0/24。等于这个限制形同虚设，谁都能访问后台登录页。更离谱的是，后台登录没有加验证码，也没有失败次数锁定。我试了试，用密码字典跑了五分钟，还真试出了一个弱口令。赶紧改了密码，加了双因素认证。这种错误，纯粹是粗心，但造成的后果跟恶意攻击没两样。

最后检查备份。我们的备份策略是每周全量，每天增量，存在同一台物理服务器的另一块硬盘上。这等于没备份——要是服务器被勒索病毒加密，备份一起遭殃。我建议把备份异地同步一份，哪怕放到对象存储上，成本也不高。但这事得老板拍板，我写进报告里，标注了"建议优先处理"。

整个自查花了四天，发现的问题列了满满两页A4纸。大部分不是什么高深的技术漏洞，而是懒惰、疏忽和流程缺失。最讽刺的是，我最初想防的外部攻击，其实防火墙挡得挺好。真正的风险全在内部——没人管的测试机、不更新的插件、写错的IP段、形同虚设的登录保护。

漏洞自查报告写到最后，我加了一句个人建议：别老想着跟黑客斗智斗勇，先把自家后门锁好。这话不好听，但管用。