怎么也没想到,我的个人网站数据库竟然被黑掉了。所有的库都被删掉,只留有一个勒索信息表。查看数据库日志,除了 drop 库和新建了一个 mysqlbackups 用户之外,并没发现其他记录。(已经撕票,还让我交钱,没有武德啊)。不过庆幸,只是侵入了数据库,并未发现服务器有异常,而且数据库的binlog文件都在。下面就尝试通过日志文件进行恢复。

截图1

关于 binlog

二进制日志 binlog 是 MySQL 最重要的日志之一,记录了对数据库的常见增删改查,索引,表的操作记录(DDL和DML);binlog 主要用于复制和数据恢复。关于复制,之前写过一个简单的示例 使用Docker实现简单的MySQL主从复制。本篇的内容主要介绍数据恢复。

binlog 默认开启,SET SQL_LOG_BIN=1开启,SET SQL_LOG_BIN=0关闭(重启生效)。

show master status 可以查看当前正在写入的 binlog 文件。binlog 的磁盘路径,默认应该位于 /var/lib/mysql 下,可以在数据库配置文件中自定义。(binlog 在生产环境作为重要的日志文件,一定要特别注意保存和维护)。

切换到 binlog 所在目录,可以看到日志文件分为两类。

  1. **.index (index后缀)记录所有有效的的二进制文件,index 就是 binlog 的索引目录文件。
  2. *.0000 (数字后缀) 记录数据库所有的 DDL 和 DML 语句事件。

日志恢复

可以使用 mysqlbinlog 命令去查看 binlog。mysqlbinlog是 shell 命令,而不是 MySQL 命令

mysqlbinlog mysql-bin.000001可以进行直接查看。当然,很少的情况会这样使用,因为通常 binlog 很大,会导致终端窗口无限滚动。

出现了错误?

直接执行 mysqlbinlog mysql-bin.000001 出现错误: mysqlbinlog: unknown variable ‘default-character-set=utf8’。可以尝试带上参数 --no-defaults;即 mysqlbinlog --no-defaults mysql-bin.000002
下面所有的 mysqlbinlog 命令基于我本地服务器的环境,默认都带上 --no-defaults

这就要求我们进行有目的地查询;比如手误删除了某个表中的数据,可以以该表的表名 table1 作为关键词进行查询;知道某个具体的自增主键的ID,也可以通过ID作为关键词。

mysqlbinlog --no-defaults mysql-bin.000001 | grep table1 -C 3; 这里通过 grep 查询关键词 table1,其中 -C 3 表示查看关键词匹配行的上下三行内容。同理,-B 3打印匹配行的前3行(B=before);-A 3打印匹配行的后3行(A=after)。

截图2

上图是查询关键词 INSERT_ID=2734961 的终端截图。

这里有两个重要的信息(图中划红线的位置):position 事件位置和事件时间。下面几个参数可以用来框选日志的范围。

  • –start-datetime=开始时间

  • –stop-datetime=结束时间

  • –start-position=开始位置

  • –stop-position=结束位置

  • –database=数据库名称

mysqlbinlog --no-defaults --database=db --start-position=34926815 --stop-position=181096090 mysql-bin.000001 | /usr/bin/mysql -uroot -ppwd -v db 事件位置在 34926815 和 181096090 之间的脚本重新执行(恢复)到指定账户的数据库,只执行该数据库的事件 db 库有关的脚本。

总结

这次暂不清除什么原因导致数据库账户泄露,但终归是因为没有良好的数据库权限管理的习惯,而导致这次的"损失"。折腾一下午,数据算是恢复了。亡羊补牢,这里列出几个常见的tips:

  1. 数据库的 root 账户只能在数据库所在服务器进行本地使用,不得远程登录。
  2. 平时的数据库连接工具采用一个库一个账户的方式,防止鸡蛋放在一个篮子里。
  3. 接口服务的数据库连接账号只予以增删改查的权限 select,insert,update,delete。因为代码都在云端托管,万一第三方出现信息泄漏(gitlab出现过账户信息泄漏),也能将风险劲量降低。

另外,对数据库的定期备份也是一个必须操作。因为这次好在数据库数据量不大,恢复也未太费功夫。倘若生产环境数年的数据被删除,即使可以通过日志进行恢复,恢复过程中的宕机损失也不能忽视。有了定期备份,需要恢复数据量的减少也会大大减少恢复本身所需的时间,从而减小意外事故带来的业务损失。

最后,害人之心不可有,防人之心不可无。