一则数据泄露案例教你做好安全基线的重要性

据澎湃新闻2月15日消息，2月13日，GDI基金会荷兰安全研究员Victor Gevers在推特上爆料，中国某公司发生大规模数据泄露事件。Gevers表示，该公司所掌握的数百万人的跟踪数据可供任何人访问，其中包含超过256万人的个人信息，例如身份证号码、身份证发行日期、性别、国家、住址、生日、照片、雇主和过去24小时内的位置，大约有668万条记录。Gevers称，该公司的数据库从2018年7月开始就处于任何人都可以访问的状态。

经仔细阅读分析该案例后，发现常易被人忽视的日常安全运营之安全基线工作即能轻松预防和避免该类事件的发生，详细分析如下：

一、案例成因分析

1. 背景信息

2. 数据泄露原因技术分析

从Gevers在推特上发的截图和描述可以初步分析如下，该公司使用MongoDB数据库存放人脸识别等个人敏感数据，该数据库实例服务使用MongnDB安装缺省端口27017，该服务端口可由互联网直接访问，该数据库未启用身份认证机制，即允许任何人访问。

事件产生原因：该公司对存放人脸识别敏感数据的MongoDB数据库使用了出场安装缺省配置，未进行日常安全运营中的安全基线工作，存在严重安全漏洞导致了此事件的发生。

二、安全运营之安全基线工作的预防能力介绍

在日常安全运营中的安全基线工作中，企业的安全团队会针对公司使用的各种系统、软件和数据库开发和发布相应的安全基线标准，在系统上线前进行部署和合规性检查，经检查只有在与公司的安全基线标准符合的前提下才允许上线，这样就可以避免由于各种系统、软件和数据库由于使用厂家出厂不安全缺省配置导致的安全漏洞问题，有效地降低和控制安全风险。

下面针对该案例摘录部分MangoDB安全基线内容如下：

1. 端到端安全架构设计

MongoDB端到端安全架构设计如下图所示，从人员、过程和产品（技术）三个维度进行纵深安全体系防护，分别通过访问控制、加密和审计来实施。

网络安全架构部署参照下图，通过两层防火墙将WEB/应用服务器和MongoDB数据库服务器分别隔离在不同的两个DMZ类进行网络区域隔离和分层网络访问控制，数据库服务器通过防火墙访问规则控制只能由DMZ1区域内的应用服务器访问，避免了将其直接暴露给互联网的安全风险问题。

2. 启用MongoDB数据库身份认证功能

身份认证功能状态检查：

cat /etc/mongod.conf | grep “Auth=”

如果身份认证功能已启用，则Auth的设置值为“True”。

激活身份认证功能步骤：

1）启动未激活身份认证功能的MongoDB数据库实例；

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

2）创建数据库系统管理员用户，并确保设置的口令符合组织口令策略的要求；

use admin db.createUser(

{

user: "siteUserAdmin", pwd:"password",

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

}

)

3）重启已激活身份认证功能的MongoDB数据库实例。

mongod --auth--config /etc/mongod.conf

3. 确保MongoDB数据库实例只在授权的接口上侦听网络连接

当前数据库实例网络侦听状态检查：

检查MongoDB配置文件；

cat /etc/mongod.conf |grep –A12“net”| grep “bindIp“

检查相关网络访问控制设置；

iptables –L

配置数据库实例侦听在指定网络接口并用防火墙规则进行严格访问控制，应只允许DMZ区域里的应用服务器连接，下面以主机防火墙iptables示例配置如下。

iptables -A INPUT -s <ip-address> -p tcp--destination-port 27017 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -d <ip-address> -p tcp--source-port 27017 -m state --state ESTABLISHED -j ACCEPT

如上对比分析可以看出，如果企业在日常安全运营中，认真严格地按照MongoDB数据库安全基线标准执行的话，就能够有效地预防和避免类似大数据泄露案例的发生。

Reference

https://github.com/cn-quantumsec/Diaoyu-Castle-Sec-Benchmark-Project

*本文作者：heymind，转载请注明来自FreeBuf.COM