防撞库不止改密码：3个入口先堵上

撞库这词听着玄乎，拆开看一点都不高级——别人在别处偷到的一批账号密码，拿到你家的门上挨个试一遍，就这么回事。所以防撞库不止改密码：3个入口先堵上，改密码只是事后缝针，被撞的那几扇门还敞着。登录页、找回密码页、接口，这三处漏一处，你把密码改成十八位混符号也照样白搭。

改密码这事，顶多算止血

用户密码改了三遍照样被盗，这种反馈我见得太多。原因很简单，密码本身没问题，是攻击者压根不用猜——他手里有现成的清单，A 站泄露的一批邮箱加密码，拿去 B 站、C 站批量提交。你让用户改成更复杂的密码，只是让这份清单在他这儿失效一次，下一份清单来的时候还是照撞。真正的差别在于：请求能不能被限速、异常能不能被识别、账号被试探的时候有没有人知道。

还有个更隐蔽的点，后台存密码的方式。要是程序还在用 md5 或者不加盐的 sha1 存密码，库一旦被拖走，等于把明文送人，这批用户在你别的站点上也保不住。主流框架现在默认是 bcrypt 或者 argon2，老系统该换就换，具体怎么换看程序文档，别照着某篇博客一把梭。

防撞库不止改密码：3个入口先堵上，头一个就是登录页

登录页是最显眼的门，也是最容易被写坏的。常见的毛病有这么几个：没有失败次数限制，同一 IP 或者同一账号可以无限提交；报错提示分得太细，“用户不存在”和“密码错误”分开写，等于免费给攻击者做账号枚举；验证码形同虚设，或者只在第三次失败才出现，而攻击者一个账号只试两次就换号，永远碰不到。这三件事凑一块，登录页就是个敞开的口子。

改法不复杂。账号维度加失败计数，连续错几次就短暂锁一段时间或者强制出验证码；IP 维度加频控，Nginx 里 limit_req 按每秒请求数掐一下，宝塔面板的网站设置里也有对应的限速入口，具体项以面板当前版本为准。报错文案统一成一句“账号或密码不正确”。再加一层双因素，哪怕是邮箱验证码，也能把拿着清单硬撞的人挡在门外。密码修改这块也一样，改密码页面要求输入原密码、改完踢掉其他会话，别让人撞进去之后还能挂着不走。

第二个入口：找回密码那一页

这页最容易被忽略，因为在很多人脑子里它是“辅助功能”。实际上攻击者很喜欢它：输个邮箱就能触发发信，没有频控的话，你的域名就变成了别人手里的轰炸工具，轻则进垃圾邮件黑名单，重则被服务商限流，正常用户收不到验证邮件。更麻烦的是重置链接的设计——token 太短、能重复使用、有效期长达几天，或者链接里的邮箱参数可以直接改，这些都是现成的洞。

能落地的做法：同一邮箱和同一 IP 都设触发间隔；重置 token 用足够长的随机串，一次性消费，十几分钟到一小时过期就够用；重置成功之后立刻让该账号所有在线会话失效。还有个细节，重置页面别把目标邮箱完整显示出来，遮一半就行，不然又是一个枚举接口。

第三个入口：接口和 xmlrpc 这种看不见的门

网页上你能看见的登录框只有一个，接口层面可能有三四个。移动端 App 的登录接口、小程序、第三方登录回调，还有 WordPress 这类程序默认开着的 xmlrpc.php——它支持一次请求提交多组用户名密码，是撞库的人非常喜欢的省事通道。很多人把 wp-login.php 保护得严严实实，转头 xmlrpc.php 大开，前功尽弃。

不用这个功能的，直接关掉或者拦截，Nginx 里给 xmlrpc.php 返回 403 就行。要用的，就同样加频控和鉴权。自己写的接口更要注意：登录接口不能靠前端校验，速率限制必须落在服务端或者网关层；返回体别带“账号存在”这类差异信息；请求体大小设个上限，避免有人拿超大表单刷。日志里留全 IP、UA、时间戳，出事了才有得查。

频控和日志，两个最便宜的先上

加固不一定要买设备。频控和日志是性价比最高的两件事，而且顺序上应该先做。频控拦住量，日志让你知道有没有量。Nginx 的 access.log 里，同一 IP 在几分钟内刷了几十次 POST /login，这种模式肉眼都能看出来，写个脚本 grep 一下也能筛。有条件的把日志送到集中平台，留够保留天数，别三天就轮转没了。

顺手还能做的：后台路径别用默认的，admin、wp-admin 这类地址被扫描器盯得最紧；管理入口加 IP 白名单，自己固定办公就限死；关掉不需要的注册入口和调试模式。这些都是几分钟的事，做了就少一堆噪音。

手上是虚拟主机，能做的比想的多

不少人以为共享型虚拟主机啥也干不了，只能等被撞。其实能做的不少：.htaccess 里可以加基础的重写和访问控制，面板一般有限速和防护开关，程序层面有安全插件可以挡暴力登录，前面套一层 CDN 也能把频控和 WAF 交给边缘节点。限制当然有，比如你动不了内核参数、装不了系统级组件，这种时候就把能控的部分控死，剩下的靠程序本身和 CDN 兜。各家面板的开关位置和可用能力差别挺大，以服务商或官方页面说明为准。

最后给个顺序，照着走就行：先看登录页有没有失败计数和统一报错，再看找回密码有没有频控和一次性 token，最后把接口和 xmlrpc 这类隐藏入口过一遍，能关的关、要留的加限速。密码修改策略跟着一起收紧，但别指望它当主角。做完这三步，再去考虑双因素和日志集中，那时候投入才算花在刀刃上。