服务器被黑，p0级事故现场

本文已参与好文召集令活动，点击查看：后端、大前端双赛道投稿，2万元奖池等你挑战！

事情过程

网站访问不了的事也有发生过，我当时的也没多想，感觉应该是服务挂了，重启一下就可以了。

花Gie用二指禅熟练的敲着命令，因为是直接部署在tomcat下面的，所以直接进入tomcat的bin目录，执行./startup.sh，服务成功启动，很完美，访问一下主页试试。

这......，略显尴尬，于是打开日志看了一下，在日志上提示是表不存在。

linux查看文件命令：

• cat： 由第一行开始显示文件内容
• tac 从最后一行开始显示，与cat相反
• nl 显示的时候带有行号
• more 一页一页的显示文件内容
• less： 与 more 类似，但是比 more 更好的是，他可以往前翻页！
• head： 只看头几行
• tail： 只看尾巴几行
• tailf： 显示动态日志，也可以使用
• tail -200f： 设置加载的行数

当时还是觉得问题不大，猜想应该是数据库出现异常，没有忽略数据库表大小写之类的问题，然后就用本地的navicat打开数据库看了一下。

不看还好，一看眼睛都湿润了，这也太感人了，两个库删的干干净净，就剩下了一张表，表的内容大致意思就是 你的数据库已被我们黑了，需要交钱才能赎回 。

数据库恢复之路

就算一万个那啥啥奔腾而过，花Gie也要坚强，不哭，不能慌。常在河边走哪有不湿鞋，这个时候更需要展现出惊人的应对能力，开启数据库恢复之路。

• 备份库

数据库损坏，首先我们应该考虑的是以前有没有备份，可能有很多小伙伴没有接触过数据库备份，这里也和小伙伴们大致介绍一下通过过设定Crontab来每天备份MySQL数据库的方法。

1. 新建脚本，每天定时执行

#!/bin/bash
# 数据库认证
 user=""
 password=""
 host=""
 db_name=""
# 备份路径
 backup_path="/home/mysql"
 date=$(date +"%d-%b-%Y")
# 设置导出文件的缺省权限
 umask 177
# Dump数据库到SQL文件
 mysqldump --user=$user --password=$password --host=$host $db_name > $backup_path/$db_name-$date.sql

1. 定期删除

通过上面的脚本，我们可以每天导出一份数据库的sql备份文件，但是随着时间变化，数据库备份脚本占用较大内存，可以执行脚本删除一些较久远的备份文件。如果备份的数据库文件内容为空，查看是否缺少系统环境信息mysqldump。

# 删除7天之前的就备份文件
 find $backup_path/* -mtime +7 -exec rm {} ;

是不是很简单呢，但是我的库因为是自己博客，以前也没有被黑的经历，完全没有当回事，所以没有数据备份，忍不住流下没有备份习惯的眼泪。

• binlog

不慌，还有binlog（此时的内心已经开始慌张，默默祈求当时一定开启过binlog）。

首先打开数据库，输入show variables like 'log_bin';查看

嗯，很好，结果查出来了，和我想的一样，我没有开启binlog。。。

在MySQL8以前，这个功能是默认关闭的（内心已经接近崩溃），需要手动开启。虽然我的数据库binlog没有开启，这里还是要给其他小伙伴介绍一下binlog怎么用。

1. 在/etc/my.cn添加如下配置文件（后面会专门写一篇binlog怎么玩的教程）

[mysqld]

server_id=1918

log_bin = mysql-bin

binlog_format = ROW

1. 重启mysql

CentOS 6：service mysqld restart

CentOS 7：systemctl restart mysqld

1. 使用show variables like '%log_bin%'查看是否开启成功

• 服务器快照

前面两种方式都不适用，说实话，我有点慌了，真慌了。。。我个人博客辛辛苦苦积累的十万张图片素材，还有一千多篇文章就这么没了，真的挺可惜的。于是我冥思苦想，想起来我可以去找找服务器运营商管理界面的快照，这是我最后一根救命稻草，我小心翼翼的登录网站，点开快照按钮，我甚至不敢睁开眼。

哈哈哈哈哈哈哈.......哈哈哈哈哈哈哈.........啊啊啊啊啊啊啊啊啊啊啊啊............啊啊啊啊啊啊啊啊啊啊啊啊...............啊哈哈啊哈哈哈哈哈哈。

苍天不负有心人，终于经过这么久的努力，我放弃了....，服务器没有快照。我哭了，哭的好大声。

最后的倔强

从小就受优秀环境熏陶的花Gie是不会向恶势力低头的，绝不，绝不可能。大家看好，就是这个邮箱...

血的教训

综合我的这次事件，我这里也给小伙伴们一些警醒，也是一些注意项：

• 密码强化，千万不要root/root，admin/admin，这简直送人头，非常容易破解
• 不推荐使用默认的端口3306
• 极其不推荐放开远程访问权限，在my.cnf 配置文件中添加 bind-address =127.0.0.1, 设置仅限本地访问，如果是硬性需求，只允许特定安全网段访问数据库。
• 开启binlog
• 使用云主机的安全组功能，限制访问来源和端口。

总结

对于网络安全，这次也算是一个警醒，也算给小伙伴们做了一个示范，如果有大佬还有其他什么办法，可以留言告诉我，和大家一起分享这些抗争的经验.

当然我们需要注意，遇到这种事情千万不要联系对方，因为对方根本就不会备份你的库，交钱就等于打水漂。

点关注，防走丢

以上就是本期全部内容，如有纰漏之处，请留言指教，非常感谢。我是花Gie，有问题大家随时留言讨论 ，我们下期见🦮。

原创不易，你怎忍心白嫖，如果你觉得这篇文章对你有点用的话，感谢老铁为本文点个赞、评论或转发一下，因为这将是我输出更多优质文章的动力，感谢！