摘要MongoDB漏洞是如何发生的？应怎样防护？近期，陆陆续续发发生一些自建MongoDB被“黑客”攻击，数据被删，并且索要Q币的案例。漏洞是怎么发生的？我们先来复盘看看。

 

 

MongoDB漏洞是如何发生的？应怎样防护？近期，陆陆续续发发生一些自建MongoDB被“黑客”攻击，数据被删，并且索要Q币的案例。漏洞是怎么发生的？我们先来复盘看看。

被黑者特征

本次事件的作案手法实在是称不上高级，所以我暂且称他们为“坏人”，但这事不能完全埋怨“坏人”，被攻击的这些自建MongoDB，全部都满足两个特征：
1. 暴露公网地址，甚至有些实例端口号都是默认的27017；
2. 没有配置鉴权约束，谁来都可以访问；

怎么攻击的

这就是把自己家的大门敞开，任由“坏人”搜割，“坏人”会做几件事：
1. 访问shadon网站，本来这个网站是做互联网数据分析的，原理是扫描全球IP和端口，通过分析协议来收集各种设备或者服务的统计数据。不幸被人利用，这些“坏人”甚至连端口扫描都不用，shadon都为你准备好了；
2. 用mongoshell等管理工具尝试登入，因为很多人的MongoDB都没有配置鉴权，所以连破解密码都的步骤都可以省了；
3. 单独破坏数据库意义不大，一般都是把数据dump到本地留存一份，或者直接修改集合名称或者地址，存在一个相对隐蔽的地方；也有“坏人”纯恶意破坏；
4. 勒索受害人，索要Q币或者比特币，交钱放“人”（归还数据，如果有的话）；

该埋怨谁

看吧，实在不是很高明的手段，也真的不能完全埋怨“坏人”不讲情理。这事情责任三方各打一板，怎么是三方？
1. “坏人”责任50%，勒索良民；
2. 自己责任40%，谁叫你公网地址，谁叫你不配鉴权的？大门敞开，家里被盗，上哪都喊不了冤；
3. MongoDB责任10%，说起来有点冤，但默认配置就应该强制要求鉴权访问，并且这事情也是需要官方不断去教育用户（虽然官方英文文档明确有写明要配置鉴权来保障安全），但不能指望人人都有安全意识；另外，MongoDB 3.0开始修改了鉴权协议，不支持2.x的Driver，很多用户也因此懒得去升级客户端，索性不要鉴权；

亡羊补牢

事实已经发生了，埋怨没有用，怎么解决：
1. 不论你有没有中招，有没有在公网，都要检查鉴权配置，避免更多的损失；
2. 关闭公网的访问入口，把门关上；
3. 如果你是阿里云用户，尝试恢复ECS存储镜像，有多少算多少；但是有一定的风险是镜像恢复了，但数据文件可能是不完整的，用MongoDB的repair命令尝试修复，祈祷吧；
4. 碰碰运气，看看数据表是不是只是被rename了，因为数据dump是有时间成本和存储成本的，有监控数据的可以对比下看看容量有没有变化；
5. 心有余孽的话就快点用阿里云MongoDB；

还是来用阿里云的云数据库MongoDB吧

阿里云的云数据库MongoDB从设计之初就重点考虑了安全问题，所以整个服务提供上我们具备：
1. 基于云数据库MongoDB 3.2兼容版本的解决方案，并且强制要求鉴权，并且默认不提供公网入口。还在用2.X版本的同学们尽快升级吧，各种原因可以参考另一篇文章，《告别 MongoDB 2.x 拥抱 3.x 版本的5大理由》；

2. 阿里云提供云数据库MongoDB的VPC能力，即使在阿里云内网，也可以网络隔离；

3. 云数据库MongoDB提供白名单功能，只接受你自己的ECS访问；
4. 重点的来了哦，这可是自建没有能力，增量数据备份与恢复，哪怕被人删了，或者自己不小心drop了，可以恢复到任意时间的数据状态；
5. 重点的又来了，这可是官方企业版的能力，完整的审计日志，被谁删的，怎么删的，数据哪里去了，一清二楚；
6. 阿里云安全专家众多，“攻击者”也是看风险和收益比的；
另外，值得一提的是，因为PHP这种高级语言，对数据库的操作都是短连接，所以鉴权开启后会带来大量的性能损失（主要影响并发能力），云数据库MongoDB也在这方面做了优化处理，针对短连接场景，阿里云有10倍性能优化。同时，也提供上云在线迁移服务DTS，详情请访问官网了解。