《Ourlinux》杂志

漏洞介绍：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;
}

本文来自：http://www.80sec.com/nginx-securit.html

好东西，收藏一下！

Fstorage是免费、开放的轻量级快速的文件系统。

（碧轩注：根据自己的策略可以方便实现分布式！）

支持的API有：python和php！

通过以上的api结合gx_http_fstorage_module，可以很方便实现文件的上传和下载，个人认为比较适合有一定文件存储需求的公司！

Fstorage如何工作？请看下图：

目前还只是0.2的版本，如果要线上使用，还是请小心为主，个人关注先，下载请移至官方：http://fstorage.pl/fstorage/downloads

威总威武：

Consistent Hashing 如下所示：首先求出所有备选服务器（节点）的哈希值，并将其
配置到0～232的圆（continuum）上。然后用同样的方法求出存储数据的键的哈希值，并
映射到圆上。然后从数据映射到的位置开始顺时针查找，将数据保存到找到的第一个服务器
上。如果超过232仍然找不到服务器，就会保存到第一台服务器上.

详细文档这里下载： nginx_hasnginx_upstream_hash 增加一致性hash

web 2.0海量小文件cache集群探讨(原创)

在互联网快速发展的背景下，特别是we2.0，网络上的数据内容呈几何级的增长，而其中增长最快并且最容易给技术架构带来挑战的就是数目庞大的小文件，如 何来解决这种高并发，大流量，小文件，热点不集中的问题，经过我们大量研究，实践之后，总结出这种海量小文件，高并发所存在的关键问题和解决方案。

我们先对比一下在web1.0的解决方案和web2.0的我们碰到的困难。

Web1.0
1、源数据量小，单台squid即可达到很高的命中率。
2、请求量大，用lvs+squid或者dns轮询即可解决问题。
3、squid服务器磁盘IO压力大，用超大内存做cache。

web 2.0
目前的瓶颈:
1、源数据数量很大，导致squid hash table 索引效率不高，Cache 命中率低。
为了提高对文件的访问效率，往往会在前端配置一个稍大容量的缓存。但由于小文件的数量极其庞大，应用对这些文件访问的随机性非常高，使得Cache 命中率极低，缓存失去了应有的作用，导致应用需要直接到后端存储系统上读取数据，给存储系统带来了极大的压力。刚开始就是我们也采用了昂贵的高端存储系统 NetApp，但是在用户高并发访问的情况下，存储系统经常出现长时间无响应的严重故障。

2、源数据容量巨大，海量文件检索效率低，从而也导致单台squid命中率很低。
有些频道数据容量会超过200T，单台squid只是杯水车薪，频繁的cache置换更是加剧了cache效率低下，再加上现有的存储系统无法有效管理海 量小文件，并且在单个目录下存放文件的数量有一定的限制，一旦文件数到达了一定规模之后，文件的检索速度就急剧下降。我们只能通过多级目录来组织存放大量 的小文件，随着目录深度的增加，文件的检索开销进一步增大，检索效率随之下降。

3、大量的cache导致的磁盘IO问题
由于目前单台cache容量已经达到上百G，文件系统瓶颈、磁盘IO问题也很快凸显。

4、压力过大导致的hit　ratio抖动
cache 删除，写操作达到一定的比例,同时如果压力较高，会导致hit ratio呈线性下降。即使cache没down，但也因为命中率的下降而失去应有的作用。

5、特殊集群下的单台失效问题
在类url hash的集群下，单台cache失效会导致hash rehash，那么整个集群的squid命中率都会被冲击。

如何来解决这些问题，思路如下：

1、优化squid hash table 索引算法,
需要修改源squid代码

2、cache集群，用类url hash的方法，以增加cache容量
1)、wccp: cisco的路由器均有此功能
2)、carp: ISA,squid自身的7层调度协议
3)、url hash: nginx haproxy等7层代理

3、选择合适的文件系统
XFS使用更多的内存来作为自己的高速缓存，以尽可能的延迟零散的写操作，尽可能的执行批量写操作。

4、选择更合理的磁盘搭配策略，比如Raid策略或者单盘策略等
Raid 5，10 带来了不错的安全性，但是会导致磁盘IO效率低下，不做Raid的单盘性能最高，更适合单台服务器多squid进程模式。

5、集群下的单台cache失效的接管，以免单点故障，提高可用性。

针对以上分析，我们大量尝试了开源的一些产品，像LVS，Nginx，Squid，XFS等。
具体的软件组合和架构如下：

（1）、web服务器的选择，目前，大多数web服务器的处理能力有限，互联网广泛上使用的web服务器如Apache，其并发能力往往在2000以下， 这是由web服务器自身的设计模式（如多进程，无IO缓存等）决定的。因此，在较大规模的访问情况下，通常会表现出用户访问网站慢，web 服务器负载高。为什么选择Nginx? use linux epoll, sendfile and aio to improve the performanc，我们主要利用的是Nginx的第三方模块ngx_http_upstream_hash_module做反向代理。

部分代码如下：
upstream img{
server squid1:81;
server squid2:81;
hash $request_uri;
hash_again 0; # default 0
hash_method crc32; # default “simple”
}

server {
listen 80;
server_name images.gx.com;
location / {
proxy_pass http://img;

(３)负载均衡软件，我们选择了LVS+HA，用DR模式。目前我们运行环境中的LVS（2.6的内核），普通很稳定。我们主要用Heartbeat+ldirectord。

(4) 适合处理小文件的文件系统XFS。XFS 最佳表现之一在于：象 ReiserFS 一样，它不产生不必要的磁盘活动。XFS 设法在内存中缓存尽可能多的数据，并且，通常仅当内存不足时，才会命令将数据写到磁盘时。当它将数据清仓（flushing）到磁盘时，其它 IO 操作在很大程度上似乎不受影响。

(5)其它优化
在客户端和服务器做大量有效的缓存策略;用更小的并且可缓存的图片（单张图片尽量不要超过200K）;尽量减少http请求;开起 keepalive减少tcp连接开销;优化tcp参数;起用多域名分域名策略;减少cookie影响等。

(6)关于优化题外：大配置和架构没有问题的前提下，有money的话应该首选硬件优化方案而不是软件细节优化。

整个架构如下图

后端存储垂直分割的规则如下(按00-ff散列)：

location ~ ^/[0-1][0-f]/ {
proxy_pass http://192.168.3.12;
}
location ~ ^/[2-3][0-f]/ {
proxy_pass http://192.168.3.11;
}

……..

以上这个架构的优化在于：
实现了高可用性，最大程度上防止单点，又保证架构的伸缩性。
在后端服务器中模拟url hash的算法来找到内容所在的squid，提高了命中率。
充分发挥机器的性能，架构可扩展性，层次分明。

最后，很重要的二点，1）要通过性能分析和监控，来找到系统瓶颈的临界点和薄弱点。监控分析是一切优化的重点，要以数据事实来调整策略。2）架构的负荷如果已经超过设计负荷的5~10倍，就要考虑重新设计系统的架构，我们这里仅仅讨论某一阶段的架构设计。

部份资料来源http://bbs.be10.com,http://www.dbanotes.net,http://ourlinux.net,特别感谢http://jsqyy.51.com,他在squid方面深有研究。

版权声明：转载时请以超链接形式标明文章原始出处和作者信息及本声明
http://syre.blogbus.com/logs/20092011.html

原文链接：http://php-fpm.anight.org/

fast-cgi是做啥用的

FastCGI是一个可伸缩的，高速地在web server和脚本语言间交互的接口。关于FastCGI技术的更多信息可以在官方网站和这里看到。

多数流行的web server都支持FastCGI。包括Apache(mod_fastcgi和mod_fcgid)，Zeus，nginx和lighttpd。

FastCGI的主要优点是把动态语言和web server分离开来。这种技术允许把web server和动态语言运行在不同的主机上，以大规模扩展和改进安全性而不损失生产效率。

php-fpm可以和任何支持远端FastCGI的web server工作。

更多见：http://syre.blogbus.com/logs/20092011.html