MongoDB勒索事件频发下的认证开启与备份策略调整

MongoDB数据库被勒索的事件，在2024年到2025年期间呈现出了明显的反弹趋势。攻击者不再满足于简单地删除数据，而是利用配置疏漏进行批量扫描、加密数据、索要赎金，甚至威胁公开数据。核心问题在于，大量的生产环境实例仍然在公网上以默认的无认证模式运行，或者仅仅依赖网络防火墙做了一层薄弱的防护。一旦边界被突破，数据库完全裸露。解决这个问题不需要复杂的架构，只需立即开启认证机制，并彻底调整备份策略，从逻辑备份转向物理全量加实时增量备份。

攻击者通常利用自动化扫描工具，在公网上探测27017端口。一旦发现无认证或弱口令的MongoDB实例，攻击脚本会在几秒钟内完成入侵。入侵后，攻击者会执行数据库枚举，导出数据，随后删除原库，并在一个名为“READ_ME_TO_RECOVER_DATA”的集合中留下勒索信息。近年来，部分攻击团伙开始采用更隐蔽的手法，他们不立即删除数据，而是先窃取敏感数据，再对原地数据进行加密，以此实施双重勒索。如果你仅仅关闭了公网端口，但内网横向移动的防护不到位，同样会遭遇内部威胁。因此，第一道防线必须从数据库自身的安全机制做起。

MongoDB默认安装时，localhost模式允许无密码登录，这是最危险的配置。必须立即切换到强制认证模式。首先，在未开启认证时进入mongo shell，切换到admin库，创建一个具有root权限的管理员账号。命令如下：

use admin
db.createUser(
  {
    user: "rootAdmin",
    pwd: "yourStrongPassword",
    roles: [ { role: "root", db: "admin" } ]
  }
)

创建成功后，需要修改MongoDB的配置文件，通常是/etc/mongod.conf。在security部分，将authorization设置为enabled。同时，为了安全，建议将bindIp从默认的127.0.0.1改为内网IP，避免直接监听0.0.0.0。配置片段如下：

net:
  port: 27017
  bindIp: 192.168.1.100,127.0.0.1

security:
  authorization: enabled

重启MongoDB服务后，任何数据库操作都必须经过身份验证。连接字符串也必须修改为包含认证信息的格式：mongodb://用户名:密码@主机IP:27017/数据库名。对于副本集或分片集群，每个节点都需要配置相同的认证文件，并建议启用内部节点间的keyFile认证。keyFile相当于节点之间的共享密钥，内容为随机生成的base64字符串，权限必须设置为400。生成方式很简单，使用openssl rand -base64 756 > /path/to/keyfile，然后在配置文件中添加security: keyFile: /path/to/keyfile。这样即使网络层被突破，攻击者也难以伪装成集群节点。

开启认证后，切忌所有应用都使用root账号。应该为每个数据库创建独立的读写用户。对于一般的业务应用，只需要readWrite角色。如果应用只需要查询，坚决只授予read角色。创建应用专属用户的命令如下：

use yourAppDB
db.createUser(
  {
    user: "appUser",
    pwd: "anotherStrongPassword",
    roles: [ { role: "readWrite", db: "yourAppDB" } ]
  }
)

对于需要跨库操作的情况，不要为了方便直接给root，而是精确指定多个库的角色。定期审计用户权限，删除不再使用的账号。攻击者在获取应用服务器权限后，往往会尝试读取配置文件中的数据库密码，如果该密码具有root权限，整个数据库集群将瞬间沦陷。因此，权限隔离是纵深防御的关键一环。

很多团队习惯使用mongodump进行逻辑备份。这在勒索事件中暴露出严重缺陷：恢复速度极慢，且容易在备份窗口期间遗漏增量数据。一旦数据库达到TB级别，mongodump的导出和导入可能需要数小时甚至数天，业务无法承受这么长的停机时间。必须转向基于文件系统快照的物理备份，并结合oplog实现实时增量恢复。

MongoDB的复制集机制天然支持备份。Oplog是一个固定大小的集合，记录了所有数据变更操作。通过备份全量数据文件，并持续拉取oplog，可以实现任意时间点的恢复。具体操作上，在生产环境部署至少三个节点的复制集，其中一个节点可以设置为隐藏节点，专用于备份。备份流程如下：在隐藏节点上停止写入同步，对数据目录进行快照，然后重新同步。快照完成后，将快照数据上传到异地对象存储。同时，启动一个持续运行的进程，从主节点拉取oplog，并实时备份到远端。这样，即使主节点数据被加密，也可以从备份节点恢复到加密前的最后一刻。

手动管理快照和oplog比较复杂，推荐使用Percona Backup for MongoDB（PBM）这类成熟工具。PBM是开源工具，专门为MongoDB设计，支持物理全量备份和oplog增量备份，并且天然支持对象存储。部署PBM后，配置备份存储位置为S3兼容的对象存储，设置备份频率。全量备份可以每天一次，增量备份建议每10分钟一次。PBM会自动处理oplog的截断和合并，确保恢复时不会出现断点。恢复命令也很简单，只需指定时间点，PBM会自动选择最近的全量备份，并重放oplog到指定时刻。这种方式将恢复时间从小时级压缩到分钟级，大幅降低了勒索攻击造成的业务中断风险。

仅仅备份到同一台服务器或同一内网存储是不够的。攻击者一旦获得高权限，会尝试删除或加密备份文件。必须实施不可变备份策略。对象存储如MinIO或云厂商的S3兼容服务，都支持对象锁定功能。配置备份存储桶的WORM（一次写入多次读取）策略，设定保留期内备份文件无法被删除或修改。同时，备份必须异地存放，至少跨机房或跨区域。PBM支持直接备份到S3，无需在本地落盘，这减少了攻击面。如果必须保留本地副本，应使用独立于MongoDB服务器的备份服务器，并通过只读方式挂载备份目录，MongoDB服务器本身没有该备份服务器的访问权限。

认证和备份是防御和恢复的手段，而实时监控则是发现攻击的眼睛。开启MongoDB的审计日志，记录所有数据库操作，特别是删除集合、删除数据库、创建用户等敏感操作。将审计日志输出到独立的日志分析平台，设置告警规则。一旦检测到dropDatabase或dropCollection命令，立即触发告警，并自动暂停数据库服务。同时，监控网络流量，如果发现某个IP在短时间内进行大量全表扫描查询，这很可能是数据导出行为，应立即阻断。MongoDB Atlas和部分第三方监控工具如Datadog、Prometheus的MongoDB Exporter都可以实现这些功能。对于自建集群，可以编写脚本定期检查是否有名为“READ_ME_TO_RECOVER_DATA”的集合出现，这是一个简单但有效的勒索特征检测。

虽然核心是认证和备份，但网络层的加固同样不能忽视。永远不要将MongoDB端口直接暴露在公网上。如果业务必须跨公网访问，必须使用VPN或专线。在云环境中，安全组规则应严格限制访问来源IP，只允许应用服务器所在的子网访问。同时，在MongoDB服务器上启用防火墙，如iptables，只放行内网IP的27017端口。对于分片集群，各个组件之间的通信端口也应限制在集群内部。这些措施虽然不能替代认证，但能有效减少攻击者的扫描命中率。

备份策略的最后一环是验证。很多团队配置了自动备份后就以为高枕无忧，直到灾难发生才发现备份文件损坏或恢复流程有误。必须每季度进行一次恢复演练。演练环境应完全隔离，从对象存储拉取最新的全量备份和oplog，使用PBM或手动方式恢复到一台全新的服务器上，然后启动MongoDB，验证数据完整性和应用兼容性。演练过程中记录恢复耗时，评估是否满足业务RTO和RPO指标。如果发现恢复时间过长，需要调整备份频率或升级硬件。这种演练不仅能发现技术问题，还能让团队熟悉恢复流程，在真实攻击发生时从容应对。

面对持续演进的MongoDB勒索攻击，防御策略必须清晰且可执行。第一，立即检查所有实例是否已开启SCRAM认证，关闭公网监听。第二，为每个应用创建最小权限账号，禁用root远程登录。第三，部署物理全量加oplog增量的备份方案，使用PBM等工具实现自动化。第四，将备份存储到异地对象存储并开启不可变锁定。第五，配置审计日志和敏感操作告警。第六，定期进行恢复演练。这六步构成了从预防到检测再到恢复的完整闭环，能有效将勒索攻击的影响降到最低。