应使用 iptables 或 ufw 在网络层封禁恶意 IP，因 mongod 无内置防护；需封禁所有监听端口（如 27017/27018/27019/http.port），用 DROP 静默丢包；ufw 更稳妥，支持日志与持久化；authenticationRestrictions 不防暴力破解，仅认证后校验；bindIp 配合云安全组才有效，且必须启用 security.authorization。
直接用 iptables 拒绝恶意 IP 的 TCP 连接
mongod 本身不提供 IP 黑名单或暴力破解拦截功能，所有“阻断”必须落在网络层。iptables 是最直接、生效最快的方式，且规则匹配发生在连接建立前，不消耗 MongoDB 进程资源。
常见错误是只封 27017 端口但漏掉其他监听端口（比如副本集用的 27018、27019，或启用了 net.http.port 的监控端口）。务必确认 MongoDB 实际监听的所有端口：
- 运行
sudo ss -tlnp | grep mongod或sudo netstat -tulnp | grep mongod - 检查配置文件中
net.port、replication.replSet关联端口、net.http.port（若启用）
封禁单个恶意 IP（例如 192.168.3.122）的命令：
sudo iptables -A INPUT -p tcp -s 192.168.3.122 --dport 27017 -j DROP
注意用 DROP 而非 REJECT：前者静默丢包，不返回任何响应，可降低攻击者探测反馈；后者会发 RST 包，可能暴露服务存在。
用 ufw 管理 IP 封禁更稳妥（适合 Ubuntu/Debian）
ufw 是 iptables 的封装，语法更清晰，且自带日志和规则持久化支持，对运维友好。它默认不记录被拒绝连接，需手动开启日志才能追踪暴力尝试：
- 启用日志：
sudo ufw logging on（日志存于/var/log/ufw.log） - 封禁 IP：
sudo ufw deny from 192.168.3.122 to any port 27017 - 查看当前规则：
sudo ufw status numbered - 删除某条规则（如第 3 条）：
sudo ufw delete 3
ufw 的一个关键优势是：它会自动在规则末尾插入默认 deny all 策略。只要没显式 allow，所有未匹配流量都会被拦——这比手写 iptables 时漏掉 REJECT 或 DROP 默认链更可靠。
authenticationRestrictions 不防暴力破解，只校验首次认证来源
有人误以为给用户加 authenticationRestrictions 就能阻止爆破，这是错的。该字段只在用户成功完成 SASL 认证后，比对客户端 IP 是否匹配 CIDR 白名单；而暴力破解发生在认证阶段之前——攻击者连密码都还没输，就反复发起连接+auth 请求，此时 authenticationRestrictions 完全不触发。
换句话说，它是个“登录后校验”，不是“登录前拦截”。真正起作用的仍是网络层防火墙。示例错误认知：
db.createUser({
user: "appuser",
pwd: "xxx",
roles: ["readWrite"],
authenticationRestrictions: [{ clientSource: ["10.0.5.0/24"] }]
})
这段配置只会让 10.0.5.100 成功登录后能操作，但 192.168.1.200 仍可无限次尝试输错密码——mongod 会照常处理每个 auth 请求，直到你用 iptables 把它掐断。
别忘了 bindIp 和云安全组的协同失效风险
很多人设了 bindIp: 127.0.0.1 就以为万事大吉，结果发现云主机上还是被扫到了。这是因为：云环境（阿里云、AWS、腾讯云）的“安全组”是第一道网关，它在数据包到达操作系统前就做了过滤。如果安全组放行了 0.0.0.0/0 到 27017，那即使 bindIp 设成 127.0.0.1，流量根本到不了本地网卡，mongod 压根不会监听外网请求——但攻击者扫端口时仍能看到“端口开放”（因为安全组允许），只是连不上而已。真正的防护链必须完整：
- 云平台：安全组只放行可信源 IP 段（如
10.0.5.0/24）到27017 - 宿主机：iptables/ufw 再做一层细化（比如封掉其中某个异常 IP）
- mongod 配置：
bindIp设为实际需要监听的内网地址（如10.0.5.10），而非0.0.0.0 - 必须启用
security.authorization: enabled，否则前面全是白忙
最容易被忽略的是：安全组规则修改后不生效，是因为没刷新连接状态——已有 TCP 连接不会被立即中断，新连接才会受控。暴力破解者可能正维持着长连接反复重试，所以封 IP 后最好顺手重启 mongod 或 kill 掉可疑连接。
