返回 登录
0

超2.6万台服务器遭劫持 UDB MongoDB零漏洞全防御

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

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

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

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

1、 MongoDB实例免密码登陆;

2 、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开发者并不使用鉴权。经过分析,无外乎三方面原因:

一、小白用户使用MongoDB默认配置,即本身就不鉴权;

二、部分用户缺乏安全意识,该服务也并不那么重要,于是就偷懒了;

三、部分用户怕鉴权操作带来性能损耗。

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

第三点影响确实存在,而且在某种情况下还会成为系统瓶颈,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从安全性上进行考量,进行优化并强制采用安全机制,保证了客户数据库实例及数据的安全性。

评论