推荐一个开源程序gixy,https://github.com/yandex/gixy ，作用是来检测Nginx配置文件中存在的问题(不是nginx –t 检测的语法问题)

$uri导致的CRLF注入漏洞

下面两种情景十分常见：

用户访问http://example.com/aabbcc，自动跳转到https://example.com/aabbcc 用户访问http://example.com/aabbcc，自动跳转到http://www.example.com/aabbcc

第二个场景主要是为了统一用户访问的域名，更加有益于SEO优化。

在跳转的过程中，我们需要保证用户访问的页面不变，所以需要从Nginx获取用户请求的文件路径。查看Nginx文档，可以发现有三个表示uri的变量：

$uri $document_uri $request_uri

解释一下，1和2表示的是解码以后的请求路径，不带参数；3表示的是完整的URI（没有解码）。那么，如果运维配置了下列的代码：

location / {
    return 302 https://$host$uri;
}

因为$uri是解码以后的请求路径，所以可能就会包含换行符，也就造成了一个CRLF注入漏洞。（关于CRLF注入漏洞，可以参考我的老文章 https://www.leavesongs.com/PENETRATION/Sina-CRLF-Injection.html ）

这个CRLF注入漏洞可以导致会话固定漏洞、设置Cookie引发的CSRF漏洞或者XSS漏洞。其中，我们通过注入两个
即可控制HTTP体进行XSS，但因为浏览器认为这是一个300跳转，所以并不会显示我们注入的内容。

这个情况下，我们可以利用一些技巧：比如使用CSP头来iframe的地址，这样浏览器就不会跳转，进而执行我们插入的HTML：

14967564064912.jpg

关于上述利用方法，可以参考我的另一篇文章《Bottle HTTP 头注入漏洞探究》。

如何修复这个CRLF漏洞？正确的做法应该是如下：

location / {
    return 302 https://$host$request_uri;
}

另外，由$uri导致的CRLF注入漏洞不仅可能出现在上述两个场景中，理论上，只要是可以设置HTTP头的场景都会出现这个问题。

目录穿越漏洞

这个常见于Nginx做反向代理的情况，动态的部分被proxy_pass传递给后端端口，而静态文件需要Nginx来处理。

假设静态文件存储在/home/目录下，而该目录在url中名字为files，那么就需要用alias设置目录的别名：

location /files {
    alias /home/;
}

此时，访问http://example.com/files/readme.txt，就可以获取/home/readme.txt文件。

但我们注意到，url上/files没有加后缀/，而alias设置的/home/是有后缀/的，这个/就导致我们可以从/home/目录穿越到他的上层目录：

14967571806301.jpg

进而我们获得了一个任意文件下载漏洞。

这个有趣的漏洞出现在了Pwnhub上一期比赛《寻找 SNH48》中，@Ricter师傅的题目。

如何解决这个漏洞？只需要保证location和alias的值都有后缀/或都没有这个后缀。

Http Header被覆盖的问题

众所周知，Nginx的配置文件分为Server、Location、If等一些配置块，并且存在包含关系，和编程语言比较类似。如果在外层配置的一些选项，是可以被继承到内层的。

但这里的继承也有一些特性，比如add_header，子块中配置后将会覆盖父块中的add_header添加的所有HTTP头，造成一些安全隐患。

如下列代码，Server块添加了CSP头：

server {
    ...
    add_header Content-Security-Policy "default-src 'self'";
    add_header X-Frame-Options DENY;

    location = /test1 {
        rewrite ^(.*)$ /xss.html break;
    }

    location = /test2 {
        add_header X-Content-Type-Options nosniff;
        rewrite ^(.*)$ /xss.html break;
    }
}

但/test2的location中又添加了X-Content-Type-Options头，导致父块中的add_header全部失效：

14967575824298.jpg

此时，test2的csp就完全失效了，我们成功触发XSS：

14967576277243.jpg

总结

Nginx配置文件造成的漏洞绝不止这三种，比如之前特别火的解析漏洞（ https://github.com/phith0n/vulhub/tree/master/nginx_parsing_vulnerability ），也和Nginx的配置有一定关系。

解决这类漏洞，最根本的方法是仔细阅读官方文档，文档里说明了很多配置文件错误和正确的用法。最忌去百度网上的一些解决方法，很多错误就是一传十十传百，最后流传开来的。

另外，本文开头提到的工具gixy，我们也可以利用起来，网站上线前进行一下扫描，也许就能发现一些可能存在的问题。

 

网站安全配置Nginx防止网站被攻击

网站安全配置(Nginx)防止网站被攻击（包括使用了CDN加速之后的配置方法）

Nginx 有 2 个模块用于控制访问“数量”和“速度”，简单的说，控制你最多同时有 多少个访问，并且控制你每秒钟最多访问多少次， 你的同时并发访问不能太多，也不能太快，不然就“杀无赦”。

HttpLimitZoneModule 限制同时并发访问的数量

HttpLimitReqModule 限制访问数据，每秒内最多几个请求

请先检查你的 nginx 是否有这 2 个模块，否则~额~没戏，一边墙角哭去吧~~~

1.普通配置（Nginx 官方例子）

## 用户的 IP 地址 $binary_remote_addr 作为 Key，每个 IP 地址最多有 50 个并发连接

## 你想开 几千个连接 刷死我？ 超过 50 个连接，直接返回 503 错误给你，根本不处理你的请求了

limit_conn_zone $binary_remote_addr zone=TotalConnLimitZone:10m ;

limit_conn TotalConnLimitZone 50;

limit_conn_log_level notice;

## 用户的 IP 地址 $binary_remote_addr 作为 Key，每个 IP 地址每秒处理 10 个请求

## 你想用程序每秒几百次的刷我，没戏，再快了就不处理了，直接返回 503 错误给你

limit_req_zone $binary_remote_addr zone=ConnLimitZone:10m rate=10r/s;

limit_req_log_level notice;

## 具体服务器配置

server {

listen 80; location ~ .php$ {

## 最多 5 个排队， 由于每秒处理 10 个请求 + 5个排队，你一秒最多发送 15 个请求过来，再多就直接返回 503 错误给你

limit_req zone=ConnLimitZone burst=5 nodelay;

fastcgi_pass 127.0.0.1:9000;

fastcgi_index index.php;

include fastcgi_params;

}

}

## 用户的 IP 地址 $binary_remote_addr 作为 Key，每个 IP 地址最多有 50 个并发连接

## 你想开 几千个连接 刷死我？ 超过 50 个连接，直接返回 503 错误给你，根本不处理你的请求了

limit_conn_zone $binary_remote_addr zone=TotalConnLimitZone:10m ;

limit_conn TotalConnLimitZone 50;

limit_conn_log_level notice;

## 用户的 IP 地址 $binary_remote_addr 作为 Key，每个 IP 地址每秒处理 10 个请求

## 你想用程序每秒几百次的刷我，没戏，再快了就不处理了，直接返回 503 错误给你

limit_req_zone $binary_remote_addr zone=ConnLimitZone:10m rate=10r/s;

limit_req_log_level notice;

## 具体服务器配置

server {

listen 80;

location ~ .php$ {

## 最多 5 个排队， 由于每秒处理 10 个请求 + 5个排队，你一秒最多发送 15 个请求过来，再多就直接返回 503 错误给你

limit_req zone=ConnLimitZone burst=5 nodelay;

fastcgi_pass 127.0.0.1:9000;

fastcgi_index index.php;

include fastcgi_params;

     }

}

这样一个最简单的服务器安全限制访问就完成了，这个基本上你 Google 一搜索能搜索到 90% 的网站都是这个例子，而且还强调用“$binary_remote_addr”可以节省内存之类的废话

你 Google 不到的配置

普通用户浏览器 —–> 360网站卫士加速（CDN，360防 CC,DOS攻击） ——> 阿里云加速服务器（我们自己建的CDN，阿里云盾） —-> 源服务器（PHP 程序部署在这里，iptables, nginx 安全配置）

可以看到，我们的网站中间经历了好几层的透明加速和安全过滤， 这种情况下，我们就不能用上面的“普通配置”。因为上面基于 源IP的限制 结果就是，我们把 360网站卫士 或者 阿里云盾 给限制了，因为这里“源IP”地址不再是 普通用户的IP，而是中间 网络加速服务器 的IP地址。我们需要限制的是 最前面的普通用户，而不是中间为我们做加速的 加速服务器。

现在我们面对的最直接的问题就是， 经过这么多层加速，我怎么得到“最前面普通用户的 IP 地址”呢？
(这里只说明结果，不了解 Http 协议的人请自行 Google 或者 Wikipedia http://zh.wikipedia.org/zh-cn/X-Forwarded-For )

当一个 CDN 或者透明代理服务器把用户的请求转到后面服务器的时候，这个 CDN 服务器会在 Http 的头中加入 一个记录

X-Forwarded-For : 用户IP, 代理服务器IP

如果中间经历了不止一个 代理服务器，像 www.bzfshop.net 中间建立多层代理之后，这个 记录会是这样

X-Forwarded-For : 用户IP, 代理服务器1-IP, 代理服务器2-IP, 代理服务器3-IP, ….

可以看到经过好多层代理之后， 用户的真实IP 在第一个位置， 后面会跟一串 中间代理服务器的IP地址，从这里取到用户真实的IP地址，针对这个 IP 地址做限制就可以了，

经过多层CDN之后取得原始用户的IP地址，nginx 配置
取得用户的原始地址Shell

map $http_x_forwarded_for $clientRealIp {

## 没有通过代理，直接用 remote_addr

“” $remote_addr;

## 用正则匹配，从 x_forwarded_for 中取得用户的原始IP

## 例如 X-Forwarded-For: 202.123.123.11, 208.22.22.234, 192.168.2.100,…

## 这里第一个 202.123.123.11 是用户的真实 IP，后面其它都是经过的 CDN 服务器

~^(?P<firstAddr>[0-9.]+),?.*$ $firstAddr; }

## 通过 map 指令，我们为 nginx 创建了一个变量 $clientRealIp ，这个就是 原始用户的真实 IP 地址，

## 不论用户是直接访问，还是通过一串 CDN 之后的访问，我们都能取得正确的原始IP地址

map $http_x_forwarded_for $clientRealIp {

## 没有通过代理，直接用 remote_addr

“” $remote_addr; ## 用正则匹配，从 x_forwarded_for 中取得用户的原始IP

## 例如 X-Forwarded-For: 202.123.123.11, 208.22.22.234, 192.168.2.100,…

## 这里第一个 202.123.123.11 是用户的真实 IP，后面其它都是经过的 CDN 服务器

~^(?P<firstAddr>[0-9.]+),?.*$ $firstAddr; }

## 通过 map 指令，我们为 nginx 创建了一个变量 $clientRealIp ，这个就是 原始用户的真实 IP 地址， ## 不论用户是直接访问，还是通过一串 CDN 之后的访问，我们都能取得正确的原始IP地址

测试、测试
很多时候，你在网上搜到一堆配置，你照着做了，但是你怎么知道这个配置真的正确 ？是的，我们需要自己做一个有效的真实的测试，验证它是正确的之后才真的采用它

Nginx 这种配置怎么测试呢？ 用 Echo 模块，如果你知道 Nginx 这个模块的话。

以 www.bzfshop.net 网站为例， 我们首先测试这个 $clientRealIp 是否真的是我们客户机的 IP 地址，在网站上增加一个访问地址，比如 www.bzfshop.net/nginx-test，配置如下：

给 Nginx 增加一个测试地址Shell

server {

listen 80; server_name www.bzfshop.net;

## 当用户访问 /nginx-test 的时候，我们输出 $clientRealIp 变量，看看这个变量

## 值是不是真的 用户源IP 地址

location /nginx-test { echo $clientRealIp;

       }

}

server {

listen 80;

server_name www.bzfshop.net;

## 当用户访问 /nginx-test 的时候，我们输出 $clientRealIp 变量，看看这个变量

## 值是不是真的 用户源IP 地址

location /nginx-test { echo $clientRealIp;

   }

}

接下来，用你的浏览器访问 www.bzfshop.net/nginx-test，这个时候会弹出框下载一个文件 nginx-test，下载完成用 notepad++ 打开，里面就是一个 IP 地址

访问 www.ip138.com ，看看这个里面记录的IP地址是否和 ip138 侦测的IP 一致？

通过这种方式，你就可以对 Nginx 的一些复杂配置做有效的测试。

经过测试，我们确认 通过多层CDN 之后，$clientRealIp 仍然是有效的原始用户IP地址

根据用户的真实 IP 做连接限制
下面是修改之后的 Nginx 配置：

CDN环境下 Nginx 的安全配置Shell

## 这里取得原始用户的IP地址 

map $http_x_forwarded_for $clientRealIp {

“” $remote_addr;

~^(?P<firstAddr>[0-9.]+),?.*$      $firstAddr;

}

## 针对原始用户 IP 地址做限制

limit_req_zone $clientRealIp zone=ConnLimitZone:20m rate=10r/s;

#limit_req zone=ConnLimitZone burst=10 nodelay;

limit_req_log_level notice;

## 具体服务器配置

server {

listen 80; location ~ .php$ {

## 最多 5 个排队， 由于每秒处理 10 个请求 + 5个排队，你一秒最多发送 15 个请求过来，再多就直接返回 503 错误给你

limit_req zone=ConnLimitZone burst=5 nodelay;

 

fastcgi_pass 127.0.0.1:9000;

fastcgi_index index.php;

include fastcgi_params;

   }

}

## 这里取得原始用户的IP地址

map $http_x_forwarded_for $clientRealIp {

“”   $remote_addr;

~^(?P<firstAddr>[0-9.]+),?.*$    $firstAddr;

}

## 针对原始用户 IP 地址做限制

limit_conn_zone $clientRealIp zone=TotalConnLimitZone:20m ;

limit_conn TotalConnLimitZone 50;

limit_conn_log_level notice;

## 针对原始用户 IP 地址做限制

limit_req_zone $clientRealIp zone=ConnLimitZone:20m rate=10r/s;

#limit_req zone=ConnLimitZone burst=10 nodelay;

limit_req_log_level notice;

## 具体服务器配置

server {

listen 80; location ~ .php$ {

## 最多 5 个排队， 由于每秒处理 10 个请求 + 5个排队，你一秒最多发送 15 个请求过来，再多就直接返回 503 错误给你 limit_req zone=ConnLimitZone burst=5 nodelay;

fastcgi_pass 127.0.0.1:9000;

fastcgi_index index.php;

include fastcgi_params;

     }

}