我的时光，停在了你的角落…~
Posts tagged nginx
nginx设置wordpress的Rewrite配置
Jul 18th
我的在wordpress后台设置固定链接为自定义结构：/archives/%post%/，nginx装好以后，自然是不能正常访问。我就开始到处找方法。
这个玩意儿搞了我个把钟头了，几乎搜遍了google上面所有的文章，搞来搞去就那几篇。无论哪一种方法，我都无法成功。一开始我以为是我这一段RP差到了几点，都打算整个重来了。突然想起来，我的blog跟别人不一样，我的是以二级目录做的，比如http://www.am82.com/houzan，是这样的类型，想了想，是不是规则也不同呢？研究了一下nginx规则的简单语法，发现果然是这样。把这个过程写下来，记录，同时供大家参考～～～高手飘过～～～
我今天下午碰到的方法是在nginx的配置文件nginx.conf中加入
server |
{ |
listen 80; |
server_name am82.com; |
index index.html index.htm index.php; |
root /www/blog; |
#limit_conn crawler 20; |
if (-f $request_filename/index.html){ |
rewrite (.*) $1/index.html break; |
} |
if (-f $request_filename/index.php){ |
rewrite (.*) $1/index.php; |
} |
if (!-f $request_filename){ |
rewrite (.*) /index.php; |
} |
一开始我看大家都这么写，没想什么，二百五一样把自己的规则也这么写，结果不管怎么改都不行，后来研究了一下简单的规则语法，才想起来，原来我的是二级目录的问题。
同时为了方便，我专门做了一个myrewrit.conf的文件，放在nginx.conf同目录下
vi myrewrit.conf
if (-f $request_filename/index.html){
rewrite (.*) $1/index.html break;
}
if (-f $request_filename/index.php){
rewrite (.*) $1/index.php;
}
if (!-f $request_filename){
rewrite (.*) /houzan/index.php;
}
nginx的配置文件这样写，用include插入～～～这样方便多了～
vi nginx.conf
server
{
listen 80;
server_name www.am82.com am82.com;
index index.html index.htm index.php;
include myrewrit.conf;
root /www/blog;
nginx加载新配置
Jul 18th
这两天都在配新的VPS，以前虚拟主机上也有自己的几个小站，挪过来，总要重启nginx，敲的我都嫌烦，翻翻以前下的电子书，找到这个好东西：kill -HUP pid。
使用前先要查看看进程的PID：ps aux |grep nginx
结果
root 1208 0.0 0.1 5968 680 ? Ss Jul17 0:00 nginx: master process /usr/local/nginx/sbin/nginx
1208这个值就是PID的值
然后 kill -HUP 1208 ，就行了。
注意，如果新配置有问题的话，nginx还会加载旧配置，先确定新配置没有问题。
再提供一种解决Nginx文件类型错误解析漏洞的方法
May 21st
昨日，80Sec 爆出Nginx具有严重的0day漏洞，详见《Nginx文件类型错误解析漏洞》。只要用户拥有上传图片权限的Nginx+PHP服务器，就有被入侵的可能。
其实此漏洞并不是Nginx的漏洞，而是PHP PATH_INFO的漏洞，详见：http://bugs.php.net/bug.php?id=50852&edit=1
例如用户上传了一张照片，访问地址为http://www.domain.com/images/test.jpg，而test.jpg文件内的内容实际上是PHP代码时，通过http://www.domain.com/images/test.jpg/abc.php就能够执行该文件内的PHP代码。
网上提供的临时解决方法有：
方法①、修改php.ini，设置cgi.fix_pathinfo = 0;然后重启php-cgi。此修改会影响到使用PATH_INFO伪静态的应用，例如我以前博文的URL：http://blog.s135.com/read.php/348.htm 就不能访问了。
方法②、在nginx的配置文件添加如下内容后重启：if ( $fastcgi_script_name ~ \..*\/.*php ) {return 403;}。该匹配同样会一并干掉类似“/read.php/348.htm”的URI。
方法③、对于存储图片的location{…}，或虚拟主机server{…}，只允许纯静态访问，不配置PHP访问。例如在金山逍遥网论坛、SNS上传的图片、附件，会传送到专门的图片、附件存储服务器集群上（pic.xoyo.com），这组服务器提供纯静态服务，无任何动态PHP配置。各大网站几乎全部进行了图片服务器分离，因此Nginx的此次漏洞对大型网站影响不大。
本人再提供一种修改nginx.conf配置文件的临时解决方法，兼容“http://blog.s135.com/demo/0day/phpinfo.php/test”的PATH_INFO伪静态，拒绝“http://blog.s135.com/demo/0day/phpinfo.jpg/test.php”的漏洞攻击：
location ~* .*\.php($|/)
{
if ($request_filename ~* .*\.php$) {
set $is_path_info ’0′;
}
if (-e $request_filename) {
set $is_path_info ’1′;
}
if ($is_path_info ~ ’0′) {
return 403;
}
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
include fcgi.conf;
}
也可将以下内容写在fcgi.conf文件中，便于多个虚拟主机引用：
if ($request_filename ~* .*\.(php|php5)$) {
set $is_path_info ’0′;
}
if (-e $request_filename) {
set $is_path_info ’1′;
}
if ($is_path_info ~ ’0′) {
return 403;
}
fastcgi_param GATEWAY_INTERFACE CGI/1.1;
fastcgi_param SERVER_SOFTWARE nginx;
fastcgi_param QUERY_STRING $query_string;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param SCRIPT_NAME $uri;
fastcgi_param REQUEST_URI $request_uri;
fastcgi_param DOCUMENT_URI $document_uri;
fastcgi_param DOCUMENT_ROOT $document_root;
fastcgi_param SERVER_PROTOCOL $server_protocol;
fastcgi_param REMOTE_ADDR $remote_addr;
fastcgi_param REMOTE_PORT $remote_port;
fastcgi_param SERVER_ADDR $server_addr;
fastcgi_param SERVER_PORT $server_port;
fastcgi_param SERVER_NAME $server_name;
# PHP only, required if PHP was built with –enable-force-cgi-redirect
fastcgi_param REDIRECT_STATUS 200;
nginx文件类型错误解析漏洞
May 21st
漏洞介绍：nginx是一款高性能的web服务器，使用非常广泛，其不仅经常被用作反向代理，也可以非常好的支持PHP的运行。80sec发现其中存在一个较为严重的安全问题，默认情况下可能导致服务器错误的将任何类型的文件以PHP的方式进行解析，这将导致严重的安全问题，使得恶意的攻击者可能攻陷支持php的nginx服务器。
漏洞分析：nginx默认以cgi的方式支持php的运行，譬如在配置文件当中可以以
location ~ \.php$ {
root html;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
include fastcgi_params;
}
的方式支持对php的解析，location对请求进行选择的时候会使用URI环境变量进行选择，其中传递到后端Fastcgi的关键变量SCRIPT_FILENAME由nginx生成的$fastcgi_script_name决定，而通过分析可以看到$fastcgi_script_name是直接由URI环境变量控制的，这里就是产生问题的点。而为了较好的支持PATH_INFO的提取，在PHP的配置选项里存在cgi.fix_pathinfo选项，其目的是为了从SCRIPT_FILENAME里取出真正的脚本名。
那么假设存在一个http://www.80sec.com/80sec.jpg，我们以如下的方式去访问
http://www.80sec.com/80sec.jpg/80sec.php
将会得到一个URI
/80sec.jpg/80sec.php
经过location指令，该请求将会交给后端的fastcgi处理，nginx为其设置环境变量SCRIPT_FILENAME，内容为
/scripts/80sec.jpg/80sec.php
而在其他的webserver如lighttpd当中，我们发现其中的SCRIPT_FILENAME被正确的设置为
/scripts/80sec.jpg
所以不存在此问题。
后端的fastcgi在接受到该选项时，会根据fix_pathinfo配置决定是否对SCRIPT_FILENAME进行额外的处理，一般情况下如果不对fix_pathinfo进行设置将影响使用PATH_INFO进行路由选择的应用，所以该选项一般配置开启。Php通过该选项之后将查找其中真正的脚本文件名字，查找的方式也是查看文件是否存在，这个时候将分离出SCRIPT_FILENAME和PATH_INFO分别为
/scripts/80sec.jpg和80sec.php
最后，以/scripts/80sec.jpg作为此次请求需要执行的脚本，攻击者就可以实现让nginx以php来解析任何类型的文件了。
POC： 访问一个nginx来支持php的站点，在一个任何资源的文件如robots.txt后面加上/80sec.php，这个时候你可以看到如下的区别：
访问http://www.80sec.com/robots.txt
HTTP/1.1 200 OK
Server: nginx/0.6.32
Date: Thu, 20 May 2010 10:05:30 GMT
Content-Type: text/plain
Content-Length: 18
Last-Modified: Thu, 20 May 2010 06:26:34 GMT
Connection: keep-alive
Keep-Alive: timeout=20
Accept-Ranges: bytes
访问访问http://www.80sec.com/robots.txt/80sec.php
HTTP/1.1 200 OK
Server: nginx/0.6.32
Date: Thu, 20 May 2010 10:06:49 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Keep-Alive: timeout=20
X-Powered-By: PHP/5.2.6
其中的Content-Type的变化说明了后端负责解析的变化，该站点就可能存在漏洞。
漏洞厂商：http://www.nginx.org
解决方案：
我们已经尝试联系官方，但是此前你可以通过以下的方式来减少损失
关闭cgi.fix_pathinfo为0
或者
if ( $fastcgi_script_name ~ \..*\/.*php ) {
return 403;
}
PS: 鸣谢laruence大牛在分析过程中给的帮助
本站内容均为原创，转载请务必保留署名与链接！
nginx文件类型错误解析漏洞:http://www.80sec.com/nginx-securit.html
最新评论