MongoDB如何防范暴力破解攻击_配置用户锁定策略或限制尝试频率-MongoDB-PHP中文网

MongoDB官方至今不支持内置用户锁定或登录失败次数限制，其认证体系仅做单次校验、不记录失败历史、不维护登录状态；有效防爆破必须依赖外挂措施，包括防火墙IP限流、反向代理层请求限制及应用层滑动窗口计数。

mongodb如何防范暴力破解攻击_配置用户锁定策略或限制尝试频率

MongoDB 本身不支持用户锁定或登录失败次数限制——这是最常被误解的一点。官方至今（2026年4月）未在任何版本中提供类似 failLockout、maxFailedLoginAttempts 这类配置项，也不存在“账户锁定后自动解锁”的内置机制。

MongoDB 的认证体系只做“单次校验”，不维护登录状态、不记录失败历史、不触发服务端账户冻结。它把频率控制完全交给网络层或应用层。误以为加了 security.authorization: enabled 就自带防爆破能力，是多数被攻破实例的起点。

所有失败登录请求都会返回相同的错误：Authentication failed.，攻击者无法区分是密码错、用户不存在，还是账号被锁——因为根本没锁
配置文件中无论写 setParameter: { authenticationFailureDelayMS: 100 }（v6.0+ 支持）还是自定义 loginThrottle，都只是延缓单次响应，不影响重试总次数
即使启用 TLS + SCRAM-SHA-256，只要密码弱、账号暴露，暴力破解仍可在数小时内完成（实测：8核 CPU + hashcat + rockyou.txt 可达 20k H/s）

不能指望 MongoDB 自己拦住爆破，得在它前面立三道卡口：

mongodb-query

用于调试和故障排查，查询MongoDB数据库。用户需要时可以： (1) 列出所有数据库； (2) 列出数据库中的集合； (3) 执行MongoDB查询或命令。

下载

云环境优先用安全组/ACL：只放行业务服务器固定内网 IP 到 27017 端口，拒绝所有公网源；禁止配 0.0.0.0/0，哪怕加了密码也不行
本地部署必配系统级防火墙：ufw（Ubuntu）或 firewalld（CentOS/RHEL），按 IP 设置连接速率限制，例如：
```
sudo ufw limit from 192.168.1.100 to any port 27017
```
若 MongoDB 前有反向代理（如 Nginx、HAProxy），在 proxy 层做连接数/请求数限制，比在数据库层拦截更早、更省资源

Node.js / Python / Java 应用绝不能把原始用户名密码直传 db.auth() 或连接字符串。必须前置校验：

对登录请求做 IP + 用户名维度的滑动窗口计数（如 Redis 中存 login:fail:10.10.2.5:admin），5 分钟内超 10 次就直接 HTTP 429 拒绝，不发请求到 MongoDB
禁用所有明文传输：确保连接字符串中不含 username/password 参数，改用连接池凭据管理（如 Node.js 的 mongodb://user:pass@host/ 必须走 TLS，且密码需从环境变量或 Vault 注入）
强制使用长 Token 替代密码登录（如 JWT 认证后换取短期 mongosh 临时凭证），避免密码反复暴露在网络链路中

防爆破最难的不是技术实现，而是接受一个事实：MongoDB 不是堡垒机，它连基本的登录失败日志聚合都不做（system.profile 不记 auth 失败，auditLog 默认也不开）。所有防御动作都得从它外面开始，而且得每一层都做——少一层，爆破脚本就能多跑十分钟。