改端口不是安全措施，真正有效的是限制访问来源（bindIp+防火墙）和强制认证（auth+TLS）；仅换端口无法防扫描，未授权服务仍会被快速识别并入侵。
直接关闭或修改 27017 端口本身并不能提升安全性，真正起作用的是「限制访问来源 + 强制认证」；单纯换端口只是把门换个位置，没锁好照样被撬。
为什么改端口不是安全措施，而是掩耳盗铃
攻击者扫描 27017 端口只是习惯性起点，实际工具（如 nmap -sV、mongo-express 扫描器）会主动探测常见服务指纹，哪怕你改成 29089 或 37017，只要 MongoDB 服务在监听且未启用认证，几秒内就能被识别出来。
常见错误现象：Failed to connect to 127.0.0.1:27017, reason: errno:61 Connection refused —— 这不是安全了，只是客户端没跟上你改端口的动作。
- 改端口后，所有连接方（应用代码、监控脚本、备份任务）都必须同步更新
--port参数或连接字符串中的:端口号 - 运维排查时容易误判：看到非标准端口，第一反应是“这不是 MongoDB”，反而延迟发现入侵痕迹
- 防火墙规则、K8s Service、云安全组等配置项都要额外维护，出错概率翻倍
bindIp 和 firewall 才是真正有效的第一道防线
bindIp 控制 MongoDB 进程自己监听哪些网卡地址；防火墙（iptables / firewalld）控制操作系统是否放行该端口的入站包。两者叠加，才能让攻击流量根本连不到服务进程。
典型配置差异：
-
bindIp: 127.0.0.1（YAML 配置） → 只响应本地回环请求，连本机其他容器/进程都访问不了，适合单机开发 -
bindIp: 192.168.1.100,127.0.0.1→ 显式列出可信内网 IP，拒绝0.0.0.0或127.0.0.1,::1,0.0.0.0这类模糊写法 -
iptables -I INPUT -p tcp --dport 27017 -j DROP必须放在所有ACCEPT规则之前，否则无效
注意：iptables --list INPUT --line-numbers 查看规则顺序，数字越小越先匹配。
auth 启用后，用户创建和角色分配容易踩的坑
启用 security.authorization: enabled 后，MongoDB 不再允许任何未认证操作 —— 包括 show dbs、use admin，甚至 db.version() 都会报 not authorized on admin to execute command。
关键实操点：
- 必须先用无认证方式连上，再在
admin库执行db.createUser()，否则进不去 -
roles: ["root"]权限过大，生产环境建议按需分配，例如应用账号只给{role: "readWrite", db: "myapp"} - 密码不能含特殊字符（如
@、/），否则 URI 连接时要 URL 编码，否则mongodb://user:pass@host/db会解析失败 - 重启服务后，如果忘记加
--auth或配置文件里没生效，会静默降级为无认证模式 —— 用db.runCommand({getCmdLineOpts: 1})检查实际加载参数
SSL/TLS 和定期升级不是可选项，是运营底线
内网不等于安全。Docker 网络、宿主机混部、跳板机直连都可能暴露明文流量。一旦开启 net.ssl.mode: requireSSL，所有连接必须带证书，连 mongo --port 27017 都会失败，必须用 mongosh --tls --tlsCAFile ca.pem ...。
更常被忽略的是版本碎片问题：
- MongoDB 4.4 早在 2024 年底已 EOL，继续用存在未修复的
CVE-2023-35889（身份绕过）等高危漏洞 - 升级不是简单
apt upgrade，必须检查storage.engine兼容性（WiredTiger vs MMAPv1）、oplog 大小变更、驱动 API 差异 - 阿里云、腾讯云托管版 MongoDB 默认启用 TLS 和最小权限账号，自建集群若没做等效替代，风险等级其实高于云服务
最危险的配置，是开着 bindIp: 0.0.0.0、关着 authorization、又没设防火墙 —— 这等于把数据库裸奔挂在公网上，改不改 27017 端口毫无意义。
