MongoDB勒索事件后必须修改的默认配置

MongoDB默认配置在没有修改的情况下直接投入生产环境，等于把数据库大门敞开。默认端口27017、无认证机制、绑定所有网络接口，这三项组合在一起，攻击者用自动化扫描工具几分钟就能发现并锁定目标。勒索事件的技术本质不是漏洞利用，而是运维配置缺失导致的人为敞口。攻击者连接上数据库后，直接执行dropDatabase或导出数据并删除，然后留下勒索信息。整个过程不需要任何高级渗透技术，只需要一个能连通27017端口的客户端。

MongoDB配置文件mongod.conf中的bindIp参数默认值通常是127.0.0.1或0.0.0.0。0.0.0.0意味着监听所有网络接口，包括公网网卡。如果你通过云服务器部署，公网IP绑定的网卡也会被监听，这就给了外部扫描可乘之机。修改bindIp为内网IP地址，例如192.168.x.x或10.x.x.x，确保只有内网其他服务器能访问。多网卡环境下可以指定多个IP，用逗号分隔。改完重启mongod服务后，用netstat -anp | grep 27017确认监听地址是否已变为内网IP。这一步是物理隔离，比任何认证机制都更基础。

MongoDB默认不开启认证，任何能连上数据库的人都有最高权限。在配置文件security段落中加入authorization: enabled。开启前必须先创建管理员账号，否则重启后自己都进不去。先用mongo连接数据库，执行以下命令创建root用户：

use admin
db.createUser({
  user: "adminUser",
  pwd: "强密码请替换",
  roles: [ { role: "root", db: "admin" } ]
})

然后再修改配置文件开启认证，重启服务。之后连接必须使用mongo -u adminUser -p --authenticationDatabase admin。生产环境不要只建一个root账号，应该按业务库分别创建读写权限分离的账号。例如给某个业务库创建readWrite权限的用户，roles数组里指定具体数据库名，role用readWrite而不是root。权限最小化原则能限制攻击者即便拿到某个业务账号也无法删除其他库。

27017是MongoDB的默认端口，也是所有扫描工具的首选目标。改成非标准高端口，比如37128、50123等，能过滤掉大部分自动化扫描。修改mongod.conf中的port参数，重启生效。同时需要在云服务商的安全组或防火墙规则中同步更新放行端口，并删除原来27017的规则。注意修改端口不是安全措施的核心，它只是增加发现难度，不能替代认证和网络隔离。如果认证没开，改端口只是让攻击者多花几秒钟换个端口扫描而已。

内网通信如果不加密，数据以明文传输，遇到内网嗅探或中间人攻击时账号密码和业务数据全部暴露。MongoDB支持节点间通信和客户端通信两层的TLS加密。需要先生成或购买证书，然后在配置文件中配置：

net:
  tls:
    mode: requireTLS
    certificateKeyFile: /etc/ssl/mongodb.pem
    CAFile: /etc/ssl/ca.pem

副本集环境下，每个节点都需要配置证书，并且集群内部通信也要开启TLS。参数net.tls.mode设为requireTLS强制所有连接加密。如果暂时无法全部切换，可以先开启preferTLS模式，兼容明文连接逐步过渡。证书过期时间要设置监控告警，过期后MongoDB会拒绝新连接，导致业务中断。

即使bindIp设为内网地址，也应该在系统层和云安全组层做双重限制。iptables或firewalld只放行业务服务器的内网IP访问27017端口，其他来源一律DROP。云安全组入方向规则同样只允许特定安全组或IP段。不要在安全组里放行0.0.0.0/0，这是最常见的错误配置。运维人员为了方便临时调试开放全网，事后忘记回收，等于在防火墙上开了后门。安全组规则要定期审计，删除任何来源为全网的规则。

MongoDB支持在服务端执行JavaScript代码，包括$where操作符、mapReduce、group命令等。攻击者如果获得了数据库操作权限，可以通过JavaScript执行系统命令或进行拒绝服务攻击。在配置文件中设置noscripting: true可以全局禁用服务端脚本执行。大部分业务场景用不到服务端JS，聚合管道和查询操作符已经足够。如果确实有遗留系统依赖mapReduce，应尽快迁移到聚合管道，然后关闭此选项。

默认最大连接数很高，攻击者可以用大量连接耗尽数据库资源。在配置文件中设置net.maxIncomingConnections为一个合理值，比如根据业务并发量上浮30%。同时利用MongoDB的hostManager角色或操作系统层面的cgroup限制资源使用。应用层也要做好连接池管理，避免连接泄漏导致连接数被打满。请求速率限制可以在应用层或中间件实现，MongoDB本身不提供原生的速率限制功能，但可以通过监控慢查询和活跃连接数设置告警阈值。

没有审计日志，被入侵后无法追溯攻击者的操作记录。MongoDB企业版支持审计功能，社区版可以通过mongod的--auditDestination参数输出到文件或syslog。审计日志记录所有数据库操作，包括认证尝试、CRUD操作、DDL操作等。日志文件会快速增长，需要配置日志轮转和定期清理策略。审计日志本身也要保护，存储到只有安全人员可访问的位置，防止攻击者删除日志掩盖痕迹。如果使用社区版且没有审计功能，至少开启详细日志，设置logLevel为1或更高，记录所有操作。

勒索事件的最后一道防线是备份。备份策略要满足3-2-1原则：至少3份副本，2种不同介质，1份异地存储。MongoDB的mongodump逻辑备份适合小数据量，大数据量用文件系统快照或mongod的备份工具。关键点在于定期做恢复演练，验证备份文件确实可用。很多团队每天备份但从没恢复过，真到被勒索时发现备份文件损坏或不完整。备份文件权限要严格控制，攻击者如果拿到备份存储的访问权限，会连同备份一起删除。异地备份存储的访问密钥要与生产环境隔离。

虽然勒索事件主因不是漏洞，但老旧版本确实存在可被利用的安全漏洞。保持MongoDB版本在官方支持周期内，及时应用安全补丁。升级前在测试环境验证兼容性，尤其是驱动版本是否匹配。大版本升级要注意废弃功能和API变更。使用包管理器安装的可以通过yum或apt自动更新，二进制部署的需要手动替换并迁移数据。版本信息不要暴露给外部，可以通过db.version()在未认证状态下获取，这给攻击者提供了针对性攻击的线索。修改配置关闭serverStatus等命令对未认证用户的暴露。

配置改完不代表安全，需要持续监控。关键监控指标包括：连接数突增、认证失败次数激增、数据库被删除、大量数据导出操作、异常IP连接等。可以通过MongoDB的slowOpThresholdMs参数记录慢操作，结合日志分析平台设置告警规则。数据库级别的监控用mongostat和mongotop实时查看，系统级别监控CPU、内存、磁盘IO、网络流量。一旦发现数据库或集合被删除，第一时间断开网络、保留现场、启动恢复流程。告警通知渠道要多样化，短信、电话、即时通讯工具并行，避免单点故障收不到告警。

以下是一份加固后的mongod.conf关键配置段落，供参考调整：

net:
  port: 37128
  bindIp: 192.168.1.100
  maxIncomingConnections: 5000
  tls:
    mode: requireTLS
    certificateKeyFile: /etc/ssl/mongodb.pem
    CAFile: /etc/ssl/ca.pem

security:
  authorization: enabled
  javascriptEnabled: false

auditLog:
  destination: file
  format: JSON
  path: /var/log/mongodb/audit.log

配置修改后务必用mongod --config /etc/mongod.conf --dryRun验证语法正确性，再重启服务。生产环境变更走灰度流程，先在从节点应用，观察无异常后再滚动到主节点。

bindIp改为内网IP、开启认证并创建分权账号、修改默认端口、配置TLS加密、防火墙限制来源IP、禁用服务端JS、限制连接数、开启审计日志、落实备份恢复演练、保持版本更新、搭建监控告警。这十一项配置每一项都是必要的，缺任何一项都可能成为攻击者的突破口。MongoDB勒索事件本质上不是MongoDB的安全缺陷，而是使用者没有完成这些基础配置。把这些配置项纳入运维基线，新部署实例自动化应用安全模板，才能从根本上杜绝此类事件。