快速识别MySQL后门账户需重点检查host字段异常（如'%','0.0.0.0','127.0.0.1'、空值或通配符）、无密码、账户未锁定、密码长期未更新及plugin异常，并结合account_locked、password_last_changed等字段交叉验证。
如何快速识别 mysql.user 表里的后门账户
后门账户最典型的特征是 host 字段值异常：比如 '%'、'0.0.0.0'、'127.0.0.1' 配合高权限，或出现非常规 IP 段（如 '192.168.100.%'）、通配符混用（如 '%.example.com'），甚至空字符串 ''。这些不是“不能用”，而是极难被日常运维注意到的隐患。
执行这条语句能一次性暴露高风险记录：
SELECT user, host, authentication_string IS NULL AS no_password, account_locked, password_last_changed FROM mysql.user WHERE host IN ('%', '0.0.0.0', '127.0.0.1') OR host LIKE '%%%' ESCAPE '\' OR host = '' OR user = '';
注意：host = '' 是匿名账户，user = '' 是空用户名——两者都应立即删除；no_password 为 1 表示无密码，属于严重弱口令风险。
为什么不能只查 SELECT user,host FROM mysql.user
单纯列出所有用户和 host 容易漏掉关键上下文。真正危险的不是“存在 %”，而是“% + root + 未锁定 + 密码过期时间为空”。必须关联以下字段交叉判断：
-
account_locked：值为Y才安全，N且 host 为%就是开放大门 -
password_last_changed：NULL 或早于 90 天前，说明长期未更新，大概率是遗留账户 -
authentication_string：长度为 0 或明显短于 40 位（MySQL 5.7+ SHA256 哈希长度），可能被重置为弱密码或空密码 -
plugin字段（需额外查）：若为mysql_native_password且密码哈希很短，可能是人为降级兼容性留下的后门入口
定期审计时容易忽略的 host 匹配逻辑
MySQL 的 host 匹配不是简单字符串比对，而是按“最长匹配优先”规则排序。这意味着：
如果表里同时存在 'root'@'192.168.1.100' 和 'root'@'%'，客户端从 192.168.1.100 连入时，会命中前者——但如果你只删了 '%'，那个具体 IP 的账户仍可登录，且更难被日志归类为“远程泛用账户”。
所以审计必须包含：
- 查出所有 host 不是
'localhost'的非业务账户（业务账户应有明确 IP 段或域名） - 用
SELECT user, host FROM mysql.user ORDER BY host DESC;观察排序，确认是否存在看似精确实则宽泛的 host（例如'192.168.%'排在'192.168.1.%'前面） - 避免依赖
LIKE '%.%'模糊搜索——它会误伤合法域名（如'app.example.com'），应改用正则：host REGEXP '^[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}.*'
自动化审计脚本的关键检查点
手动跑 SQL 容易遗漏，建议用定时任务跑轻量脚本。核心逻辑不是“删掉所有 %”，而是标记可疑项供人工复核：
以下 SQL 应作为基础检查项嵌入脚本：
SELECT CONCAT('ALERT: ', user, '@', host, ' has global host and is unlocked') AS reason
FROM mysql.user
WHERE host IN ('%', '0.0.0.0') AND account_locked = 'N'
UNION ALL
SELECT CONCAT('ALERT: ', user, '@', host, ' has no password set') AS reason
FROM mysql.user
WHERE authentication_string = '' OR authentication_string IS NULL;
注意：FLUSH PRIVILEGES 不需要在审计阶段执行；但一旦确认要清理，删除后必须立刻执行该命令，否则内存缓存仍生效。另外，任何修改操作都应在低峰期进行，并提前备份 mysql.user 表（mysqldump mysql user > user_backup.sql）。
