目录

前言

删库事件过程

后续

删库流程

安全防御总结

前言

距离黑客删库到数据恢复已经过去了几天了，悬着的心总算放了下来，因为数据丢失差一点点就要吃”国家饭“去了...人生第一次遭遇删库还是有必要记录下的哈哈哈

删库事件过程

这是我嫂子公司当初接下的一个外包项目，我后来去帮过忙，其线上所使用的服务器为阿里云服务器，然后mysql，nginx，java，py脚本全部署在一起，然后上周服务突然无法访问，看到日志抛出数据库连接异常，当下就感觉不对劲，连忙检查数据库发现业务库已经木得了，取而代之的是黑客留下的一份勒索信息

 有生之年竟然能遇到删库事件，还特么的是生成环境，最关键的是这库还没有备份...连忙检查binlog日志开关，还好是打开的，但是查看了下日志文件，才发现已经被黑客清空，五味杂陈，难不成这回要因为数据丢失背黑锅了嘛（甲方由于和许多学校签订了合同，所以他们明显更急）

网上寻找数据恢复的商家，32张表开口1.8w，wdnmd，劳资帮我嫂子忙才赚那么一丢丢，数据恢复这么多，而且他们还没把握完全恢复，提出如果没完全恢复按照单表500收费，每张表都很重要，要是没完全恢复有个毛线用，不过开价高也能理解，这帮人也都是趁火打劫，看中数据价值；后来找了一个靠出售技术为主的大佬，只要2k。当然那些通过binlog日志恢复的商家就都不提了，因为日志没了直接pass了，上面提到的这两家都是通过服务器的底层文件去爬取原先的数据，然后再恢复过来，反正很吊。

后续

经过两天的数据恢复工作，生产数据总算是回来了，当然后续的一些小问题到时候会分别总结，针对此次被黑事件，也做了一些排查和总结

删库流程

1、攻击服务器暴露的端口，根据不同的端口执行不同的攻击策略（服务器上通过 lastb 查看登陆失败信息，能看到十几万次黑客爆破记录，无限猜测用户名和密码，试图暴力突破，其余端口类似，mysql数据库3306同理；暴力破解图部分如下）

2、针对mysql数据库的3306端口，黑客也是按照同样的方式，通过自动程序从常用的root用户名开始猜测破解
3、成功后进入数据库，删除非mysql默认数据库，创建一张勒索库并留下勒索信息
4、防止我们能轻易恢复数据，删库binlog日志

安全防御总结

1、最关键的还是数据库自动备份，建议通过异地备份，如果数据库不支持远程登陆，那只能本地备份了，不会写脚本的话可使用宝塔进行定时备份，当然我们也建议甲方购买阿里云的数据库服务
2、禁掉ssh的root登陆，密码增加错误次数限制
3、禁掉大部分非必要端口，同时修改所有默认端口号，比如 22、3306 等