MongoDB漏洞如何加固

wen 网络安全 28

本文目录导读:

MongoDB漏洞如何加固

  1. 第一阶段:基础网络安全与访问控制(最紧急)
  2. 第二阶段:用户与权限管理
  3. 第三阶段:数据传输加密
  4. 第四阶段:功能与逻辑加固
  5. 第五阶段:审计与监控
  6. 第六阶段:操作系统与依赖加固
  7. 整体加固清单示例(mongod.conf
  8. 特别提醒:检查已知CVE

针对MongoDB的漏洞加固,核心思路是默认安全配置深度防御,MongoDB历史上多次出现因为默认配置不当(如绑定0.0.0、未开启认证)导致的大规模数据泄露事件。

以下是系统性的加固方案,按优先级从高到低排列:

第一阶段:基础网络安全与访问控制(最紧急)

这是防止勒索和数据泄露的第一道防线。

  1. 修改绑定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
  2. 启用防火墙规则

    • 操作:使用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
  3. 启用认证(Authorization)

    • 问题:旧版本默认无密码,新版本需显式开启。
    • 加固:在配置文件中添加:
      security:
        authorization: enabled
    • 操作:重启后,必须使用use admindb.auth()或连接字符串中的用户名密码登录。

第二阶段:用户与权限管理

确保即使被入侵,攻击者权限受限。

  1. 遵循最小权限原则

    • 避免使用root角色:不要给应用连接使用rootdbAdminAnyDatabase角色。
    • 创建专用用户:为每个应用创建仅访问特定数据库的用户。
    • 示例
      use myapp_db;
      db.createUser({
        user: "myapp_user",
        pwd: "strong_password",
        roles: [{ role: "readWrite", db: "myapp_db" }]  // 只读写一个库
      });
  2. 强制使用强密码与SCRAM认证

    • 密码策略:长度大于16位,包含大小写/数字/特殊字符。
    • 认证机制:MongoDB 4.0+默认使用SCRAM-SHA-256,比旧版MONGODB-CR更安全,确保升级版本。

第三阶段:数据传输加密

防止中间人攻击或内网嗅探。

  1. 启用TLS/SSL传输加密
    • 场景:跨网络传输(不在同一台机器)。
    • 配置
      net:
        tls:
          mode: requireTLS  # 强制所有连接使用TLS
          certificateKeyFile: /etc/ssl/mongodb.pem
          CAFile: /etc/ssl/ca.pem
    • 注意:客户端连接需使用mongodb://...?tls=true

第四阶段:功能与逻辑加固

主动关闭不安全的特性。

  1. 禁用HTTP状态接口(REST API)(针对旧版本)

    • 问题:MongoDB 2.6及之前版本默认开启REST接口,无需认证即可获取数据库信息。
    • 加固:确保启动参数中没有--rest,或在配置中关闭。
    • 现代版本:已默认移除该功能。
  2. 禁用Server-Side JavaScript(mongo shell)(高安全环境)

    • 问题$wheremapReduce等操作可执行任意JavaScript代码,存在注入风险。
    • 加固:在配置文件中添加:
      security:
        javascriptEnabled: false
    • 影响:会禁用$wheremapReduce,如果业务需要,可考虑替换为$expr或聚合管道。
  3. 限制--nojournal(日志功能)

    • 问题:关闭Journaling可能导致断电时数据损坏。
    • 加固:务必开启storage.journal.enabled: true(默认开启)。

第五阶段:审计与监控

亡羊补牢与日常运维。

  1. 开启审计日志

    • 操作:监控所有DDL和DML操作。
    • 配置
      auditLog:
        destination: file
        format: JSON
        path: /var/log/mongodb/audit.log
        filter: '{ atype: { $in: ["createCollection", "dropCollection", "authCheck"] } }'
  2. 升级到最新稳定版本

    • 原因:MongoDB官方持续修复安全漏洞(如CVE-2021-32039、CVE-2024-13522等)。
    • 操作:定期检查MongoDB版本,并更新到4.x/5.x/6.x/7.x的最新小版本(如0.x)。

第六阶段:操作系统与依赖加固

  1. 使用专用低权限用户运行

    • 原则:不要用root运行MongoDB,创建mongod系统用户,并确保/var/lib/mongodb/var/log/mongodb目录归该用户所有且权限为700或600。
  2. 文件系统安全

    • 加密磁盘:对MongoDB数据目录(/data/db)使用LUKS或云磁盘加密。
    • selinux/AppArmor:启用强制访问控制,防止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暴露在公网(尽量避免),务必结合VPNSSH隧道访问,永远不要将生产数据库直接暴露在公网IP上。

抱歉,评论功能暂时关闭!