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

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

运维派隶属马哥教育旗下专业运维社区,是国内成立最早的IT运维技术社区,欢迎关注公众号:yunweipai
领取学习更多免费Linux云计算、Python、Docker、K8s教程关注公众号:马哥linux运维

作者介绍

上海小胖[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的,其中老美和中国占据半壁江山。
MongoDB
而在第一页中,我就看到一个裸奔的节点:
MongoDB二次勒索过后,如何加强数据库安全防范?插图1
数据量并不大,为了验证节点的有效性,这里仅作为论证参考,不对该节点进行任何影响。
MongoDB
从图中,我们可以看到,这台机器显然并没有逃过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。
打开方式非常简单:1.在admin数据库中,创建一个admin 用户

use admin

db.createUser(

{

user: “myUserAdmin”,

pwd: “abc123”,

roles: [ { role: “userAdminAnyDatabase”, db: “admin” } ]

}

)

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

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

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

mongo –port 27017 -u “myUserAdmin” -p “abc123” –authenticationDatabase “admin”

4.在应用库中创建一个具有读写权限的应用账号。(注意:在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 一遍。避免同样的悲剧在发生。

原文来自微信公众号:DBAplus社群

本文链接:https://www.yunweipai.com/22614.html

网友评论comments

发表回复

您的电子邮箱地址不会被公开。

暂无评论

Copyright © 2012-2022 YUNWEIPAI.COM - 运维派 京ICP备16064699号-6
扫二维码
扫二维码
返回顶部