今天nginx漏出php-fcgi解析漏洞后，一时间沸沸扬扬，一些高手也出了相应的解决方法，汇总比较如下：
1.
if ( $fastcgi_script_name ~ .*\.(png|jpg|gif|bmp|PNG|JPG|GIF|BMP)\/.*php ) {
return 404;
}
本人针对漏洞的解决方法！
【2010-5-21 20:03】修改补充：
dennis大侠提出：
还有第一个解决方法 如果是rar的怎么办？ 那个和文件后缀的关系不大
我早上测试的文件名字是.kpg的也一样可以针对后缀名不确定的元素我修改为（测试通过，可以加入到enable_php5.conf顶部，多虚拟主机启用）：
if ( $fastcgi_script_name ~ .*\.([0-9a-zA-Z]+)\/.*\.php ) {
return 404;
}
附上我的enable_php5.conf配置：
if ( $fastcgi_script_name ~ .*\.([0-9a-zA-Z]+)\/.*\.php ) {
return 404;
}
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 $fastcgi_script_name;
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;
2.
if (!-e $request_filename) {
rewrite .* http://www.yanghengfei.com/index.php;
}
已经可以实现防止漏洞的效果，但是如果你的网站是康盛的程序或者其他开源程序需要开启rewrite伪静态的程序，那么就会出现rewrite伪静态后的静态页面全部访问你设置的页面！
3.
if ( $fastcgi_script_name ~ \..*\/.*php ) {
return 403;
}
有重写的同学，慎用通杀
4.
设置php.ini的cgi.fix_pathinfo为0，重启php。最方便，但修改设置的可能对你网站有影响！是比较鲁莽的做法！
补充
【2010-5-21 21:27】
张宴的方法：
本人再提供一种修改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;
漏洞介绍：80sec发现nginx存在一个较为严重的安全问题，默认情况下可能导致服务器错误的将任何类型的文件以PHP的方式进行解析，这将导致严重的安全问题，使得恶意的攻击者可能攻陷支持php的nginx服务器。根据Netcraft的统计，直到2010年4月，全球一共有1300万台服务器运行着nginx程序；非常保守的估计，其中至少有600万台服务器运行着nginx并启用了php支持；继续保守的估计，其中有1/6，也就是100万台服务器允许用户上传图片。80sec指出，由于nginx有漏洞，这100万台服务器可能通过上传图片的方法被黑客轻易的植入木马。
nginx和lvs都可以用作多机负载均衡的方案，它们各有优缺，在生产环境中需要好好分析实际情况并加以利用。自己多做测试，不仅可以提高技术水平，奕可找到真正适合自己的。
在使用上，一般最前端所采取的策略应是lvs，也就是DNS的指向应为lvs均衡器，lvs的优点令它非常适合做这个任务。
重要的ip地址，最好交由lvs托管，比如数据库的ip、webservice服务器的ip等等，这些ip地址随着时间推移，使用面会越来越大，如果更换ip则故障会接踵而至。所以将这些重要ip交给lvs托管是最为稳妥的，这样做的唯一缺点是需要的VIP数量会比较多。
nginx可作为lvs节点机器使用，一是可以利用nginx的功能，二是可以利用nginx的性能。当然这一层面也可以直接使用squid，squid的功能方面就比nginx弱不少了，性能上也有所逊色于nginx。
nginx也可作为中层代理使用，这一层面nginx基本上无对手，唯一可以撼动nginx的就只有lighttpd了，不过lighttpd目前还没有能做到nginx完全的功能，配置也不那么清晰易读。另外，中层代理的IP也是重要的，所以中层代理也拥有一个VIP和lvs是最完美的方案了。
nginx也可作为网页静态服务器，不过超出了本文讨论的范畴，简单提一下。
具体的应用还得具体分析，如果是比较小的网站（日PV<1000万），用nginx就完全可以了，如果机器也不少，可以用DNS轮询，lvs所耗费的机器还是比较多的；大型网站或者重要的服务，机器不发愁的时候，要多多考虑利用lvs。
1) 不使用session，换作cookie
能把session改成cookie，就能避开session的一些弊端，在从前看的一本J2EE的书上，也指明在集群系统中不能用session，否则惹出祸端来就不好办。如果系统不复杂，就优先考虑能否将session去掉，改动起来非常麻烦的话，再用下面的办法。
2) 应用服务器自行实现共享
已知的，php可以用数据库或memcached来保存session，从而在php本身建立了一个session集群，用这样的方式可以令 session保证稳定，即使某个节点有故障，session也不会丢失，适用于较为严格但请求量不高的场合。但是它的效率是不会很高的，不适用于对效率 要求高的场合。
以上两个办法都跟nginx没什么关系，下面来说说用nginx该如何处理：
3) ip_hash
nginx中的ip_hash技术能够将某个ip的请求定向到同一台后端，这样一来这个ip下的某个客户端和某个后端就能建立起稳固的session，ip_hash是在upstream配置中定义的：
upstream backend {
server 127.0.0.1:8001;
server 127.0.0.1:8002;
ip_hash;
}
ip_hash是容易理解的，但是因为仅仅能用ip这个因子来分配后端，因此ip_hash是有缺陷的，不能在一些情况下使用：
1/ nginx不是最前端的服务器。ip_hash要求nginx一定是最前端的服务器，否则nginx得不到正确ip，就不能根据ip作hash。譬如使用 的是squid为最前端，那么nginx取ip时只能得到squid的服务器ip地址，用这个地址来作分流是肯定错乱的。
2/ nginx的后端还有其它方式的负载均衡。假如nginx后端又有其它负载均衡，将请求又通过另外的方式分流了，那么某个客户端的请求肯定不能定位到同一 台session应用服务器上。这么算起来，nginx后端只能直接指向应用服务器，或者再搭一个squid，然后指向应用服务器。最好的办法是用 location作一次分流，将需要session的部分请求通过ip_hash分流，剩下的走其它后端去。
4) upstream_hash
为了解决ip_hash的一些问题，可以使用upstream_hash这个第三方模块，这个模块多数情况下是用作url_hash的，但是并不妨碍将它用来做session共享：
假如前端是squid，他会将ip加入x_forwarded_for这个http_header里，用upstream_hash可以用这个头做因子，将请求定向到指定的后端：
可见这篇文档：
http://www.oschina.net/discuss/thread/622
在文档中是使用$request_uri做因子，稍微改一下：
hash $http_x_forwarded_for;
这样就改成了利用x_forwarded_for这个头作因子，在nginx新版本中可支持读取cookie值，所以也可以改成：
hash $cookie_jsessionid;
假如在php中配置的session为无cookie方式，配合nginx自己的一个userid_module模块就可以用nginx自发一个cookie，可参见userid模块的英文文档：
http://wiki.nginx.org/NginxHttpUserIdModule
在nginx中做负载均衡的时候可以使用ip_hash和url_hash，其中url_hash为第三方模块。
1、ip_hash
upstream backend {
ip_hash;
server 10.0.2.1:80;
server 10.0.2.2:80;
}
server {
location / {
proxy_pass http://backend;
}
}
根据客户端IP进行负载均衡，针对同一个C类地址段中的客户端选择到后端同一个源服务器，可避免session引起的问题。
原文如下：
This directive causes requests to be distributed between upstreams based on the IP-address of the client.
The key for the hash is the class-C network address of the client. This method guarantees that the client request will always be transferred to the same server. But if this server is considered inoperative, then the request of this client will be transferred to another server. This gives a high probability clients will always connect to the same server.
参考：http://wiki.nginx.org/NginxHttpUpstreamModule
2、url_hash(第三方)
upstream backend {
server 10.0.2.1:80;
server 10.0.2.2:80;
hash $request_uri;
}
server {
location / {
proxy_pass http://backend;
}
}
根据url的hash结果来分配请求，使每个url定向到同一个后端服务器。可进一步提供后端缓存服务器(如squid等)效率。
参考：http://wiki.nginx.org/NginxHttpUpstreamRequestHashModule
看一个这样的架构：
squid<=>
nginx<=>server(s)
前端使用squid做缓存，后端用多台服务器，但多台服务器间的SESSION不共享，为了做负载均衡，使用nginx的
ip_hash来做，使得来源机器的会话是持续的。
于是便引起来了一个问题，使用nginx的ip_hash规则来做负载均衡时，得到的IP则始终是squid机器的IP，于是负载均衡便失效了。
同理，在使用nginx的ip_hash做负载均衡方案时也会存在这个问题，即realip的问题，nginx有一个realip的模块，但并没有解决ip_hash的realip的问题，因此当通过代理访问你的网站就会引起分布均的问题，这种情况在小范围的负载方案中会表现的尤为突出。
nginx中有一个ngx_http_request_t的数据结构，其中的x_forwarded_for存储的就是realip的信息(当然这是存在安全问题的).
