数据库失陷昨晚，读者群里一位小伙伴发信息说自个的数据库被黑了，搞安全性的我当然是马上来啦兴趣爱好，日夜奋战逐渐剖析起來，不清楚的还以为我想经常熬夜等抢货节呢。
这名小伙伴应用了某云平台搭建了一个自身的网址，昨日登陆却察觉了古怪的出错：
看来是数据库出了问题，接着查询数据库，才发觉粗事儿了···
看来是遭敲诈勒索灰产精英团队看上了，依据以上的信息提示，有两个数据库被他给免费下载后灭掉了，分别是：kodbox、zxl。
这名小伙伴给了我账户密码，登陆了上来。
用Navicat联接查询了一下，果真，这两个库文件只剩余一个名称为WARNING的表，表格中仅有一行纪录，留有了敲诈勒索者的危害信息内容：
下面，准备用SSH登陆到云服务器上，看一下有哪些抽丝剥茧。
最先查验了系统登录日志，并没看到有异常的IP登陆纪录。
再观察了系统软件客户目录，都没有发觉有异常的客户发生。
然后查询MySQL的日志，尽管这名小伙伴说沒有打开binlog，但具体发觉是开始的，而且日志文档也存有：
接着，在mysql-bin.000023中，找到犯罪现场，应用mysqlbinlog专用工具查看binlog日志：
依据binlog时间格式表明，事发时间是在11月10日早上8:32-8:34分，短短的2分钟以内进行的。
依据日志纪录，网络攻击并沒有备份资料的实际操作，反而是简单直接的完成了DROP实际操作，因此别寄希望于乖乖听话汇钱就能搞定。
下面，提前准备查询一下MySQL的登陆日志，看一下这段时间是哪个IP和哪个登录名登陆上去的。
很遗憾general日志沒有打开：
再看一下user表，一个隐秘的admin客户发生在了这儿，竟然用的或是弱口令：123456
这不是相当于开一扇大门口令人随便出入吗?
即然有binlog，要修复起來或是很容易。
别的发觉
除开MySQL，在查验系统优化日志的情况下，发觉日志文档十分的大：
不要看不清楚，一看吓一跳，里边都是来源于各种各样IP的SSH暴力破解密码登陆的纪录，不断24小時在试着，觉得遭到了暴击伤害：
用tail -f 指令开启的情形下，便是不断不停的在霸屏提高，由此可见进攻之强烈。
幸亏这名小伙伴的系统软件登陆密码抗压强度还算可以，要不然迟早给打穿了。
但这连续不停的暴力行为登陆也挺讨厌的，应当让服务器防火墙来干活儿了，想不到一查验服务器防火墙居然是关闭的情况。。。我感觉即将室息了。
赶快把服务器防火墙扶了起来工作中，再给配一条标准，一分钟以内超出3次的SSH联接就给拒掉：
再度查验secure日志，提高的效率显著变缓了。
安全性提议
此次历经说明，安全性离大家并不遥远。
所幸这一小伙伴此次的信息并不重要，并且还开始了binlog，沒有产生哪些关键的损害。可要是没有打开呢?万一是公司新项目呢?那结果就明显了。
安全性这一根弦或是常常要绷紧，下边是一些小提议：
(1) 日志纪录
在业务流程容许的情况下，尽量的打开详细的日志纪录，便于在案发前追溯跟踪。包含但是不限于电脑操作系统日志、财务审计日志、Web浏览日志、数据库联接登陆日志、数据信息实际操作日志这些。
(2) 备份数据
按时开展核心信息的备份数据储存，碰到敲诈勒索数据加密也可以从容应对。
(3) 登陆密码抗压强度
不能用弱口令，数据、字母大小写、特殊字符一起上，一个好的登陆密码可以帮你扛得住一大半的进攻很有可能。
(4) 按时更改密码
即使用上高韧性登陆密码，也不是一劳永逸，除开技术性进攻，也有社会工程学，一个登陆密码行万里路风险性极高，隔三差五更改密码也是十分需要的。
(5) 服务器防火墙
防火墙的必要性就不要多讲了，用好服务器防火墙，将绝大部分网络攻击避而不见。
(6) 技术专业的网络安全产品
针对公司和政府单位，还必须专业型的网络安全产品，例如全流量统计商品用以案子回朔，寻找另一方是怎么进去的，有利于找到安全漏洞，立即修复。
互联网技术是一个充满了虚假的自然环境，别使你的网络服务器在云上裸跑。