本文目录导读:

- 第一阶段:基础网络安全与访问控制(最紧急)
- 第二阶段:用户与权限管理
- 第三阶段:数据传输加密
- 第四阶段:功能与逻辑加固
- 第五阶段:审计与监控
- 第六阶段:操作系统与依赖加固
- 整体加固清单示例(
mongod.conf) - 特别提醒:检查已知CVE
针对MongoDB的漏洞加固,核心思路是默认安全配置加深度防御,MongoDB历史上多次出现因为默认配置不当(如绑定0.0.0、未开启认证)导致的大规模数据泄露事件。
以下是系统性的加固方案,按优先级从高到低排列:
第一阶段:基础网络安全与访问控制(最紧急)
这是防止勒索和数据泄露的第一道防线。
-
修改绑定IP(
bindIp)- 问题:默认绑定
0.0.0(所有网卡),导致暴露在公网。 - 加固:在
mongod.conf中,将bindIp修改为内网IP(如0.0.1, 10.0.0.x)或私有IP。 - 配置示例:
net: bindIp: 127.0.0.1, 192.168.1.100 # 仅监听本地和内部网络 port: 27017
- 问题:默认绑定
-
启用防火墙规则
- 操作:使用iptables或云安全组,仅允许受信任的服务器IP访问MongoDB端口(默认27017)。
- 命令示例:
# 仅允许Web服务器访问 iptables -A INPUT -p tcp --dport 27017 -s 10.0.0.2 -j ACCEPT iptables -A INPUT -p tcp --dport 27017 -j DROP
-
启用认证(Authorization)
- 问题:旧版本默认无密码,新版本需显式开启。
- 加固:在配置文件中添加:
security: authorization: enabled
- 操作:重启后,必须使用
use admin和db.auth()或连接字符串中的用户名密码登录。
第二阶段:用户与权限管理
确保即使被入侵,攻击者权限受限。
-
遵循最小权限原则
- 避免使用root角色:不要给应用连接使用
root或dbAdminAnyDatabase角色。 - 创建专用用户:为每个应用创建仅访问特定数据库的用户。
- 示例:
use myapp_db; db.createUser({ user: "myapp_user", pwd: "strong_password", roles: [{ role: "readWrite", db: "myapp_db" }] // 只读写一个库 });
- 避免使用root角色:不要给应用连接使用
-
强制使用强密码与SCRAM认证
- 密码策略:长度大于16位,包含大小写/数字/特殊字符。
- 认证机制:MongoDB 4.0+默认使用
SCRAM-SHA-256,比旧版MONGODB-CR更安全,确保升级版本。
第三阶段:数据传输加密
防止中间人攻击或内网嗅探。
- 启用TLS/SSL传输加密
- 场景:跨网络传输(不在同一台机器)。
- 配置:
net: tls: mode: requireTLS # 强制所有连接使用TLS certificateKeyFile: /etc/ssl/mongodb.pem CAFile: /etc/ssl/ca.pem - 注意:客户端连接需使用
mongodb://...?tls=true。
第四阶段:功能与逻辑加固
主动关闭不安全的特性。
-
禁用HTTP状态接口(REST API)(针对旧版本)
- 问题:MongoDB 2.6及之前版本默认开启REST接口,无需认证即可获取数据库信息。
- 加固:确保启动参数中没有
--rest,或在配置中关闭。 - 现代版本:已默认移除该功能。
-
禁用Server-Side JavaScript(mongo shell)(高安全环境)
- 问题:
$where、mapReduce等操作可执行任意JavaScript代码,存在注入风险。 - 加固:在配置文件中添加:
security: javascriptEnabled: false
- 影响:会禁用
$where和mapReduce,如果业务需要,可考虑替换为$expr或聚合管道。
- 问题:
-
限制
--nojournal(日志功能)- 问题:关闭Journaling可能导致断电时数据损坏。
- 加固:务必开启
storage.journal.enabled: true(默认开启)。
第五阶段:审计与监控
亡羊补牢与日常运维。
-
开启审计日志
- 操作:监控所有DDL和DML操作。
- 配置:
auditLog: destination: file format: JSON path: /var/log/mongodb/audit.log filter: '{ atype: { $in: ["createCollection", "dropCollection", "authCheck"] } }'
-
升级到最新稳定版本
- 原因:MongoDB官方持续修复安全漏洞(如CVE-2021-32039、CVE-2024-13522等)。
- 操作:定期检查MongoDB版本,并更新到4.x/5.x/6.x/7.x的最新小版本(如
0.x)。
第六阶段:操作系统与依赖加固
-
使用专用低权限用户运行
- 原则:不要用
root运行MongoDB,创建mongod系统用户,并确保/var/lib/mongodb和/var/log/mongodb目录归该用户所有且权限为700或600。
- 原则:不要用
-
文件系统安全
- 加密磁盘:对MongoDB数据目录(
/data/db)使用LUKS或云磁盘加密。 - selinux/AppArmor:启用强制访问控制,防止MongoDB进程访问非授权文件。
- 加密磁盘:对MongoDB数据目录(
整体加固清单示例(mongod.conf)
# 网络与安全
net:
bindIp: 127.0.0.1, 10.0.0.10 # 仅内网
port: 27017
tls:
mode: requireTLS # 生产环境强制加密
certificateKeyFile: /etc/ssl/mongodb.pem
security:
authorization: enabled # 强制认证
javascriptEnabled: false # 禁用JS执行(如不需要)
storage:
dbPath: /data/mongodb
journal:
enabled: true # 确保开启
systemLog:
destination: file
logAppend: true
path: /var/log/mongodb/mongod.log
# 资源限制
processManagement:
fork: true
pidFilePath: /var/run/mongod.pid
setParameter:
authenticationMechanisms: SCRAM-SHA-256 # 使用强认证机制
特别提醒:检查已知CVE
- CVE-2021-32039:未授权访问(4.4.11之前)
- CVE-2024-13522:拒绝服务(DoS)
- 默认配置风险:即使启用认证,如果绑定了
0.0.0而未设防火墙,仍然存在暴力破解风险。
最后建议:如果MongoDB暴露在公网(尽量避免),务必结合VPN或SSH隧道访问,永远不要将生产数据库直接暴露在公网IP上。