昨晚凌晨两点，网络我收到一条服务器告警短信。安全登录后台一看，漏洞某个旧项目的自查后台登录接口在十分钟内被尝试了四千多次——全是同一个IP段，密码字典撞库。网络还好当初给管理员账号加了二次验证，安全不然这会儿我可能已经在写事故报告了。漏洞这不是自查第一次了，上次有个客户的网络小型电商站，就是安全因为后台密码是"admin123"，被拖库后直接挂在了暗网上标价出售。漏洞

这类事见多了，自查我发现大多数漏洞根本不是网络什么高深黑客技术，纯粹是安全懒和侥幸。拿最常见的漏洞SQL注入来说，很多开发者写查询语句还是用字符串拼接，明明预处理参数就几行代码的事。我见过一个做了五年的老系统，登录框输入`' or '1'='1`就直接进后台了——那感觉就像你家大门钥匙插在锁孔里，小偷只需要转一下。

自查的第一步，先把所有默认口令和弱口令清掉。别觉得"我们公司小没人盯上"，黑客扫描工具是全网扫的，不看你公司大小，只看你技术栈有没有已知漏洞。具体做法很简单：把所有系统管理员账号列个清单，逐个试密码，凡是小于12位、不含大小写数字符号组合的，全部强制重置。这个动作花不了半小时，但能挡掉至少六成的撞库攻击。

第二步查暴露面。用Nmap或者在线端口扫描工具扫一遍你的公网IP，看看是不是有不该对外开放的端口。我见过最离谱的案例，某公司把MySQL的3306端口直接暴露在公网上，数据库连密码都没设。扫描器一抓一个准，数据就像放在马路边上的快递盒，谁路过都能拿走。正常情况，数据库端口只该内网访问，远程管理走VPN或者跳板机。

第三步看补丁更新。别笑，很多系统上线后就没再更新过。去年Log4j爆出远程代码执行漏洞的时候，我帮朋友排查他们公司的Java应用，发现有个三年前部署的老服务还在用Log4j 1.x版本，压根没修。问运维，说"能跑就不动"。结果那个漏洞的利用工具在GitHub上公开当天，就有扫描器开始全网探测。补丁这事，等出了事再打就晚了，平时得每月固定时间检查依赖库和中间件版本。

最后查日志。别指望日志能防攻击，但它能告诉你已经被打了多少次、从哪里打的。建议至少保留90天的访问日志，重点看登录失败记录和异常请求路径。我习惯每周五下午花十五分钟翻一遍，看到规律性的扫描痕迹就顺手把来源IP加进防火墙黑名单。这招不复杂，但能让你对自己的系统状态有个底。

说到底，自查不是应付检查的纸面工作。你花一个下午把这几项过一遍，比买一堆昂贵的安全设备都管用。安全这东西，七分靠习惯，三分靠工具。别等被黑了才想起来补窟窿，那时候的代价就不是一个下午能解决的了。