上周朋友老张的茶叶电商网站被拖库，用户手机号、收货地址全被发到暗网论坛上，后台日志里只留下一串陌生IP和几条异常SQL查询。他第一反应是找人重装系统，结果三天后又被扫出新漏洞——拖库不是偶然事件，而是防护链条上某个环节松了扣。
别迷信“我用的是大厂云，肯定安全”
某SaaS建站平台去年曝出批量拖库，原因不是底层云服务出问题，而是默认管理员账号密码是 admin/123456，且没强制改密。很多中小网站连基础口令策略都没设，攻击者用字典爆破10分钟就能进后台。建议登录页加图形验证码+登录失败5次锁定IP，同时禁用默认账号名：
## Nginx 配置示例：限制登录频率
limit_req zone=auth burst=5 nodelay;
limit_req_status 429;数据库别裸奔，哪怕只是本地库
见过最离谱的是把MySQL直接绑在公网IP上，端口3306开着，root账号无密码。就算用的是虚拟主机，也要确认数据库连接字符串里是不是明文写了账号密码。PHP项目里常见这种写法：
// 危险！密码硬编码在config.php里
$db_host = '127.0.0.1';
$db_user = 'root';
$db_pass = 'mypassword123';改成环境变量或配置文件外置，配合.gitignore屏蔽敏感文件。线上环境数据库账号权限只给必要表的CRUD，绝不用root。
插件和CMS不是越新越好，而是越稳越香
WordPress站点被拖库，70%以上源于未更新的旧版插件。有次帮客户查日志，发现攻击路径是通过一个停更三年的“WP-SEO-Boost”插件上传webshell。现在主流CMS都支持一键检测插件漏洞（如Drupal的Security Review模块），开启自动通知比手动检查靠谱得多。
日志不是摆设，得有人真看
某教育平台被拖库前一周，Nginx日志里反复出现 /wp-content/plugins/xxx/ajax.php?data=SELECT%20*%20FROM%20users 这类请求，但没人配置告警规则。建议用免费方案：Logrotate + grep + mail 做简易监控，比如每小时扫一次含 union select 或 information_schema 的访问记录，命中就发邮件。
最后一条，也是最容易被忽略的
定期导出脱敏后的用户数据做本地备份，不是为了防丢，而是为了对比。上个月发现某社区网站用户注册量突增200%，查数据库发现是机器人批量注册——这些账号后续成了撞库攻击的跳板。导出时用脚本自动替换手机号中间四位为****，邮箱@前缀截断，既满足合规，又能快速识别异常增长。
拖库不是黑产的魔法，它靠的是自动化扫描+已知漏洞+管理疏忽。你不需要懂逆向工程，只要把登录口锁紧、数据库权限收窄、插件保持更新、日志设好提醒、数据定期核对，大多数拖库攻击会在你服务器门口转三圈后放弃。