游戏服务端数据库安全：SQL 注入、弱口令与备份恢复

游戏服务端数据库，为什么是”重灾区”

很多私服服务器被打穿，不是网关没防住，而是数据库先失守：GM 后台弱口令、网站 SQL 注入、数据库端口暴露公网、备份文件放在网站目录里能直接下载。一旦被拖库，玩家账号、充值记录、角色数据全没了，比掉线严重得多。

一、SQL 注入：从网站打进数据库

开服网站、注册页、充值回调、排行榜查询，只要拼接了用户输入，就可能被注入。典型利用链：

1. 通过 union select 读出管理员表，拿到 GM 账号
2. 用 into outfile 写入 webshell
3. 直接 drop table 或改充值金额

防护要点：

• 所有 SQL 使用参数化查询，禁止字符串拼接
• 数据库账号最小权限：业务账号不给 FILE、DROP、GRANT
• 关闭 into outfile 与远程 root 登录
• WAF 拦截常见注入特征，作为第二层兜底

二、弱口令与公网暴露

最常见的入侵入口其实是 3306 / 1433 直接开在公网，root 密码还是 123456。建议：

• 数据库只监听内网（bind-address = 127.0.0.1）
• GM 后台改默认路径、加二次验证、限制来源 IP
• 数据库、SSH、面板端口一律不对公网开放
• 定期用 ss -antp | grep 3306 检查监听地址

三、备份：出事之后的唯一救命绳

“被删库”在游戏圈不是新闻。备份要满足三个条件才算数：

1. 能自动跑：每天全量 + 每小时增量，跑完发通知
2. 异地存：不要和数据库放同一块盘、同一台机器
3. 能恢复：定期做一次真实还原演练，别只验证”备份文件存在”

# MySQL 每日全量备份示例
mysqldump -uroot -p --single-transaction --routines --triggers game_db \
  | gzip > /backup/game_db_$(date +%F).sql.gz

四、监控：早发现比事后补救便宜

• 数据库登录失败次数告警（暴力破解）
• 表数量、数据量突变告警（删库前兆）
• 慢查询与连接数监控（性能问题前兆）
• 备份任务成功/失败通知

五、被入侵后的处理顺序

先断网保留现场 → 查 webshell 与异常账号 → 从干净备份恢复 → 改所有口令 → 复盘入口。切忌直接格式化，否则下次还会被同样的方式打进来。

我们的高防服务器默认只开放必要端口，数据库与后台建议走内网访问；如果需要协助做安全基线加固，可以联系我们，服务器套餐见套餐价格。