数据库对外的三层风险
数据库端口暴露在公网时，风险来自三层叠加：一是撞库与弱口令，攻击者可以持续尝试；二是账号来源范围过宽，例如允许从任意主机连接的账号，一旦口令泄露，任何位置的攻击者都能连；三是缺少网络层限制，脚本小子在全网扫描时就能顺手发现。核查要一起看监听地址、账号来源与边界放行三项，任何一项没收紧都算未完成。
基本信息
| 加固项 | 数据库暴露面与账号来源收敛 |
|---|---|
| 适用平台 | Linux 与 Windows（MySQL 与 MariaDB） |
| 风险等级 | 高 |
| 基线 | 不暴露公网，账号来源限制到具体网段 |
| 端口 | 默认 3306 |
典型使用场景
- 暴露面核查：确认数据库未对公网开放
- 账号治理：清理来源过宽的账号与匿名账号
- 入侵排查：勒索事件中数据库被删除往往从暴露开始
- 上线检查：新库部署时一次性配置好监听地址与账号来源
- 合规整改：数据访问控制要求账号来源可限定
核查命令
核查命令
ss -tlnp | grep ':3306 '
mysql -uroot -p -e "SELECT user, host FROM mysql.user ORDER BY host;" 2>/dev/null
mysql -uroot -p -e "SHOW VARIABLES LIKE 'bind_address'; SHOW VARIABLES LIKE 'skip_networking';" 2>/dev/null
mysql -uroot -p -e "SELECT user, host, plugin FROM mysql.user WHERE host='%';" 2>/dev/null # 来源过宽的账号收敛动作
收敛动作
# 配置文件：[mysqld] 段中把监听地址收敛
grep -n 'bind-address' /etc/my.cnf /etc/mysql/my.cnf 2>/dev/null
# 账号来源收窄（示例，执行前确认无活跃连接依赖）
# RENAME USER 'app'@'%' TO 'app'@'10.0.1.%';
# DROP USER ''@'localhost'; # 清理匿名账号
FLUSH PRIVILEGES; # 权限变更后刷新三处收敛点
| 收敛点 | 当前风险形态 | 目标状态 |
|---|---|---|
| 监听地址 | 监听在所有地址上 | 仅监听回环或内网地址 |
| 账号来源 | 账号允许从任意主机连接 | 限制到业务网段或具体地址 |
| 账号口令 | 存在弱口令或空口令账号 | 强口令并纳入口令管理 |
| 匿名账号 | 存在无用户名账号 | 删除全部匿名账号 |
| 边界放行 | 安全组或防火墙放行该端口 | 仅对授权网段放行 |
来源过宽的账号配合弱口令，在扫描器眼里属于秒级可发现的目标：先把账号来源收窄，再谈其他加固。账号变更属于高风险操作，建议在变更窗口内执行，并事先确认没有应用以该账号从非预期网段连接。
改监听地址后本机连接不受影响，但远程连接会全部断开：变更前先确认应用使用的连接方式与来源地址，避免把正常业务一起中断。数据库账号的授权在修改后需要刷新权限表才会立即生效。
核查报告的写法
建议按四行输出：监听地址、账号来源分布、匿名与空口令账号数量、边界放行范围。每一行给出当前值与结论，并附上执行的命令与输出。这四行覆盖了暴露的三层与账号本身，结论清晰，也便于复评时逐项核对是否仍符合要求。