1. 云栖社区>
  2. 博客列表>
  3. 正文

MongoDB黑客赎金事件解读及防范

场景研读 2017-01-18 15:13:37 浏览7390 评论2

MongoDB 容灾

摘要: 近期关于MongoDB黑客『赎金事件』闹得沸沸扬扬,不少裸奔的公网MongoDB纷纷中招。在本次云栖社区举行的在线直播中,阿里云数据库组技术专家郑涔详细解读了黑客赎金事件来龙去脉,以及用户使用MongoDB时需要采取的安全防范措施;同时也向大家介绍了阿里云数据库MongoDB服务在安全方面工作和相关功能。

直播回顾视频:https://yq.aliyun.com/edu/lesson/play/552


最近,全球互联网圈子内发生了一件大事:MongoDB数据库被黑事件,被黑掉的MongoDB数据库中所有的数据都内黑客洗劫一空,并留下信息勒索,要求支付比特币来赎回数据。截止到目前,受害者数目还在不断增加。为了更好地解读该事件,首先对MongoDB进行简单介绍,MongoDB数据库是NoSQL的文档型数据库,在DB engines排名中处于第四位。MongoDB最大的优势在于拥有灵活的表结构以及高可用、高可扩展的特性,因此MongoDB深受初创公司的喜爱。

黑客赎金事件回顾

7a907bed00944f3a98d15f527e6776c37947414a

此次MongoDB数据库被黑事件最早由白帽子VictorGevers@GDI Foundation(网名0xDUDE)在2016年12月27日发现,他发现有些在公网上暴露的MongoDB被黑掉,数据库中的数据都被删掉,并且黑客创建了一个WARING数据库(其中包含一张WARING表),其中的文档要求用户发送0.2个比特币到某个地址,然后再通过Email将IP地址发给黑客,黑客再进行相应的数据恢复工作。

在接下来的时间中,陆续有更多的MongoDB数据库被黑事件曝光。该事件最早是由Harak1r1黑客组织发起的,后续有多达20+黑客组织跟进,他们勒索的赎金从0.1到1比特币不等,短短数天时间已有约3W+MongoDB中招;据不完全统计,3天之内被删除的MongoDB数据量超过100TB。

原因分析

为什么会有这么多MongoDB数据库被黑客黑掉呢?是因为MongoDB不安全吗?

fe756eaacb5b0f19bba1e6594b492e2cc33ac89a

事实上并非如此,导致这次事件的直接原因:一是因为攻击成本太低(此次攻击的手段其实很初级),此次受到攻击的MongoDB用户共同的特征就是受害者没有配置鉴权,并且暴露在公网上,同时使用默认端口,导致门户大开;另外一个直接原因是获取受害者的成本很低,黑客通过SHODAN搜索引擎可以快速地获取暴露在公网上的MongoDB受害者的信息(该搜索是无辜的)。

但究其根本原因无外乎两者:一是被攻击者安全意识薄弱;二是MongoDB自身设计的缺陷,它默认配置没有开启鉴权。

了解到被黑的原因后应该如何应对呢?首先,使用者需要查看自己管理的MongoDB是否中招,可以从三个方面入手:一是验证数据库和集合是否还在;二是检查用户列表,看是否添加了异常的用户;三是检查系统日志看是否有来自异常IP的连接,也可以通过监控系统查看磁盘使用量等操作进行确认。

对于已经中招的MongoDB用户,我们的建议是:首先不要轻易支付赎金,除非有证据表明黑客确实备份了你的数据(据统计,有部分用户已支付赎金,但数据却没有得到恢复);其次,尝试数据恢复,通过备份(如果有)或文件系统快照(如果有)或其他数据恢复手段。

MongoDB安全Checklist

之所以有大量的MongoDB数据库被黑,首要原因就是因为没有开启鉴权功能。下面将从MongoDB支持的鉴权机制、基于角色的访问控制、内部鉴权(Keyfiles)、Sharding集群的鉴权、鉴权的开销、如何开启鉴权等方面详细介绍MongoDB的鉴权功能。

MongoDB支持的鉴权机制

505e6142d6fad3bf7ed67e8d189780489aaaf809

MongoDB的鉴权是基于用户名和密码完成的。在MongoDB 3.0以前版本中使用的是MongoDB-CR的鉴权协议。该机制略简单,对密码做了一个摘要,然后在服务端通过相同的方式验证,安全性不高。在3.0版本以后,使用的是SCRAM-SHA-1鉴权机制,该机制双向验证,同时验证客户端及服务端的身份,安全性较高(强烈建议使用3.0以后的版本),但该协议不兼容旧的客户端,旧的客户端使用该协议时需要进行版本升级。

除了用户名和密码之外,MongoDB还支持x.509证书鉴权,但该方式较为复杂,此处不再深入介绍。

基于角色的访问控制

9a86936f089b3bd15c825975e636b286b8f147b5

在MongoDB中有几个基本概念:User(用户);Role(角色)是权限的集合,可以继承;AuthenticationDatabase即鉴权数据库,用户在哪个库创建就指定在哪个库进行鉴权。

使用者可以通过Mongo Shell在某个数据库创建一个用户并指定具体权限,如通过以下指令创建一个root角色的用户:db.createUser({user:’用户名’,pwd:‘密码’,roles:[role:’root’,db:’admin’]})

MongoDB数据库可以实现非常精细的权限控制,除了ROOT角色之外,还有很多预先定义的内建角色,如只读数据库角色等;此外,如有特殊需求时,用户可以自定义角色。

内部鉴权

在MongoDB中,副本集及Sharding集群成员之间也需要鉴权,所有成员之间通过相同的Keyfile内容来实现内部鉴权。Keyfiles生成内容可以有很多种方法,但是要求内容必须是base64编码的字符,长度介于[6,1024]之间;此外,需要注意Keyfile文件不能拥有group和other的权限。

事实上,副本集及Sharding集群成员之间的鉴权也是通过SCRAM-SHA-1机制完成的,内部鉴权的用户名是__system,鉴权数据库是local数据库。

Sharding集群的鉴权

Sharding集群的鉴权和副本集鉴权有一定的区别:副本集在Mongod上鉴权,Sharding集群在Mongos上进行鉴权。Sharding集群鉴权时,通过连接Mongos来创建/管理用户;2.6版本以后,用户是保存在Config Server上的Admin库里。在某些场景中,需要直连Shard的一些特殊操作,如cleanupOrphaned/compact/rs.reconfig()等,这种情况下需要在Shard上创建用户,注意这些在Shard上创建的用户是无法通过Mongos来连接的。

鉴权的开销

b7cc822dc854d6488f827c70fa9569f459952753

开启鉴权势必会带来性能的开销,这是因为鉴权通常需要客户端和服务端进行一些网络交互以及CPU计算,比如SCRAM-SHA-1机制会在客户端和服务端进行一定迭代次数的Hash计算。对于长连接来说,这些性能开销是可以忽略的,因为长连接建立之后只需要一次鉴权即可进行多次操作;但对于短连接,会对性能有一定影响,因为每次操作都新建连接,都需要进行一次鉴权(这里可以考虑使用阿里云MongoDB,因为我们队鉴权的性能做了优化,效果能够达到原来的10倍)。鉴权所导致性能开销和带来的安全效益两者相比,显然后者更为重要,毕竟安全是性能的基础。

如何开启鉴权?

鉴权的开启步骤较为简单:

  • 在配置文件中,通过指定security.authorization:enabled和keyFile:<path-to-keyfile>两个配置项,前者是打开基础鉴权,后者是配置副本集及Sharding集群成员内部鉴权。
  • 如果不使用配置文件,直接通过命令行启动,则通过增加--auth和--keyFile <path-to-keyfile>参数即可。

需要注意的是,鉴权开启之后,需要通过本地Localhost进行连接服务器去创建第一个管理员用户,建立管理员用户之后才能建立其他的普通用户,而且MongoDB需要重新启动。

除了鉴权之外,为了防止黑客攻击,还需要进行其他的安全防护措施:

  • 修改监听端口,即不使用默认27017端口。
  • 限制访问来源,用户可以通过net.bindlp选项配置监听IP(MongoDB默认绑定在所有网卡上监听IP),此外,可以通过防火墙之类的安全组限制对外暴露的端口。
  • 不要使用Root权限账户启动进程,最好使用单独的用户启动进程,避免高级黑客通过某些手段获取主机root权限。
  • MongoDB默认具有Http相关的接口,用户可以通过Http的方式查看MongoDB相关的信息,并且可以通过一些REST API进行某些操作出于安全起见,在生产环境下,需要关闭Http相关接口,具体配置方式:
    •  net.http.enabled:false
    •  net.http.JSONPEnabled:false
    •  net.http.RESTInterfaceEnabled:false

除了上述操作,为了安全起见,还可以对数据进行加密,将业务数据先加密后再存放到MongoDB中,避免数据泄露。

容灾

在此次MongoDB数据库被黑事件中,数据基本上都被黑客删除了,因此除了做好鉴权等安全工作之外,还需要对数据做好容灾,通过一些手段对数据进行定期备份;或者也可以通过配置一个MongoDB的延迟副本集节点来简单起到备份的效果。

备份和恢复

备份又分为全量备份和增量备份。MongoDB目前支持的全量备份有两种方式:一种是通过mongodump进行逻辑备份(使用mongorestore进行恢复);另一种是基于文件系统快照或其他手段进行物理备份。

增量备份主要采用抓取oplog的方式实现,这需要用户自主开发抓取oplog的程序。

配置延迟副本集节点

c448522fdf71ede94b0992726e28594b0e7f19ed

在MongoDB中,可以指定某个节点配置成比Primary节点最新数据固定延迟一段时间的节点以备数据恢复用,例如可以配置一个比主节点晚一个小时的节点,如果黑客在一个小时内将数据删掉,则可以通过该节点将数据恢复。

阿里云MongoDB服务

6d893e58f335eccbfca1070030a2084fd5f85e8d

阿里云MongoDB服务强制要求开启鉴权,同时对MongoDB自身的鉴权进行了优化,使得鉴权性能提升10倍;同时开放用户管理功能,最大程度保留灵活性。目前,阿里云MongoDB只允许内网访问(只允许在云ECS上访问云MongoDB),避免对外暴露IP;同时还支持VPC,可以将MongoDB配置在VPC中;此外,还支持IP白名单,只有指定的IP才能访问数据库,大大提高了安全性。

审计

729889bb609e2b63609561997a87b26ba332b04a

阿里云MongoDB服务还实现了审计功能,可以记录所有操作、来源、耗时 。上图是审计结果,可以看到在11:00:48时,某个用户执行了Drop表的操作,客户端IP和消耗时间都有记录。当数据库内数据被删除时,可以通过审计日志查看操作者的信息以及发生时间(审计日志查看功能目前还未对外开发,下一步计划开放)。

自动备份/恢复

阿里云MongoDB服务提供了自动备份/恢复功能,目前实现了全量和增量备份。用户通过阿里云MongoDB可以恢复到任意时间点。

总结

为了避免MongoDB数据库被黑客入侵,用户需要开启鉴权,利用MongoDB强大的权限控制功能,遵循权限最小化原则进行用户管理;修改监听端口和限制访问来源来预防MongoDB暴露在公网上;另外不要使用ROOT启动进程,并注意关闭HTTP相关的接口。

除此之外,还需要做好容灾,定期进行全量备份;有条件的做增量备份,或者配置延迟副本集节点。如果,既想省心,又想保证MongoDB数据库的安全性,建议采用阿里云MongoDB服务。


延伸阅读:

也可以扫描图中的二维码阅读相关文章!

——————————————————————————————————————

关于分享嘉宾:

郑涔,花名明俨,阿里云数据库组技术专家,主要关注分布式存储、NoSQL数据库等技术领域,目前主要参与MongoDB云数据库的研发,致力于让开发者用上最好的MongoDB云服务。

版权声明:本文内容由互联网用户自发贡献,本社区不拥有所有权,也不承担相关法律责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件至:yqgroup@service.aliyun.com 进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容。

用云栖社区APP,舒服~

【云栖快讯】数据库技术天团集体亮相,分享一线生产实践经验,告诉你踩过的坑、走过的路,都是老司机,靠谱!干货分享,不可错过!  详情请点击

网友评论

1F
山东宸旭

数据库安全意识需要加强防范!

2F
jay120

极佳数据库恢复公司可以做 mongodb数据库恢复 开发的有程序上次我们的mongodb被删除了 找他们恢复的 有案例 http://www.sql110.com/2017/0104/636.html