近日，大批MongoDB数据库再次遭受攻击。截至目前，被劫持的MongoDB服务器数量已经超过了26000台，黑客无需身份认证即可登录MongoDB实例，进行批量删除数据的操作。而UCloud研发的UDB MongoDB产品设计之初就出于安全性考量，均在产品层做了优化和强制安全措施，从根本上杜绝了实例遭受相应类攻击的可能性。

警惕开发漏洞 侥幸心理不可取

最让人痛心的是，黑客在此次事件中采用的手法与2016年底大规模MongoDB遭勒索事件完全如出一辙，因此从技术角度来讲，这一事件原本完全是能够规避的。但再次发生大规模劫持勒索事件，就不得不深刻探究背后的缘由了。

调查发现遭遇黑客攻击的MongoDB实例需同时具备以下两个条件：

• MongoDB实例免密码登陆；

• MongoDB实例开放了公网访问。

其实从根本上来看，发生大规模攻击事件源自MongoDB设计之初的一个漏洞。而熟悉MongoDB的技术人员也不难发现，漏洞存在已久，并且技术角度来看并不复杂。

为了让开发者能够更快地上手使用，MongoDB免去复杂的连接配置和鉴权，默认无鉴权设置（即免密码即可登陆）。同理，其他类型的数据库，比如MySQL，只要配置了允许免密码公网IP访问，同样会存在遭遇攻击的风险。

遭受攻击的原因如此简单，如果说第一次被攻击是因为警惕性不高、运维能力薄弱，那么第二次被大规模MongoDB劫持造成巨大损失，则完全就该归咎于自身安全意识太薄弱。

UDB MongoDB保障措施 放心的 UCloud NoSQL服务

针对上述两个触发条件，UCloud研发的UDB MongoDB产品在设计之初就将安全性放在首位，均在产品层做了优化和强制安全措施，从根本上杜绝了实例被攻击的可能性。

针对第一个条件，MongoDB产品强制要求鉴权，UCloud的客户在申请云MongoDB产品时，必须输入复杂度足够的root密码，后续任何情况下连接云MongoDB时都需要输入正确密码和鉴权database名称，并且同一套集群采用KeyFile认证机制。

针对第二个条件，MongoDB产品没有提供公网IP，所以连接MongoDB实例的操作都必须在同一区域、同一账户下的云主机UHost产品上通过该MongoDB内网IP进行访问，即UCloud的MongoDB产品是完全实现VPC内网隔离的，并且在配置文件中强制设置了bind_ip值为该MongoDB实例的内网IP。

另外，UDB MongoDB即使遭遇了其他黑客攻击，数据也不存在被勒索的可能性，UDB MongoDB提供了完整的数据备份机制，确保数据安全性。

鉴权设置作用突显 教您一招击破“瓶颈”

“鉴权”不仅是MongoDB产品强制要求的，而且在遭受攻击时作用突显，但许多MongoDB开发者并不使用鉴权。经过分析，无外乎三方面原因：

1 、小白用户使用MongoDB默认配置，默认无鉴权设置；

2、 部分用户缺乏安全意识，对该服务重视度不够，未能完成相关设置；

3 、部分用户担心鉴权操作带来性能损耗，未完成相关设置。

对于第一点和第二点，这里就不再说了，主要针对第三点做下说明：

第三点影响确实存在，而且在某种情况下还会成为系统瓶颈，MongoDB 3.0以后的版本，默认采用SCRAM-SHA-1鉴权机制，关于该鉴权机制的介绍请参考官方链接（https://docs.mongodb.com/v3.0/core/security-scram-sha-1/#authentication-scram-sha-1）。

通过查看SCRAM-SHA-1的代码实现（src/mongo/crypto/tom/sha1.c），可以发现其中涉及较为复杂的哈希计算，从而在高并发短连接的情况下，导致系统CPU飙升，造成系统瘫痪。该场景下执行perf命令时，典型截图如下，可看到系统瓶颈在鉴权过程。

优化思路也很清晰，将业务连接方式改为使用连接池的长连接方式即可。

UCloud研发的UDB MongoDB从安全性上进行考量，进行优化并强制采用安全机制，保证了客户数据库实例及数据的安全性。