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,详情请访问官网了解。