Nginx后台入口限制与防脚本执行配置

很多团队在加固 Nginx 后台入口时，喜欢一上来就堆各种 WAF 规则、改一大段 location 配置，结果业务崩了才发现连静态资源都访问不了。其实真正管用的做法，是把“访问限制”和“防脚本执行”拆成两个独立动作，先堵住入口，再锁死上传目录的执行权限，顺序错了，配置就容易互相打架。

后台入口限制：别只依赖 IP 白名单

最常见的限制手段是 allow/deny 配合 IP 白名单，但实战中这个方案有一堆坑。比如运维人员用动态 IP 办公，一旦 IP 变了，后台直接 403，为了临时上线不得不把整个 C 段都放行，安全防线等于形同虚设。更好的做法是把 IP 白名单作为“辅助层”，核心认证还是交给 HTTP Basic Auth 或 JWT token 验证。Nginx 里可以这样结合：

location /admin/ {
    satisfy any;  # 满足任意一个条件即可
    allow 192.168.1.0/24;
    deny all;
    auth_basic "Restricted Area";
    auth_basic_user_file /etc/nginx/.htpasswd;
}

这样即使 IP 不在白名单内，只要提供正确的用户名密码也能访问——适合需要偶尔远程维护的场景。更严格的环境可以改成 satisfy all，把 IP 和密码双重锁定。

防脚本执行：上传目录才是重灾区

很多 CMS 后台允许上传图片、附件，这些目录如果允许执行 PHP/Python 脚本，攻击者上传一个 webshell 就能直接拿到控制权。配置核心就一句话：在存放用户上传文件的目录里禁止脚本执行。

location /uploads/ {
    location ~ .(php|py|pl|sh|cgi)$ {
        deny all;
    }
}

注意这里用 location ~ 正则匹配，比写在全局 php 处理块里更精准，不会误杀正常图片请求。另外，如果服务器上有 /tmp 或 /var/tmp 等可写路径被映射到 Nginx 访问范围，也要加上类似的规则，防止攻击者利用任意文件上传漏洞写入恶意脚本。

常见遗漏：后台 API 接口的脚本限制

如今很多后台功能通过 API 实现（比如 /api/admin/*），如果这些接口没有做脚本执行验证，攻击者发一个包含文件包含参数的请求就可能绕过目录限制。建议在 server 块全局禁用危险的 fastcgi 参数：

if ($request_uri ~* ".(php|phtml|php3|php4|php5|inc)$") {
    set $block_script 1;
}
if ($block_script = 1) {
    return 403;
}

这里有个潜规则：if 在 Nginx 里性能开销不小，但放在全局级别只检查一遍，比在每个 location 里重复写正则要高效。如果站点流量极大，可以改用 map 指令预处理。

日志验证：配置完不等于安全

很多人改完配置重载就以为万事大吉，其实最容易被忽略的是——攻击者可能已经拿到了后台账号，只是还没动手。建议配置完后，强制检查 /var/log/nginx/access.log 里是否有异常 IP 访问后台路径，同时用 curl 模拟测试：

# 测试上传目录是否执行脚本
curl -I http://your-site/uploads/evil.php
# 期望返回 403 或 404，而非 200

如果返回 200，说明防护失效，需要立刻排查 location 顺序或者正则匹配是否覆盖正确。Nginx 的规则优先级是“精确匹配 > 正则匹配 > 前缀匹配”，很多人把 location ~ .php$ 写在了 location /uploads/ 前面，导致上传目录依然能执行 PHP。正确的做法是把上传目录的 deny 规则放在 php 处理块之前，或者用 location ^~ 禁止正则覆盖。

藏在细节里的坑：反向代理模式下的脚本执行

如果你的 Nginx 做反向代理，后端是 Apache 或 Tomcat，情况会更麻烦。攻击者可能通过修改 Host 头或 X-Forwarded-For 绕过入口限制。此时需要在 Nginx 层手动剥离危险请求头，并在 upstream 配置中加入：

proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For "";
proxy_pass_header Server;
proxy_hide_header X-Powered-By;

同时检查后端服务器是否开启了 Options +ExecCGI 或 AddHandler，因为即便 Nginx 阻断了 .php 请求，如果后端 Apache 的文档根目录下存在 .htaccess 允许执行，攻击者依然可以绕过。防脚本执行必须做到“前端拦截+后端禁用”双保险。

说到底，Nginx 后台入口的限制和防脚本配置，本质是“最小权限”原则在 Web 服务器层的落地。配置完用 nginx -t 检查语法，再用 curl 逐一验证每个风险路径，最后把规则纳入 version control。一次性的改完容易，持续维护才真难——下次加新功能时，别忘了顺手加上 deny all。