mongodb两次被黑后......

先说说事情的经过......

2017年1月8号星期天，在家翻头条无意中看到一条新闻说很多用户的mongodb被黑了，数据都被删了。当时想着公司的爬虫用的也是mongodb做存储，应该不会被黑吧，不可能这么巧，也没太在意。

1月9号周一来到公司，运营人员找我说数据一条都查不出来了，我当时心里一紧，回想昨天晚上看到的新闻，抓紧打开数据库一看，顿时傻眼了，“不会这么巧吧”。 数据库被删干净了，只留了一条信息

Your DB is Backed up at our servers, to restore send 0.1 BTC to the Bitcoin Address then send an email with your server ip  

抓紧上网查了下，果然很多人都中招了，留下的也是这一条信息。想想最后一次备份是在一个多月以前（因为数据库太大，备份太麻烦，所以没考虑到定期备份），简直想死的心都有。不过万幸的是只是抓取的网页数据丢了，其他之前配置过的一些重要的信息都存在了另一个SQL Server数据库中。被领导批过以后，老老实实的还原数据，加密码，重新运行爬虫。

其实之前考虑到放在公网上，也给mongodb加过密码。只是加了密码之后，另一个组的同事C#写的客户端就没法访问了，研究了两天也没解决，就和我商量着能不能先把密码去了，等他研究明白了再加上，不能因为这个影响了运营部门同事的工作了。当时想着我们这么个小公司，谁会没事黑我们啊，就暂时去了吧，等过段时间再加上。这样暂时去掉以后，就再也没有后来了......

等数据还原完以后，我拿起手机发了条朋友圈

2017年做了第一件SB的事，mongodb裸奔......

并在心里发誓，谁让我把密码去掉我也不去。

第二天一早，接到了领导的电话，“你把密码去掉吧”。原来负责客户端的那个同事还是没办法连上我加密码后的数据库，而他本人在客户现场驻场开发，抽不出时间来研究。领导的意思是说用bind_ip的方式来保证安全，既要能保证外网的访问，因为外网有两个程序需要连这个库，又要保证内网的任意用户能够连接，我说那这该怎么实现啊，当他说出“你自己研究啊，难道要我告诉你吗?”时，心里别提有多委屈了。

没办法，领导都下了命令，就必须执行。于是乖乖的把密码去掉，然后开始各种搜索怎么通过bind_ip实现只允许特定机器的访问。但是多次试验后，发现 bind_ip设置除了本机ip和127.0.0.1之外的地址，mongod服务就起不来了，查日志也是bind（） failed错误。于是加了几个群一问就被大神们笑话了，说你自己的机器去绑别人的地址肯定不行啊。这时我才意识到，我理解错了bind_ip的作用，一直以为这个设置是为了限制哪些主机可以访问本机数据库，其实bind_ip只能绑定本机有的ip地址，是监听的意思，是允许其他机器通过哪个地址来访问本机数据库。理解了这个，就明白了通过这种方式是无法实现我们的要求的。

后来听群里大神说可以通过在防火墙设置ip白名单的方式实现，我开始欢天喜地的去设置防火墙，还没等我设置完，运营人员发来了一条信息，“数据库又一条数据都查不到了”。看到这条消息我压抑住心底骂人的冲动再次打开数据库，数据又被删干净了，只留了这样一条消息

亲，您的数据库我们没有备份，但是如果你想放广告请支付0.1 BTC给我们

我气得手都有点哆嗦，一方面气世界上为什么会存在这样可气的不法分子，一方面气自己为什么不长记性，还一方面是气领导这样草率的决定。我颤抖着双手给领导发了一条信息，“你还是让XXX抽时间研究研究把密码访问mongodb加上吧，数据库又被黑了”。领导也很震惊，然后又说这边项目太紧抽不出人手，最后丢下一句“你自己想办法吧”，心灰意泠的感觉啊，恨不得自己学下C#把源码要过来自己改了。

最后多方协调，终于找人把外网访问的功能暂时屏蔽了，只允许公司内部访问，这样再被黑，我真的要砸键盘了。通过这件事，想到了很多：

1. 平常工作中增加安全意识，不能存在侥幸心理；
2. 数据库要定期更换密码和异机备份；
3. 认为正确的事要坚持原则；
4. 做一个正直的人；

人生就是一个不断挖坑、填坑的过程，不止要填自己挖的坑，还要填别人帮你挖的坑。