【复盘】数据库被入侵：从发现到溯源全过程
专栏： 安全 & 故障排查
难度： 进阶
标签： 安全事故 入侵溯源 数据库安全 复盘 应急响应
前言
这是一次真实的安全事故复盘（已脱敏）。凌晨2点，监控告警数据库异常连接，我们花了4小时完成了从发现到溯源的全过程。记录下来希望对你有用。
时间线
| 时间 | 事件 |
|---|---|
| 02:14 | 监控告警：MySQL连接数异常，突然增加200+ |
| 02:17 | 值班同学收到告警，登录服务器查看 |
| 02:31 | 确认入侵，开始应急响应 |
| 03:45 | 完成隔离，服务恢复 |
| 06:20 | 完成溯源，找到入侵路径 |
一、发现阶段
bash
# 异常告警触发，登录服务器查看
mysql -u root -p -e "SHOW PROCESSLIST\G"
# 发现大量来自非内网IP的连接
# 来自 103.x.x.x 的连接在持续执行 SELECT * FROM users
# 查看MySQL用户
mysql -e "SELECT user, host, authentication_string FROM mysql.user\G"
# 发现：多了一个陌生用户 'backup'@'%'二、应急隔离
bash
# 立刻隔离：修改iptables，封禁外网访问MySQL端口
iptables -I INPUT 1 -p tcp --dport 3306 -j DROP
# Kill掉所有可疑连接
mysql -e "SHOW PROCESSLIST\G" | grep "103\." | awk '{print $1}' | \
while read id; do mysql -e "KILL $id"; done
# 锁定可疑账号
mysql -e "ALTER USER 'backup'@'%' ACCOUNT LOCK;"
# 修改所有账号密码
mysql -e "ALTER USER 'root'@'%' IDENTIFIED BY '$(openssl rand -base64 24)';"三、溯源分析
bash
# 查看MySQL binlog，找攻击者的操作
mysqlbinlog /var/lib/mysql/mysql-bin.000023 | grep -A5 "backup"
# 发现：攻击者创建了 backup 账号并导出了 users 表
# 追查攻击来源
# MySQL general log（如果开启了）
grep "103.x.x.x" /var/log/mysql/mysql-general.log
# 系统日志
last | grep "103.x.x.x"
grep "103.x.x.x" /var/log/auth.log
# Web访问日志（找攻击入口）
grep -r "103.x.x.x" /var/log/nginx/
# 发现：这个IP在3天前通过一个旧的API接口进行了SQL注入四、根因分析
攻击路径：
1. 攻击者扫描发现系统存在一个2年前的旧API接口（/api/v1/user/search）
2. 该接口未做SQL注入防护
3. 通过 UNION SELECT 提取了数据库用户名密码（MD5弱哈希，被破解）
4. 直接使用账号密码连接MySQL（MySQL 3306 端口对外暴露）
5. 创建了后门账号并导出 users 表数据五、修复与加固
bash
# 1. MySQL端口禁止对外暴露
iptables -D INPUT 1 # 删除临时规则
iptables -A INPUT -p tcp --dport 3306 -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -p tcp --dport 3306 -j DROP
# 2. 下线旧API接口
# 3. 修复SQL注入（使用参数化查询）
# 4. 用户密码强制重置（已泄露）
# 5. 密码存储改用 bcrypt（不再使用MD5）
# 6. 添加API接口访问频率限制六、改进措施
| 改进项 | 执行时间 | 负责人 |
|---|---|---|
| MySQL端口禁止公网访问 | 立即 | 运维 |
| 全面SQL注入扫描 | 3天内 | 安全 |
| 删除所有废弃API | 1周内 | 研发 |
| 用户密码哈希升级到bcrypt | 2周内 | 研发 |
| 建立API废弃下线流程 | 1月内 | 全体 |
结语： 这次入侵的根因是一个2年前的废弃接口从未被下线。技术债务不只是影响效率，还会成为安全漏洞。定期清理废弃接口，是运维和研发共同的责任。