记一次mysql数据库被黑,及通过几种方案恢复数据,复盘总结

事件经过

早上上班客户反映,项目无法登陆,于是抓包看了下接口,报错数据库表不存在。当时心里一慌,打开数据库查看。果然,只有孤零零的一个表 README 以下数据库已被删除:*。 我们有一个完整的备份。 要恢复它,您必须将0.013比特币(BTC)支付给我们的比特币地址bc1qs82lvzrrag7aqpnyme4njv32qquky0slrclftr。 有关说明,请通过yang21@tutanota.com通过电子邮件联系我们。 任何与付款无关的邮件都将被忽略!

这是一个中途接手维护的项目,平时改动也不多,所以没有特别的关注。数据库是在服务器上自己搭建的,并没有对数据库进行数据备份。于是采取紧急数据恢复。

数据恢复

方案1(通过binlog日志进行恢复)

数据库被删,第一反应就是通过binlog恢复。

执行命令show variables like '%log_bin%';查看binlog是否开启。

记一次mysql数据库被黑,及通过几种方案恢复数据,复盘总结 binlog是开启的。

执行命令show master logs;查看所有binlog日志列表。

记一次mysql数据库被黑,及通过几种方案恢复数据,复盘总结 感觉不太妙,只有两个日志文件。

执行命令show variables like 'expire_logs_days';查看binlog过期时间。

记一次mysql数据库被黑,及通过几种方案恢复数据,复盘总结 只保留了10天的日志这条路行不通了。好吧先把10天的数据恢复出来。

mysqlbinlog命令参考mysqlbinlog参数详解

执行命令mysqlbinlog ./mysql-bin.000012 > /home/12.sql

导出mysql-bin.000012文件的sql保存到/home/12.sql。同样步骤导出mysql-bin.000013的所有sql。记得删表drop命令后再进行数据恢复。或者mysqlbinlog ./mysql-bin.000013 --start-datetime="2021-07-02 00:00:00 --stop-datetime="2021-07-12 01:15:00 " > /home/13.sql 设置指定的时间范围。

注意:binlog尽量下载到本地进行恢复,防止对线上数据库造成二次污染。

方案2(通过邮箱联系删库者,进行恢复)

搜集信息

通过BTC浏览器查询BTC地址,该地址并没有任何交易记录,是一个新的地址。 googel搜索删库者留下的邮箱,发现同一晚上被删库的不止一家,应该是脚本批量执行的。

联系删库者

由于binlg无法恢复数据,当时又比较着急,就按照要求向BTC地址转账。结果是徒劳的,那边收到币后就没有再回复过邮箱。

事后分析

后来通过分析mysql登录日志发现1点15份12秒一个泰国IP登录,binlog日志中drop命令是1点15分52秒执行,中间四十秒根本不足以备份几个G的数据库。(吐槽下:删库者是真的没有一点职业素养,靠技术吃饭的活,非要搞成诈骗性质,就算加密文件备份到本地服务器也行啊)

方案3(通过硬盘误删恢复)

该方案有点后知后觉了,之前有过恢复物理硬盘的经历,对于云服务器硬盘恢复不甚了解,前两种方案无果才去执行该方案。

通过了解,如果当数据库误删后,不进行任何磁盘操作有90%以上的概率能恢复数据,当然费用也是不低,根据数据大小每张表差不多上千元的价格。

执行此方案的时候,磁盘已经有几个G的操作了(恢复binlog……)

复盘总结

  1. 数据库一定要开启定时备份,最好进行异地备份,如上传到OSS,防止服务器shell被拿后,删除本地备份。
  2. 数据库一定要开启binlog,并且设置binlog保存时间为永久,磁盘不允许可以定期把binlog日志文件备份到其他地方,保证binlog日志完整。
  3. 数据库安全。使用复杂的密码,使用权限较低的子账号,不使用远程登录,修改默认3306端口,定期检查登录日志等。
  4. 如果发现被恶意删库,先对磁盘做一个镜像,binlog下载到本地进行数据恢复,为硬盘恢复准备条件。
  5. 对于恶意删库索要报酬恢复数据,可以根据删库者留下的信息进行分析,分析是对手恶意攻击还是批量脚本的执行。登录时间删库时间的时间差判断是否进行过数据备份等,最终判断是否支付报酬。
{{o.name}}


{{m.name}}

原创文章,作者:ItWorker,如若转载,请注明出处:https://blog.ytso.com/71160.html

(0)
上一篇 2021年8月11日 19:12
下一篇 2021年8月11日 19:12

相关推荐

发表回复

登录后才能评论