MongoDB勒索事件中，DBA们到底该学到什么？

本文主要是介绍MongoDB勒索事件中，DBA们到底该学到什么？，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

一些安全战略师表示这次MongoDB事件是意料之中，甚至还有人不解“***者为什么等到现在才开始下手”。在一些技术实践者看来，最大的安全问题，很可能源自不规范的使用，而不是MongoDB。

作者 | Sean Michael Kerner、360 DBA 组 编辑 | 大愚若智、木环  

事件回顾

无须身份验证的开放式MongoDB数据库实例正在遭受多个***组织的***，被攻破的数据库内容会被加密，受害者必须支付赎金才能找回自己的数据。

***者利用配置存在疏漏的开源MongoDB数据库展开了一系列勒索行为。此番针对MongoDB的勒索行为最早是由GDI Foundation的安全研究人员Victor Gevers在2016年12月27日发现的，在这之后影响陆续扩大，目前至少有五个不同***组织控制了上万个数据库实例。

截至目前，最后一个加入此次MongoDB勒索行动的***组织是由安全研究人员Nial Merrigan在1月6日发现的。目前，MongoDB***者的身份信息只有用于支付赎金的电子邮件地址，最新加入的***组织所用的邮件地址为3lix1r@mail2tor.com，该地址已攻陷至少17个MongoDB实例，要求受害者支付0.25个比特币才能找回数据。

目前在Google Docs上有一个列表，其中列出了参与此次***的***组织名单，具体数量还在增加中。***者所要求支付的金额各异，最低仅0.15个比特币，但也有高达1个比特币的赎金。2017年至今，比特币的价值上下波动，截止1月6日，具体金额约等于892美元。

此次针对MongoDB的***非常简单，利用了配置有误且可公开访问的数据库，无须具备相应的管理员凭据即可展开***。一旦***者登录到开放的数据库，随后会全面夺取控制权并窃取或加密数据库，被勒索的受害者必须支付赎金才能找回自己的数据。

很多MongoDB数据库处于开放状态，这种情况早已存在。2015年12月，安全研究人员Chris Vickery就曾使用Shodan搜索工具找到了很多端口开放的MongoDB服务器。当时Vickery甚至找到了一个被Mac OS X工具软件MacKeeper的开发者Kromtech使用的，配置存在疏漏的MongoDB数据库。

Shodan的创始人John Matherly跟进了Vickery的研究结果，并在2015年12月称，当时互联网上共有至少35,000个可公开访问，无须身份验证的MongoDB实例。一年过去了，直到2017年1月，开放式MongoDB数据库的数量不降反增，估计目前共有多达99,000个数据库处于风险中。

作为应对此次MongoDB安全隐患的有效措施，数据库管理员需要参考MongoDB网站上提供的安全清单进行排查。首先需要“启用访问控制并强制进行身份验证”。

安全研究人员对eWEEK表示，MongoDB被***者进行勒索完全在意料之中。

“考虑到MongoDB的流行度以及在生产环境中的普及率，以开源的数据库作为目标并不会让人惊讶。”Dome9共同创始人兼首席执行官Zohar Alon向eWEEK说到：“通常来说，数据库部署过程中的配置疏漏和疏忽就会导致可被***者利用的弱点。”

Alon还补充说，用户的人为错误与不够强的安全意识也会威胁到云环境中运行的工作负载。他建议在使用开源数据库等第三方软件之前，用户应该自学相关知识，掌握最佳实践和已知弱点等内容。

“有趣的是，大部分人认为数据库是足够安全的，因为可以受到防火墙和数据中心的保护，”Jean-François Dubé首席技术官RiskVision告诉eWEEK：“问题在于***者依然可以通过消费者所用的端点和第三方连接访问这些服务器并获取信息。”Dubé的总体建议是应当定期对数据库进行风险评估。“使用风险评估工具对数据库进行近乎实时监视的企业，会在加密后的数据离开数据库时更清楚地发现这一切，”他说。

Mimecast公司网络安全战略师Matthew Gardiner评论说，此次MongoDB被***完全没有让他感到意外。“一处开放的，无须身份验证的，存有宝贵数据的系统，或其他任何重要的系统，被互联网将规模放大上千倍后，最大的问题在于：***者为什么等到现在才开始下手？”Gardiner说。

国外的安全人员给出了一些宏观上的数据库策略，那么有没有直接针对MongoDB具体操作方法呢？

360 MongoDB概况:目前，360 维护的 MongoDB 实例数量达2000+，日访问量达300亿次。在 360 看来MongoDB 是一个流行的数据库，如果能够进行合理使用，不会遭遇这次突发的窘境。360 的 DBA 同学分享了他们的 MongoDB 成套管理策略；在他们看来其实可以通过以下八招免除勒索威胁。

以下内容来自360技术人的实践心得。

我们都知道 MongoDB 的默认端口为27017，那么说明***们也都知道啊。那么会怎样呢？这意味着***想针对 MongoDB 进行扫描那么可以直接看你的27017是否开放；而在他进行大范围的端口扫描时一旦发现27017开放就可以粗略的认为他发现了一个 MongoDB！所以，不使用默认端口虽然无法杜绝***的***，但可以相对增加***难度！因此我们建议大家维护的任何MongoDB都不要使用27017这个默认端口。

一个暴露在公网的端口可能每天都会经历无数次的恶意扫描，风险巨大。但，一个内网的端口就好太多了，***想要侵入你的内网端口难度明显高于外网，起码先得攻破堡垒机对吧？所以建议大家的 MongoDB 都只监听内网端口屏蔽公网端口的请求，通过该策略继续增加***的***难度。

不知道大家是否还记得之前一样闹得沸沸扬扬的Redis漏洞。当该漏洞被利用时，如果你的进程使用了root用户来进行启动，那么***可以通过漏洞并配合这一点对你造成更大的伤害。这个伤害很可能是爆击效果（不可恢复的严重故障），***甚至能够通过该Redis实例继续***至服务器环境、内网。这种问题对DBA、运维、公司带来的伤害都是极大的。但大家又真的很委屈，这种突如其来的bug谁又能提前料到呢？我们虽然无法确保我们使用的软件没有bug，但我们可以通过类似措施增加第二层防线来降低bug暴漏后的风险，同时给我们更多的喘息时间来修复bug！不只是MongoDB，我们建议大家维护的所有db都使用禁止登录的非root用户启动。

毫无疑问这是必须必须必须要加的，如果你看到这里但不认同我的观点那么请直接关掉本页。在报道中，那些被勒索的 MongoDB 管理者可能都没有为他们自己的 MongoDB 开启验证。你想象一下，没有开启验证的 MongoDB 就好比失去了免疫系统的人类（艾X病），这是多么脆弱的状态？所以当一个MongoDB上线后，第一件事就是启用验证。我们建议使用 MongoDB 官方建议使用的 keyFile 参数来开启验证功能，他的好用可靠性无需多言，官方文档写的很清楚。在360内部，其实最大“***者”来自于360信息安全部，他们有各种扫描工具24小时不停的对所有服务器的端口进行扫描。很多年前（2012年前）我们的 MongoDB 也没有开启验证，于是我们的信息安全部向我们的 MongoDB 里写入了大量的乱七八糟的但又不会影响业务东西，对 DBA 造成了极大的困扰。因此，在信息安全部 7 * 24 小时的"鞭策"下，我们维护的 MongoDB 全部都启用了验证。回想起当时的被迫调整，无论是DBA还是使用了MongoDB 的业务开发都是非常的痛苦。因为从无验证到有验证，要测试代码的兼容性、性能变化等等一系列连锁问题。大家最初都是抵触的，甚至会怀疑认为信息安全部真是小题大做。但现在看来这真是英明的抉择，这些短期痛苦带来的长期安全性的提升是相当划算的！

可能我们通过以上几点已经近乎完美的杜绝了***。但是！万一DBA手潮怎么办？万一运维手潮怎么办？万一开发同学手潮怎么办？可能误删带来的痛苦远大于被黑，因为这是乌龙啊朋友们！简直痛心疾首是不是？你心情不好喝多了或是失恋一个简单的drop()只需要1秒即可执行完毕，而我可能需要几天的时间来进行恢复。所以权限的严格限制是非常有必要的，一套合理严格的权限控制方案可以最大程度的避免手潮误删带来的伤痛。我们建议大家针对自己维护的MongoDB设置一套适合对应业务的权限控制、分配方案。我们之前也对自己的权限控制策略进行了分享，标题为：《MongoDB 权限控制系统简介》这篇文章讲的非常详细，具体就不在这里详细阐述。备注：《MongoDB 权限控制系统简介》经360授权于1月11日刊发在【高效开发运维】微信公众号次条。（大家如果有兴趣可以查看该文章，希望能够给你带来一些帮助！）

作为数据库的管理者，不给数据库加验证可以切腹，那么不备份数据库就可以拉去游街了（罪不至死但绝对是职业生涯污点）。一套可靠的备份逻辑永远是你那钢铁一般坚韧的永远不会被拽断的救命稻草！无论发生什么，是被黑、还是误删、或是机房漏水、或是服务器报销，甚至机房被核弹炸毁，一套可靠的本地备份逻辑 + 远程备份存储方案都可以在以上场景救到你！我们对当前维护的MongoDB使用了多套备份策略：

• 实时增量备份 + 每天定时dump整备 : 该策略适合数据量不大的业务

• 实时增量备份 + 每天定时cp（拷贝式）整备 : 该策略适合数据量相对较大的业务

• 实时增量备份 + 按库/按表过滤式备份 : 该策略适合一个大库中只有部分重要数据的场景,例如一个90%数据都是日志的集群

• 实时增量备份 + 每天定时备份 + 延迟同步节点 : 该策略适合数据重要且对恢复速度要求较高的业务

另外以上策略全部都有异地存储策略，以应对机房的整体不可恢复灾难场景下的数据恢复需求。

有了完善的备份策略，恢复怎么办？多数场景下我们的恢复都是手忙脚乱的，一个DBA在恢复数据的时候背后很可能站着3个开发2个运维1个产品1个QA，压力大不大？所以建立一套能够覆盖多数灾难场景的恢复策略来避免我们的手忙脚乱是非常必要的。我们为极端场景的恢复建立了多套策略，这些策略建立在我们的备份策略基础之上：

• 通过增量备份进行恢复 : 适合需要恢复的数据条数不多的场景

• 通过整备 + 增量备份对库/表进行过滤式恢复 : 适合需要恢复的数据仅限某库某表的场景

• 通过整备 + 增量备份恢复到灾难前1秒 : 适合数据重要希望完美恢复的场景

• 直接通过备份 + 增量备份导入生成临时服务实例 : 适合db体积巨大，短时间内无法恢复但又无法中断业务太久的场景

• 直接切换到延迟从库 : 适合有延迟从库的集群且灾难发现较为及时的场景。

这几年总有断断续续的XX公司的db被***的消息，无论是真是假，大家的密码都改到吐血。

我们建议大家一定对任何敏感信息加密后再入库，例如：密码、邮箱、地址等等。

被***只代表***打开了你的第一层保险柜，但第二层保险柜的数据加密会对数据的损失降到最低。

敏感信息加密后入库也是对用户的负责态度！

到这里8招已经全部介绍完毕，看完的你应该已经明白，一个db的安全与db自身的安全配置、网络安全配置、系统安全配置、备份恢复策略密、数据存储策略密不可分。

最大的安全问题很可能来自部分不规范的使用者，而不是MongoDB。

所以此时你还认为MongoDB是那么的不堪么？其实几乎所有的db安全策略都是相通的、类似的、可以互相借鉴的，不是么？虽然通过以上策略我们仍然不能绝对杜绝***对我们的骚扰。但请你相信，勒索此时已离你很远！

这篇关于MongoDB勒索事件中，DBA们到底该学到什么？的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！