WiredTiger加密对删库和勒索攻击完全无效，恢复仅依赖延迟副本、文件系统快照和带oplog的mongodump备份；加固关键在于严格限制bind_ip、启用authorization及配置slaveDelay。
WiredTiger 加密对勒索攻击完全无效，删库恢复不靠磁盘加密，而靠快照、延迟副本和立即停机——这是最常被误判的两点。
发现删库后第一件事：立刻停 mongod，别做任何写操作
勒索病毒执行 db.dropDatabase() 或 db.fs.files.remove({}) 后，数据并未物理擦除，只是标记为可复用。只要新写入发生（比如日志滚动、其他业务插入），旧数据块就会被覆盖。
- 马上执行
sudo systemctl stop mongod或kill -2 $(cat /var/lib/mongodb/mongod.lock)，不要重启、不要 compact、不要mongod --repair - 确认进程已退出：
ps aux | grep mongod应无残留 - 如果用了 Docker，直接
docker stop容器，不要 exec 进去查数据
恢复数据只看三类备份源，别信“加密能防删”
WiredTiger 的 enableEncryption: true 只加密 wiredtiger.wt 等底层文件，对 remove()、drop() 操作毫无拦截能力。真正可用的恢复路径只有：
-
延迟副本集节点：配置了
slaveDelay: 86400（24 小时）的 secondary，未同步勒索操作，可直接 rsync 数据目录或重搭节点 -
文件系统快照：LVM/ZFS/Btrfs 快照，比
mongodump更快更完整，且不依赖 MongoDB 运行状态 -
外部
mongodump备份：必须含--oplog（仅限副本集），且备份时间点早于攻击发生时间；验证过mongorestore能成功导入才有效
加固不是加个密码就完事，必须堵死所有入口链路
90% 被勒索实例的问题不在 MongoDB 本身，而在网络层与权限模型的松动。
-
bind_ip必须显式列出可信 IP，如127.0.0.1,10.10.5.22，禁用0.0.0.0；云环境还要配安全组，只放通应用服务器 IP 到27017 - 认证用户必须在
admin库创建，且角色最小化：业务账号绝不能有dbOwner或root，只给{role:"readWrite", db:"orders"} - 检查
mongod.conf是否含security.authorization: enabled，并确认admin.system.users里真有用户（空admin库下--auth形同虚设） - 审计日志必须开：
--auditDestination file --auditPath /var/log/mongodb/audit.log，重点监控dropDatabase、remove行为
GridFS 文件被清空后，恢复难度更高
GridFS 本质是 fs.files 和 fs.chunks 两个普通集合，WiredTiger 不识别其语义，加密也无特殊保护。一旦被 db.fs.files.remove({}) 清空，恢复依赖：
- 快照或副本集中是否保留了未被覆盖的
fs.chunks文档（每个 chunk 是独立文档，删除后可能部分残留） -
mongodump --db yourdb --collection fs.chunks若还能导出部分 chunk，配合fs.files元数据可手工拼回文件 - 但若攻击者连
fs.chunks都dropCollection，且无快照，基本无法还原——这就是为什么 GridFS 业务更要提前部署延迟副本
真正难的不是技术动作，而是把 bind_ip、security.authorization、slaveDelay 这三件事在上线前就刻进部署流程，而不是等删库后翻文档补救。
