数据库丢失昨天晚上，一个读者群的朋友发来消息说他的数据库被黑了。当然，我立即对安全产生了兴趣。我加班加点开始分析。不知道的还以为我会熬夜等购物节呢。这位小伙伴使用某云平台搭建了自己的网站，但是昨天登录的时候发现了一个奇怪的错误：好像是数据库有问题，然后查了下数据库，结果发现有些粗略……好像是被勒索了黑制作组有所察觉，根据上面的提示，下载杀掉了两个数据库，分别是：kodbox和zxl。这位小伙伴把账号密码给了我，登陆了。用Navicat连接查看，果然，两个库只剩下一张名为WARNING的表，而且表中也只有一行记录，留下了threat勒索者信息：接下来我打算用SSH登录服务器，看看有没有什么线索。首先查看了系统登录日志，没有发现可疑的IP登录记录。再次查看系统用户列表，没有发现可疑用户。然后查看MySQL日志。虽然朋友说没有开启binlog，但实际发现是开启了，日志文件也存在：然后在mysql-bin.000023中找到案发现场，使用mysqlbinlog工具查看binlog日志：根据binlog时间戳，事件发生时间在11月10日早上8点32分到8点34分之间，两分钟以内。根据日志记录，攻击者并没有备份数据，只是简单粗暴的进行了DROP操作，所以别指望听话交钱了事。接下来准备查看MySQL登录日志，看看这段时间登录的是哪个IP，哪个用户名。可惜没有启用通用日志：再看user表，这里出现了一个神秘的admin用户，密码还是弱：123456这不就相当于开了一扇门，让人随意进出？既然有binlog，需要恢复还是比较容易的。除了MySQL，在查看系统安全日志时，发现日志文件大得惊人：不看不知道。当我看到它时，我感到震惊。里面全是各种IP的SSH暴力破解登录记录，持续了24小时。试试看，感受一下暴击：当你用tail-f命令打开它的时候，会不断刷新屏幕，不断增加，可见攻势有多么猛烈。还好这位小伙伴的系统密码强度还不错，不然早晚被人破解。但是连续的暴力登录也是挺烦人的。防火墙应该被允许做这项工作。没想到检查后竟然关闭了防火墙。..我觉得我快窒息了。快速启动防火墙并工作，并指定一个规则以在一分钟内拒绝超过3个SSH连接：iptables-IINPUT-ptcp--dport22-mstate--stateNEW-mrecent--nameSSH_RECENT--rcheck--seconds60--hitcount3-jDROP再次查看安全日志，增长速度明显放缓。安全忠告这段经历表明，安全并不遥远。好在这次小伙伴的数据并不重要，binlog也开启了，没有造成什么重大损失。但是如果没有开启呢？如果是公司项目怎么办？那么后果就很严重了。保安这根弦还是时不时绷紧的。这里有几点提示：(1)日志记录。只要业务允许，尽量启用详细的日志记录，以便事后追溯源头。包括但不限于操作系统日志、审计日志、Web访问日志、数据库连接登录日志、数据操作日志等。（2）数据备份定期对关键数据进行备份和存储，以便从容应对勒索软件加密。(3)密码强度不要使用弱密码。同时使用数字、大小写字母和特殊符号。一个好的密码可以帮助您抵抗一半以上的攻击可能性。(4)定期修改密码即使使用高强度密码，也不是一劳永逸的。除了技术攻击，还有社会工程学。带着密码环游世界是极其危险的。不时更改密码也是非常有必要的。(5)防火墙防火墙的重要性不用多说，利用好防火墙将大部分攻击者拒之门外。(6)专业的安全产品企业和政府单位也需要专业级的安全产品，比如案例回溯的全流分析产品，可以发现对方是如何进入的，从而及时发现系统漏洞并进行修复.互联网是一个充满敌意的环境，不要让你的服务器裸奔在云端。
