炙手可热的mongodb,安全吗?-k8凯发天生赢家

炙手可热的mongodb,安全吗?
作者:思成 发布时间:2017-12-31

mongodb是10gen公司研发的面向文档的开源nosql数据库系统,用c 语言编写。mongodb凭借简单的部署方式,高效的扩展能力、多样化的语言接口,并借着云蓬勃发展的势头,一度在全球数据库市场占据第四名。

01.jpg

安全问题综述

作为目前使用最广泛的nosql数据库类型,mongodb短时间内能够取得如此巨大的市场成功,内因在于其上述突出的特性。但正所谓成也风云,败也风云,这些特性同时也给mongodb带来了一定的安全风险。大致上,mongodb 的安全问题可以分为三个部分:

默认配置安全问题

本身安全问题

web安全问题

1、默认配置安全问题

默认配置问题是mongodb当前最为突出的安全问题。2016年底,mongodb勒索事件在全球范围内持续发酵,主因在于在默认部署情况下,mongodb无需身份验证,即可登录,不法分子只要在互联网上发现mongodb的地址和端口就可以通过工具直接访问mongodb,并拥有mongodb的全部权限,从而进行任意操作。之所以会如此设计,原因在于:

1. mongodb默认通过最简单部署方式,最大限度提高运行速度,以在虚拟机(低配机)上运行而定制的,并未充分考虑mongodb的安全性。

2. mongodb官方文档,如针对身份验证,传输加密,网络配置的文档、指南并不规范,容易误导mongodb管理员。

3. 一些mongodb环境是为了单一项目或者是测试环境搭建,搭建者并不关心mongodb的安全问题。

上述原因最终会导致互联网上出现大量完全开放且脆弱的mongodb。据调查,截止当前,我国互联网上易被发现的mongodb有7281个,其中部分仍可随意登录。要解决上述问题就需要对mongodb进行合理配置,其中,进一步配置的不仅是身份验证和网络控制,还有更多可能造成安全隐患的部分。

1)启动访问控制并强制进行身份验证

默认配置下,mongodb不需要进行身份验证即可登录。在mongodb部署上启用访问控制会强制进行身份验证,根据当前用户实际权限判断后续操作是否被允许。使用auth参数可以开启mongodb的强制身份验证,为保证auth的真正生效,需要同时在user中配置用户名和密码信息。开启auth能有效杜绝网上非法用户恶意访问和非法操作行为,保护mongodb中的k8凯发天生赢家。此处可以通过类似防火墙的身份验证,仅允许某些特定用户通过,防止非法访问行为。

2)限制网络访问

默认mongodb允许任意地址访问,勒索事件中的mongodb除了没有设置用户密码外,同样也没有限制可信网络访问。为了确保mongodb在受信任的网络环境中运行,需要限制mongodb实例侦听传入连接的接口,仅允许受信任的客户端访问mongodb实例。而限制外网的非法访问需要通过三个参数进行合理关闭:

通过-bind_ip限定可以访问的ip;

通过-port设置mongodb的端口(不要使用默认的27017);

通过-nohttpinterface 取消mongodb的web管理页面。很多mongodb用户不知道这个web管理页面,该页面无需数据库账号密码即可完成登录,从而查询一些mongodb的敏感信息;

关闭rest参数。该参数若开启,上面的web页面就可以直接对数据库进行更多操作。即使开启了强制身份验证,该web管理页面仍无需身份验证即可登录,所以一定要关闭rest并封死28017端口。

数据库防火墙能够对不可信ip访问进行封堵;对web端口(28017)进行部分ip禁用;对27017端口进行隐藏,防止网络端对mongodb的非法访问。

3)启用加密通讯

mongodb的网络通讯默认采用明文方式。在身份验证部分虽然采用了类似mysql的挑战的方式进行认证(密码不会以hash形式直接在包中出现),但还是会暴露使用指纹加密的信息,如下图:

02.jpg

一般会话则完全是明文信息,可能被不法分子窃听、篡改和中间人攻击:

03.jpg

明文传输的会话信息容易被窃取,启用ssl可以防止网络窃听、篡改和中间人攻击,这在一定程度会提高通讯安全。该启动项不仅支持客户端和服务器之间的通讯加密,也支持服务器之间的通讯加密。

4)加密和数据保护

默认情况下mongodb中的数据以明文形式存储。从3.2版本开始mongodb默认使用具备加密能力的wiredtiger存储引擎。mongodb增加了额外的安全层,需要数据库身份验证才可以访问加密内容。支持openssl库提供的多种加密算法,默认使用aes-256的cbc模式可选gcm模式或fips模式。

5)配置基于角色的访问控制    

mongodb默认情况下没有用户和密码,管理员若在admin库中的user里添加用户和密码,则其中的用户可以访问数据库下所有实例中存储的内容。同样,在每个分库的user中直接添加用户,效果一样,但此时默认用户的权限会过大。很多业务并不需要整个实例乃至整个数据库的访问权限,权限过大可能给数据库带来安全隐患。

采用基于角色的访问控制(rbac)管理对mongodb系统的访问,向用户授予一个或多个角色,保证用户有必要的数据库资源和操作使用权限。创建各种不同权限的角色,成为解决mongodb用户权限过大的唯一方式,如此一来会让创建角色变的繁杂。此处可以采用类似数据库防火墙的权限控制加以进一步控制。

6)审核数据库操作

mongodb默认不开启审计能力,一旦开启,可对部分操作进行审计,跟踪数据库配置和数据的访问和更改。mongodb商业版支持一个系统审计工具,可在mongodb实例上记录系统事件(例如用户操作,连接事件)。审计记录允许管理员事后进行取证分析,利用数据库审计产品也可以做类似的事情。

7)安装mongodb使用专用账号

mongodb某些与操作系统交互的行为对路径缺乏很好的控制,部分安装者为了省事,直接使用root账号安装,这在某些特定情况下会危害到操作系统上文件的安全,建议不要采取这种安装方式。

8)禁用不使用的语言

mongodb支持在服务器端执行javascript、mapreduce、 eval和$where等。如果能确定不使用这些代码进行操作,请禁用,以避免mongodb被攻击入侵(后面web会细说)。具体做法是通过- noscripting选项禁用服务器端的脚本功能。

小结

mongodb目标是实现快速简单部署,所以存在很多安全隐患。解决配置安全问题重点在于:1、网络隐藏,防止恶意访问;

2、加密,保护信息安全;

3、合适的权限,防止越权操作;

4、禁用无用功能,防止某些攻击。

安全应对

满足上述安全防护措施,可以使用专业的产品和技术:

针对配置参数,使用数据库漏扫产品进行检查,生成安全情况报告,指导并帮助用户对mongodb进行安全加固。

数据库防火墙产品可以帮助mongodb实现网络隐身效果,并抵御某些利用javascrip发起的数据库攻击。

数据库审计产品为非企业版mongodb提供更全面审计。

数据库加密产品帮助mongodb用户享受更多样性的加密方式,确保数据密文存储。

2、本身安全问题

根据cve列表,mongodb从2009年面世至今一共发现了13个漏洞,这些漏洞主要分布在2.0-2.6版本之间(mongodb最高版本已经到3.4系列),漏洞主要分为以下三类:

敏感数据泄露

越权操作

登录调用的函数存在缓冲区溢出漏洞,会导致服务宕机

安全应对

1、通过升级3.0以上版本(目前尚未发现3.0以上版本有cve漏洞)来解决自身安全问题。

2、如果上述漏洞重现,可以利用数据库防火墙虚拟补丁做有利补充。

3、web安全问题

乍看起来,web安全和mongodb关系不大,但恰恰相反。鉴于mongodb的部署环境和使用领域,导致从web向mongodb发动的攻击才是mongodb面临的最大威胁。这部分攻击大体分成两类:1、rest和csrf联合攻击;2、注入攻击。

1)rest和csrf联合攻击

rest前文已介绍,mongodb自带的http rest api。默认情况下mongodb会在28017开启一个http端口提供rest服务,直接通过特定格式的url获得数据库中的大部分信息或利用admin.$cmd执行一些数据库级命令。

rest的问题是访问数据库无需身份验证(开启身份强制验证也没用),并能进行一定操作。csrf(cross-site request forgery)则是一种web攻击手段,攻击者盗用管理员身份,提交自己的命令。

2)注入攻击

注入攻击是一种宽泛说法,根据不同的语言注入有不同方式,针对mongodb的注入攻击大体分成二种:解释形语言注入和javascript注入。通过防火墙产品可以借助配置规则,过滤注入攻击。

安全应对

针对第一种攻击,可以利用数据库漏扫产品检查配置,发现rest api是否关闭,解决此类攻击最简单的办法就是将其关闭。

通过数据库防火墙产品,可以借助配置规则对注入攻击进行过滤。

本文通过对mongodb已知安全隐患进行分析,尽可能指出如何防控这些安全隐患,以期对mongodb产品研发和应用提供一些安全应对思路。


网站地图