mysql暴力撞库与弱密码检测

暴力撞库与弱密码检测
最近在生产数据库上碰到了一个问题，觉得挺有意思，总结出来和大家分享下。
关于暴力撞库和弱密码检测。

相信使用数据库的大家应该都不陌生，暴力撞库，简单通俗的讲通过一堆生成的密码，然后用默认用户去登陆你的数据，不断尝试，直到登陆到你数据库内。

下面讲下事情的始然吧

偶尔的一次巡检，查询mysql的errlog，发现了大量的root@localhost Access denied
如下图所示：

当时哥后背一凉，倒吸了一口气。这TM不是撞库么，难道哥的密码泄露了？

第一反应：是不是zabbix的某个脚本，用了root用户，密码没有更新。后来仔细确认后发现，这种怀疑不成立，因为zabbix用户并没有使用root。该撞库的日志也只在夜里1-4点某一个时刻触发，并不像zabbix的行为

持续检查：是不是自己的自动化运维脚本除了问题，于是注释了所有的任务并停掉了一台从库机器上zabbix agent，第二天依然有撞库的日志产生

脚本捕获：查到这儿的时候已经是第三天，因为每次都只有夜里会有日志触发生成，这时候就有点慌了。于是开始认真的检查操作的日志
/var/log/secure
/var/log/message
不得不说/var/log/secure还是很管用的日志，记录一个异常登陆的SSH

Sep 27 03:03:57 AliYunOS sshd[1653]: Did not receive identification string from 127.0.0.1

但是也不能作为什么明确的证据，于是开始想着通过捕获操作的进程和连接来抓到对应的任务。
立马用python写了一个脚本:

ps -ef
nestat -anlp

每五分钟捕获一次，第二天根据mysql errlog日志生成的时间点去找对应的操作系统日志还是很有收获的，一眼能比对出，正常时间点和出现撞库时产生的日志文件大小不一致。通过拿出两个日志通过nodepad++ comapre对比，又找到异样的进程

unix  3      [ ]         STREAM     CONNECTED     605808719 1565/AliSecureCheck 

不得不说，即使拿到这个异常进程，都不能完全确定它是做什么的，也不能因此就认定它是撞库的来源。持着怀疑的态度提了一个阿里云的工单，质问进程的作用。

这时候突然想起来唐人街探案宝强的一句话：
			排除了所有不可能，剩下的那个多不可思议

很快阿里云的售后给出了回复：

AliSecureCheck 是安全中心基线检查检查进程 弱口令基线检测项在检测过程中，由于使用了		 尝试登录的方式，会在系统日志中产生记录。 

具体您参考
https://help.aliyun.com/document_detail/140429.html?spm=5176.11065259.1996646101.searchclickresult.66dd49bcMs3qiH&aly_as=_tKRTgNc 文档

问题结果揭晓：
直到看了连接，才清晰的知道，原来AliSecureCheck是阿里云的安全基线检查，其实就是安全策略的测试。
描述截图：

结论：
因为阿里云的基线检查，所以才导致mysql errlog内产生大量的撞库日志。