发现问题
今天下午15时左右，跟往常一样登陆后台查看信息，在输入账号密码后居然发现提示账号密码不正确！第一次以为自己输入错误，但接连输入几次后发现都是错误，心里顿时毛骨悚然，mmp的，难道那么快就被hack掉了？？赶紧远程服务器！！
处理过程
在登陆服务器后第一件事就是history判断服务器是否被get shell，然而却发现并没有可疑的操作，当然也有可能被擦除掉，但我相信这个可能性比较低。由于不清楚危险等级，所以只能把web服务先关闭，换成正在升级的公告，这也是为了避免不必要的影响。
关闭服务器后，马上查看运行日志，第一顺序就是判断后台是否沦陷，使用正则提取POST/GET到后台地址的记录，发现条数并不是很多，而且查看今天操作的时间也跟自己操作的时间重合，昨天只有三条记录，看着这心里顿时松了口气，由此可见后台地址的重要性，这也是用户数据的最后一颗稻草。
然后查看一下日志的记录大小，没把我吓一跳，39W+的记录，我就是对黑塔项目再自信也不认为两三天内能产生那么多正常的访问记录。
接着为了分析日志方便，我把几十兆的日志文件从服务器上拉了下来，欣慰的是下载速度能达到2M左右，所以也没耽误什么时间。用UE打开后，随便一拉就发现了某用户（这里之所以说某是因为后面通过日志发现了他）在激活页面疯狂提交重置
admin密码的验证码，好家伙，足足爆破了3个小时左右，接近10W条记录。
为了更清晰的还原他的操作，继续分析日志，此时重点就在爆破前和爆破后的日志记录了，先翻到爆破前，发现此用户尝试注册
admin用户，但提示用户存在，注册失败！接着根据日志，他跑到了重置密码页面，一开始使用admin + 他的邮箱重置密码，但这肯定不行。这时，他灵光一闪【奸笑】，想到了他注册时给他发送邮件的邮箱，这也正是admin的邮箱！！然后，他再使用重置密码，但激活码发送到了admin的邮箱，这才出现了39W+的爆破记录，很明显，这将无疾而终。但他成功的把admin的账号给冻结了，导致一开始出现的admin用户无法登陆现象。
总结和修复方案
可以看到，整件事的产生都是因为admin信息的泄漏，而admin及其邮箱都是本地开发时使用的调试信息，在上线前，作者对系统中用户可控的各个输入点都进行了严密的过滤，但却没能防止敏感信息泄漏。所以，在以后的开发中，一定要注意调试环境跟生产环境间敏感信息的保护，像拿到调试环境所泄漏的敏感信息从而攻克整个生产系统的案例并不少见，如默认用户、test用户等。
修复方案：
- 删除默认管理员账号，禁用诸如
admin、root用户名作为管理员账号； - 对提交页面做次数限制，防止恶意爆破，就算不能爆破成功也要减少系统开销；