首页 ›存档› 技术 › 查看内容

工程师们注意，MongoDB 0day漏洞来了前言漏洞原因分析 UCloud UDB MongoDB的保障措 ...

2018-3-30 13:00 |来自: 互联网 352 0

摘要: 前言近期，大批量的MongoDB实例因为配置漏洞遭遇了攻击，黑客无需身份认证即可登录MongoDB实例，从而删除了大量数据，并勒索受害者支付赎金才能要回自己的数据。截止目前为止，被劫持的MongoDB实例已经达到了一个惊 ...

前言

近期，大批量的MongoDB实例因为配置漏洞遭遇了攻击，黑客无需身份认证即可登录MongoDB实例，从而删除了大量数据，并勒索受害者支付赎金才能要回自己的数据。截止目前为止，被劫持的MongoDB实例已经达到了一个惊人的数量。更加可恶的是，黑客在删除完业务数据库后，在里面的数据库留下了这段嘲讽敲诈的文章。UCloud君简单翻译了下：“你的数据库可以通过公网IP免密码登陆，你tmd的是怎么想的？”吓得UCloud君迅速针对这个漏洞去检查了下自家的云MongoDB产品，确认并无遭受攻击的风险。

漏洞原因分析

其实熟悉MongoDB的同学会不难发现，漏洞原因非常简单，而且由来已久。从根本上说，这其实是MongoDB在设计之初的一个小疏忽。MongoDB为了让开发者能够更快地上手使用，支持免去复杂的连接配置和鉴权方式的做法，默认情况下是无鉴权的，即免密码即可登陆。同样的原理，其他类型的数据库比如MySQL，只要配置了允许免密码公网IP访问，同样会存在遭遇攻击的风险。

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

MongoDB实例免密码登陆
MongoDB实例开放了公网访问

通过上述的原因分析，一般都是以下两种原因引发了悲剧：

MongoDB使用者安全意识不高（认为数据可有可无，并非关键性服务）
MongoDB使用者的运维能力薄弱，根本没想到这一点

UCloud UDB MongoDB的保障措施

针对上述的两个触发条件，我们UCloudUDB MongoDB产品在设计之初出于安全性的考虑，均在产品层面做了优化和强制安全措施，从根本上杜绝了实例被攻击的可能性。

针对第一个条件，MongoDB产品强制要求鉴权，使用过我们UCloud UDB MongoDB产品的客户知道，客户在申请云MongoDB产品时，必须输入足够密码复杂度的root密码，后续任何情况下连接云MongoDB时都需要输入正确的密码和鉴权的database名称。

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

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

云主机UHost上自建的MongoDB如何修复

建议您使用我们的UDB MongoDB，我们的云MongoDB产品文档链接如下： https://docs.ucloud.cn/database/udb-mongodb/index
对现有的云主机UHost自建MongoDB进行安全加固，步骤如下：

开启密码认证方式访问MongoDB（如果是副本集或mongos集群建议使用keyfile认证， UDB默认使用keyfile）;
禁止通过公网IP访问MongoDB（即在配置文件中设置bind_ip为该云主机的内网IP或127.0.0.1）;
已经使用鉴权的，建议将密码修改为足够的复杂度，排除被暴力破解的可能

如何从云主机迁移到云MongoDB

一般MongoDB的迁移上云的策略都是通过副本集的高可用性来实现，不过需要首先保证网络的连通性（这一点一般云计算厂商都会负责或协助打通）。通过将云DB作为自建DB的Secondary节点，当两边的数据达到完成一致，确认数据正常后，手工做一次高可用的切换，使得服务整理从自建DB切换到云DB。当切换完成后，云DB可成功选举成为新的Primary节点，这时即可在新的Primary节点上rs.remove移除自建DB节点，从而实现了MongoDB上云的平滑迁移。下面已自建的MongoDB是三个节点组成的副本集为例，现在想迁移到云上，步骤如下:

1、打通目标库和源库之间的网络。这一步不做详细讨论，简单地说，假如源库本身就布置是在云服务商所在的云主机上，那么一般来说同一账户下的资源，网络已经是打通了的；假如是从其他IDC机房迁移到云MongoDB上，可以通过做一次代理的方式实现网络互通。

2、建立源DB和目标DB的副本集，以源库作为主节点，目标库作为从节点，建立主从进行复制。这里还需要注意的是保证账户鉴权方式一致，即auth是否都关闭或者开启，保证副本集名称（replSet）一致，保证各节点使用的keyfile一致。三方面任何一个节点务必保持一致，不然无法正常同步。假设源DB为三个节点的副本集，现在想迁移到云上，那么需要做成的副本集结构图如下：

3、待同步完成后，check从节点数据完整性后，将这几个目标DB的IP添加到副本集连接字符串URI中，重启应用层连接客户端。

4、选择云上的某个从节点作为主节点候选节点，提高它的选举优先级，人为触发副本集的选举过程（具体操作参加rs.reconfig()）。这样就可以将MongoDB云数据库中的一个Secondary节点提升为新的Primary节点，提升完成后的结构图如下。

5、确认业务正常，数据没有问题后，将这几个源DB的IP从副本集连接字符串URI中删除，重启应用层连接客户端。

6、登录到MongoDB云数据库的Primary节点中挨个删除自建DB的数据节点，这样就只保留了云数据库的几个节点。

7、迁移完毕。

以上过程可以平滑迁移到云数据库上，其实在步骤3、步骤5还有一定的优化空间，可以预先配置好URI，包括变更前URI、中间态URI和变更后URI，不同阶段使用正确的URI配置文件，启用或者关闭对应的应用层连接客户端，这种策略可以缩短对业务的影响时间。