域名访问限制不严格漏洞

去年帮一个做电商的朋友看服务器日志，发现有个IP每隔三秒就请求一次后台管理接口。访问查了一下归属地，限制是不严境外某云服务商的机器。朋友说那个后台只允许公司内网访问，格漏我让他把Nginx配置发过来，域名一眼就看到问题——他只写了 allow 192.168.1.0/24;，访问后面跟了个 deny all;，限制但没设置 satisfy any;，不严也没绑定 listen 的格漏特定IP。结果就是域名：任何人只要把Host头改成他公司域名，请求就会绕过那个allow规则。访问这不是限制个例，我后来翻了不少中小企业的不严部署配置，类似情况一抓一大把。格漏

域名访问限制不严格，说白了就是服务器在判断“谁可以访问”时，只看域名（Host头），不看来源IP，或者两者之间的逻辑关系写错了。最典型的错误配置长这样：

这段配置的问题在于，allow 和 deny 确实生效了，但它们只对“直接访问IP”的请求生效。如果攻击者在自己的机器上把域名解析到你的服务器IP，然后发请求时带上 Host: admin.example.com，Nginx会匹配到这个server块，然后……它依然会检查来源IP。等等，那为什么还能绕过？

因为很多人只配了HTTP层的限制，忘了HTTPS。或者反过来，只配了443，80端口裸奔。更常见的是，他们在应用层（比如Django的ALLOWED_HOSTS、Spring Security的IP白名单）做了限制，但Nginx层完全没管。应用层拿到的是Nginx转发过来的请求，如果Nginx没做IP透传，应用层看到的来源IP永远是127.0.0.1，那白名单等于没写。

“我配了 allow 192.168.0.0/16; 啊，怎么外面还能访问？”——因为你的服务器有公网IP，而请求根本没经过你的内网网关。

还有一种情况更隐蔽：CDN。很多站点前面挂了Cloudflare或者阿里云CDN，Nginx的 remote_addr 拿到的是CDN节点IP。如果你在Nginx里写 allow 1.2.3.4; 想只允许某个办公IP访问，结果发现CDN回源IP是另一个段，于是你不得不放开整个CDN段。一放开，等于对全世界开放——因为任何人只要知道你的源站IP，就能直接绕过CDN访问。而你的源站IP，可能藏在历史DNS记录里，或者被扫描器扫出来。

我见过最离谱的一个案例：某公司把测试环境绑定在 test.xxx.com，Nginx里写了 allow 10.0.0.0/8; deny all;，但测试环境的数据库连接串里直接写了公网地址，而且没设密码。结果就是，攻击者通过域名访问被拒，但直接连数据库却畅通无阻。域名限制成了摆设，真正的入口在另一个端口上。

要堵住这类漏洞，核心就一句话：别让域名成为唯一的门禁。如果你只想让内网访问，那就绑定内网IP监听，或者用防火墙规则限制源IP，而不是在Nginx里写个allow就完事。如果必须用域名区分，那就确保 listen 指令绑定了正确的网卡，并且 server_name 匹配之后，后续的访问控制逻辑不会因为Host头被伪造而失效。

具体操作上，我一般会检查三件事：第一，listen 后面有没有跟IP，比如 listen 192.168.1.10:80;，而不是 listen 80;；第二，allow/deny 规则是不是写在 location 里，并且确认 satisfy 的默认行为符合预期；第三，如果用了反向代理，proxy_set_header X-Real-IP $remote_addr; 有没有配上，后端应用有没有信任这个头。

最后说个真事。有个做SaaS的团队，后台管理面板只允许公司IP访问，配置写得挺规范。但他们忘了关掉服务器上的 phpMyAdmin，那个路径没做任何限制。攻击者直接访问 /phpmyadmin，用弱口令进去，然后通过数据库提权，最后拿到了整台服务器。域名限制只保护了主站，却漏掉了旁边的小门。安全这事，从来都是短板决定水位。