MySQL / MariaDB 数据库被勒索病毒加密

MySQL 被加密的案例和 SQL Server 有一个明显区别：入口通常在 Web 侧，不在数据库侧。据公开报告，TellYouThePass 家族用 Go 语言开发、支持跨平台，长期通过 Web 组件与业务系统的高危漏洞（文件上传、命令执行、反序列化）批量投放，落地后同时加密 Web 目录与数据库目录。这也解释了为什么很多受害单位会看到「网站文件和数据库一起中招」。

业务风险有三层。第一层是可用性：官网、商城、OA、小程序后端同时中断，订单与支付链路断裂。第二层是数据完整性：MySQL 常承载会员、订单、支付流水这类高价值数据，缺一段时间的数据在对账上是实质性问题。第三层是数据外泄与合规：会员手机号、身份信息属于个人信息，涉及《个人信息保护法》下的通报与处置义务，需要与法务同步评估。

这个场景下最危险的几个动作：

• 重装系统或重装 MySQL 到原目录。 Linux 主机上 yum / apt 重装会覆盖数据目录里的残留文件，是最常见的不可逆错误。
• 反复启动 mysqld 并加 innodb_force_recovery 逐级尝试。 在表空间被加密的情况下，强制恢复会触发页丢弃与重写，破坏可提取的数据页。
• 在宝塔 / phpMyAdmin 里做「修复表」操作，或直接删除 ibdata1 想让服务起来。
• 把网站从备份覆盖回原目录，把入口证据和残留数据一并冲掉。
• 在原分区上跑恢复工具并写回同一盘。
• 运行攻击者的解密器。

我们不建议支付赎金，也不提供代谈判服务。

• 3306 不对公网开放。 数据库只监听内网或 127.0.0.1，远程管理走 VPN 或跳板机；云上安全组不要出现 0.0.0.0/0 的 3306 规则。
• 管理面板是高危入口。 宝塔、phpMyAdmin、Adminer 等不要暴露公网；必须用时改默认端口、绑定来源 IP、开启二次认证，并及时升级面板版本。
• Web 应用与组件按月跟补丁。 据公开报告，TellYouThePass 等家族主要依赖 Web 组件与业务系统高危漏洞批量投放；框架、中间件、CMS 插件、上传组件都要纳入补丁范围。
• 上传目录禁止执行。 Nginx / Apache 配置中对上传路径关闭脚本解析，PHP 关闭 system、exec 等危险函数，限制 open_basedir。
• binlog 与备份放到数据目录之外。 binlog 开启并独立存放（最好异机同步），逻辑备份与物理备份至少一份写入离线或不可变存储，备份账号独立。
• 数据库账号最小权限。 应用账号不给 FILE、SUPER、PROCESS 权限，禁用 root 远程登录，删除匿名账号与 test 库。
• Linux 主机侧加固。 SSH 禁用口令登录、审计 authorized_keys 与 crontab、部署具备勒索行为检测的主机安全产品，并监控大量文件改写。
• 定期做还原演练。 每季度在隔离环境从备份 + binlog 完整恢复一次业务库并计时，确认链路真实可用。