MongoDB 默认无认证且监听公网，极易遭勒索；必须启用security.authorization、创建最小权限用户、绑定内网IP+防火墙双重防护、验证备份可恢复性并隔离存储。
不设密码等于把数据库摆路边任人拿
MongoDB 默认启动时不启用认证，bind_ip 默认监听 0.0.0.0，端口 27017 直接暴露在公网——这相当于没锁门、没装防盗窗、连门牌号都印在广告单上。勒索病毒脚本（比如扫描 Shodan 的 bot）几秒就能发现你，连登录都不用密码，直接执行 db.dropDatabase() 或导出全部数据。
- 确认是否已启用认证：检查配置文件中是否有
security.authorization: enabled（v3.6+）或旧版的auth = true - 别信“我只绑了内网IP就安全”——如果宿主机有其他服务被攻破（如 SSRF、Docker API 暴露），攻击者仍能从内网打穿 MongoDB
- 刚装完 MongoDB 时，
admin数据库为空，即使加了--auth启动，只要没在admin.system.users里创建第一个用户，照样不校验权限
必须立刻创建的最小权限用户
不要用 root 或 userAdminAnyDatabase 账号给业务连接；一个账号被撞库，整个集群就裸奔。真实案例里，90% 被勒索的实例都是因为业务代码硬编码了 admin 用户和弱密码（如 admin123、password）。
- 在
admin库中创建管理员用户：db.createUser({user:"admin", pwd:"<strong>强密码（≥12位，含大小写/数字/符号）</strong>", roles:["userAdminAnyDatabase", "clusterAdmin"]}) - 为每个业务单独建用户，例如电商订单服务只给
orders库的readWrite权限：use orders\ndb.createUser({user:"order_app", pwd:"<strong>另一套独立强密码</strong>", roles:[{role:"readWrite", db:"orders"}]}) - 禁用默认
mongod启动时的匿名访问：确保配置中没有setParameter: enableLocalhostAuthBypass: false（v4.0+ 默认关闭，但老版本或自定义配置可能开着）
bind_ip 和防火墙不是二选一，是必须双开
只改 bind_ip 不拦外网请求，只开防火墙不关监听接口，都等于只系一半鞋带。MongoDB 本身不校验来源 IP，全靠网络层兜底。
-
bind_ip必须显式指定，不能留空或写127.0.0.1就以为安全——如果你的应用在另一台机器，得加上内网 IP，例如：bind_ip = 127.0.0.1,10.10.2.5 - 云服务器务必同步配置安全组/ACL：只放行应用服务器的源 IP 到
27017端口，拒绝0.0.0.0/0；本地部署则用系统防火墙（如ufw或firewalld）限制 - 别用“改端口”当安全措施：把
27017改成37017只防小白，专业扫描器早把常见偏移端口列进字典了
备份不是“定期点一下”，而是要验证可恢复
勒索病毒提示“已备份你的数据”，往往是真的——它真扫走了你的 dump。但更常见的情况是：你有备份，但备份脚本半年没跑成功，或者备份路径权限错误导致空文件，或者恢复时才发现 mongodump 版本比生产环境低，无法兼容新 BSON 格式。
- 用
mongodump --forceTableScan --gzip --out /backup/mongo-$(date +%F)定期全量备份，--forceTableScan防止因索引损坏漏数据 - 每天自动校验一次备份完整性：
mongorestore --dryRun --archive=/backup/mongo-$(date -d 'yesterday' +\%F).gz 2>/dev/null | grep "done"
成功才发通知，失败立刻告警 - 备份存储位置必须与 MongoDB 实例物理隔离：不共用同一块磁盘、不挂载同一 NAS 共享目录、不用同一云账号下的同区域 OSS——勒索程序常会顺手清空挂载点
最常被忽略的一点：所有加固动作做完后，一定要用非管理员账号、从外部 IP 连一次试试。别只在本地 mongo 命令行里敲 show dbs 就算完事——真正的攻击面永远在你没模拟到的那个角落。
