专栏名称: DBAplus社群
围绕数据库、大数据、PaaS云,顶级大咖、技术干货,运营几个月受众过十万!成为运维圈最专注围绕“数据”的学习交流和专业社群!欢迎投稿,加入探讨。
目录
相关文章推荐
数据中心运维管理  ·  NASA数据中心被淹,太阳观测数据处理中断! ... ·  3 天前  
数据中心运维管理  ·  AI交换机:未来四大变革 ·  5 天前  
51好读  ›  专栏  ›  DBAplus社群

MongoDB二次勒索过后,如何加强数据库安全防范?

DBAplus社群  · 公众号  · 数据库  · 2017-09-09 08:20

正文


作者介绍

上海小胖[Miracle Young]中国第十五位MONGODB PROFESSIONAL获得者,资深Python开发、DBA。DevOps的践行者,曾独立开发Web服务平台,电商爬虫系统、运维管理系统,涵盖数据热力图、核心数据监控、服务器监控系统等。个人博客:https://segmentfault.com/u/shanghaixiaopang。


原本这周想写一个系列关于 GDPR(General Data Protection Regulation) MongoDB 的,但是9月5日爆出了超2.6W 个MongoDB 节点被劫持。所以临阵变卦,决定写一篇关于MongoDB安全的文章。


是什么心理让各位Developer & DBAer 在发生了如此大的比特币勒索事件后,还是敢于裸奔?纵使觉得数据不重要、有备份,出于对安全的意识,是不是也应该使用一些安全保护措施呢?


注:裸奔在此处的解释为,使用默认端口27017,并对公网开放,未做任何防火墙措施,同时未开启认证和鉴权的MongoDB 数据库)


一、现状


此前我再次验证了目前的MongoDB 节点裸奔的情况,情况非常不容乐观。通过查看 SHODAN,我发现目前还有超过5W个节点的MongoDB 是在使用默认端口27017的,其中老美和中国占据半壁江山。



而在第一页中,我就看到一个裸奔的节点:



数据量并不大,为了验证节点的有效性,这里仅作为论证参考,不对该节点进行任何影响。



从图中,我们可以看到,这台机器显然并没有逃过hacker的攻击,当hacker们攻击了MongoDB的节点之后,会备份你的数据,并删除所有数据,同时会删除journal 日志,这样就算是 Enterprise 版本,也审计不到了。


hacker的攻击方式其实非常简单,可以简单分为以下几步:


  1. 通过类似SHODAN 这样的网站(诸如:ZoomEye等)提供的API,进行全网扫描,MongoDB 那就是扫描27017端口

  2. 获取到IP后,进行嗅探

  3. 如果可以获取到登录信息,那么运行脚本(备份全库、清理journal、留下打款账号信息)

  4. 具体的实现,这里不做过多描述,目的不是为了教学攻破MongoDB,而是为了给大家敲响警钟。


二、防范


通过以上,我们可以清楚地意识到只要做到基本的防范措施,不处于裸奔状态,黑客就不会那么轻易的进入我们DB中了。


需要强调的是,MongoDB官方给出一个默认不加密的配置,是为了方便developer的快速搭建环境,但并不意味着可以如此上线。


因此,在上线前,我们需要对照着MongoDB 官方给出的CheckList去校验一次。


Enable Access Control and Enforce Authentication


首先肯定是打开我们的authentication。打开方式非常简单:


  • 在admin数据库中,创建一个admin 用户

use admin

db.createUser(

 {

   user: "myUserAdmin",

   pwd: "abc123",

   roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]

 }

)


  • 在启动项中加入--auth,或者在配置文件中加入 security.authorization: enabled. 

    mongod --auth --port 27017 --dbpath /data/db1

  • 使用之前创建的myUserAdmin 用户登录mongo 

    mongo --port 27017 -u "myUserAdmin" -p "abc123" --authenticationDatabase "admin"

  • 在应用库中创建一个具有读写权限的应用账号。(注意:在MongoDB中,账号跟着数据库走,也就是说在哪个数据库下创建的,该账号就属于哪个库)


use test

db.createUser(

 {

   user: "myTester",

   pwd: "xyz123",

   roles: [ { role: "readWrite", db: "test" },

            { role: "read", db: "reporting" } ]

 }

)


Configure Role-Based Access Control


这里需要明确的是,MongoDB的基本安全分为两种:一种是认证,一种是鉴权。其实英语会说的比较明白点: authorization, authentication。


认证是作为用户登录的一种账号密码校验,类似MySQL 的 root/password ,在大部分应用中,一旦创建一个连接(用于连接池的),那么该连接只会做一次,所以大可不必担心因为认证而带来的开销。


鉴权是在数据库中的账号拥有的权限做鉴定,类似MySQL中的privilege。


Encrypt Communication


打开MongoDB 的TLS/SSl 的配置,社区版需要下载一个SSL版本,或者可以从社区版通过升级步骤升级到SSl版本,企业版自带SSL。


SSL 可以保证MongoDB的 所有连接(输入和输出的连接)都是加密的。


Encrypt and Protect Data


MongoDB 3.2 WT 引擎推出了一个新的加密功能,仅限企业版,可以对物理数据文件进行加密,若不打开,则默认通过系统对文件进行加密。


Limit Network Exposure


通过指定bindIp ,并在生产线上关闭MongoDB 的Http接口来达到规避网络进口的安全问题。


Audit System Activity


MongoDB 企业版同时提供了审计功能,帮助用户更好的巡检自己的数据库。


Run MongoDB with a Dedicated User


使用MongoDB用户 启动MongoDB,而不是使用root 用户。


三、后续


希望大家在经过2次 MongoDB 的打劫后,都提高警惕了。把自己的生产节点都check 一遍。避免同样的悲剧在发生。


若有你更好的建议,欢迎点击文末【阅读原文】可跳转与我联系,互相交流学习。


近期热文:

一个MySQL 5.7分区表性能下降的案例分析与排查

从零开始搭建MongoDB数据库即服务

深入解析Kafka高可用设计如何步步为营

运维必知必会的监控知识体系全梳理

MySQL DBA的修炼与未来,看看老司机们怎么说?