阿里云中mysql数据库被攻击了,最终数据找回来了

介绍

昨天登自己的网站的时候,发现登不上去,由于是用springboot写的,存放在阿里云轻量云服务器中,所以我去后台查看了一下日志,发现是查不到数据了。

这个时候就发现是数据库出现了问题,然后通过图像化的工具打开了自己的远程数据库,发现自己建的数据库全都不见了,自己排查了半天没有发现是怎么回事,这个时候在别人的提醒下去找了一下阿里的客服,它们为我分配了工程师,工程师帮我确定了排查的范围

最后通过查看二进制文件发现的被国外的黑客攻击了
下面话的意思大概就是让我花钱去把数据买回来不然就将我的数据卖出去,还好数据不是很重要。

并且将我的所有数据库都删除了

mysql的配置

mysql5.6.46 阿里云服务器中的mysql数据库,使用时间不到一年

恢复过程

binlog

什么是binlog

简单通俗来讲，其实就是一个记录所有增删改操作记录的日志。我们可以通过它来对误操作的数据进行恢复，当然还可以用来进行主从数据库的同步操作。

binlog的三种模式：

①statement：记录每一条修改数据的sql。

优点：日志文件比较小，节约io操作，性能较好。

缺点：只记录执行语句，所以还需要保证在主从执行的得到相同的结果。所以准确性差。

②row：保存哪条记录被修改。

优点：准确性强。

缺点:日志文件比较大。

③mixed：兼顾前两者的优点。(我属于这种)

实际操作：

① 查看binlog有没有开启：如果没有开启的话,就彻底凉凉了,几乎没有恢复的机会了,不过可以找攻击者买回数据

在mysql中输入命令：SHOW VARIABLES LIKE ‘log_bin’; 如下所示

可以看到

Value

是ON
如果没有开启的话,可以参考下面的文章,
https://blog.csdn.net/qq_21996541/article/details/107280382

也可以通过模糊查询,看到更多的信息

③ 查看binlog日志：

通过命令：

SHOW MASTER STATUS

;可以查看当前是在哪个日志文件中，

通过命令：

FLUSH LOGS;

可以截断日志文件，重新定向到新的日志文件中，我们在实际操作的时候，每次操作binlog恢复前，都需要执行下此命令，能够保证之前的日志文件不会再有新的日志在到这个文件中，影响恢复。
执行完之后再次查看的时候就会多一个

然后，可以根据命令：show variables like ‘%datadir%’; 查询出这些日志文件保存的路径

我们在服务器，cd 到这个目录下，这些文件确实存在。但是这些文件是二进制文件，用cat/vi这些命令是无法正常查看的。

这时候就需要我们的mysqlbinlog这个命令登场了，

首先，我们在服务器中输入命令：mysqlbinlog /www/serverl/data/mysql-bin.000020;

如果输入上面的命令报错的话,可以输入下面的命令
输入命令：mysqlbinlog --no-defaults /www/server/data/mysql-bin.000020; 可以看到有如下的一个文件信息。
然我们还可以在mysql中输入命令：

SHOW BINLOG EVENTS IN 'mysql-bin.000020';

这样也可以看到binlog中记录的一些事件：

其中，server_id =1，由于我们没有设置，就是表示就是默认主机，Pos我的理解就表示的是一个偏移指针，就类似于一个时间节点，在这个时间节点完成了哪些操作。event_type就表示事件类型，xid事务，query查询，write rows表示插入数据，delete_rows删除数据，都是比较好辨认出来的。

④ 通过binlog进行数据恢复：
通过查看,发现我的数据据库都在

mysql-bin.000010

这个二进制文件中
在该文件中可以清楚的看到我的数据库被删库前的最后一次操作时间是7月2号 10:35:34
删库前的时间是7月3号 0:20:06,一直到一点的时候才停止。
哎,花40多分钟来攻击一个没有什么利用价值的数据库,感觉有点不值得,而且还是在半夜。
可以看到被删除数据库的名字,有8个数据库,不过对于我来说,比较重要的就一个,有几个是平时测试的时候建的,里面也没有几条数据,
不过就是为了那一个最重要的,我就一定要将它找回来,只要还有一丝。



由于对于对于我来说比较重要的就一个数据库,其它的也没有什么数据,不是很重要,所有就通过恢复指定数据库的方式进行恢复。
通过如下命令生成

sql

文件,然后通过sql文件进行恢复

mysqlbinlog --no-defaults --database=xiaochengxu_ks --skip-gtids --stop-position=410161 /www/server/data/mysql-bin.000010 > /xiaochengxu_ks.sql

其中

xiaochengxu_ks 

是想要恢复的数据库的名字

--stop-position=410161

被删库前的位置对应的是

at后面接的数字

/www/server/data/mysql-bin.000010

该二进制文件的具体位置

/xiaochengxu_ks.sql

通过二进制文件生成的

sql

文件的位置

生成对应的sql文件在更目录下

在 MySQL 客户端命令行进入 xaiochengxu_ks 数据库，执行 source /xiaochengxu_ks.sql 恢复数据即可。

也可以设置起止点,但是我觉得没有必要,通过也可以通过时间区间的方式进行恢复

• 起始定位符 mysqlbinlog --start-position=249 binlog.000006
• 结束定位符 mysqlbinlog --stop-position=249 binlog.000006

总结

以前一直觉得网络安全不是很重要,那是因为没有发生在自己的身上,这几天让我感受到了它的无比重要,发誓以后要重视网络安全这方面,同时加强自身的知识水平,避免再次发生