【安全与故障排查】03-【复盘】数据库被入侵：从发现到溯源全过程

【复盘】数据库被入侵：从发现到溯源全过程

专栏： 安全 & 故障排查

难度： 进阶

标签： 安全事故 入侵溯源 数据库安全 复盘 应急响应

前言

这是一次真实的安全事故复盘（已脱敏）。凌晨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年前的废弃接口从未被下线。技术债务不只是影响效率，还会成为安全漏洞。定期清理废弃接口，是运维和研发共同的责任。