Zend-v3.3.9 下载
3.3.9-i386http://downloads.zend.com/optimi ... glibc23-i386.tar.gz
v3.3.9-X86
http://downloads.zend.com/optimi ... ibc23-x86_64.tar.gz
攻击的原理很简单, 目前很多语言, 使用hash来存储k-v数据, 包括常用的来自用户的POST数据, 攻击者可以通过构造请求头, 并伴随POST大量的特殊的”k”值(根据每个语言的Hash算法不同而定制), 使得语言底层保存POST数据的Hash表因为”冲突”(碰撞)而退化成链表. 这个攻击方法危害很高, 攻击成本也很小. 一个台式机可以轻松搞垮数十台, 上百台服务器. 实例: $size = pow(2, 16); // 16 is just an example, could also be 15 or 17 $startTime = microtime(true); $array = array(); for ($key = 0, $maxKey = ($size - 1) * $size; $key <= $maxKey; $key += $size) { $array[$key] = 0; } $endTime = microtime(true); echo 'Inserting ', $size, ' evil elements took ', $endTime - $startTime, ' seconds', "\n"; $startTime = microtime(true); $array = array(); for ($key = 0, $maxKey = $size - 1; $key <= $maxKey; ++$key) { $array[$key] = 0; } $endTime = microtime(true); echo 'Inserting ', $size, ' good elements took ', $endTime - $startTime, ' seconds', "\n"; https://github.com/laruence/laru ... -5.2-max-input-vars 另外, 其他语言java, ruby等, 请各位也预先想好对策, 限制post_size是治标不治本的方法, 不过可以用来做临时解决方案. 参考文章: http://nikic.github.com/2011/12/ ... ng-a-PHP-array.html http://www.laruence.com/2011/12/30/2440.html php.ini 中禁止一些函数,增加安全性# vi /usr/local/php/etc/php.ini找到: disable_functions = 设置为: passthru,exec,system,chroot,scandir,chgrp,chown,shell_exec,proc_open,proc_get_status,ini_alter,ini_alter,ini_restore,dl,pfsockopen,openlog,syslog,readlink,symlink,popepassthru,stream_socket_server Nginx中禁止访问.txt文件location ~* \.(txt|doc)$ {if (-f $request_filename) { root /home/domain/public_html/test; break; } } Nginx出现413 Request Entity Too Large处理Nginx出现的413 Request Entity Too Large错误这个错误一般在上传文件的时候出现,打开nginx主配置文件nginx.conf,找到http{}段,添加 client_max_body_size 8m; 重新加载nginx的配置 nginx -t kill -HUP nginx_pid 要是跑php的话这个大小client_max_body_size要和php.ini中的如下值的最大值一致或者稍大,这样就不会因为提交数据大小不一致出现的错误。 post_max_size = 8M upload_max_filesize = 2M 重启php-cgi killall php_cgi php_cgi start Nginx 的编译安装# tar zxvf nginx-0.6.29-tar.gz# cd nginx-0.6.29 ./configure \ "--prefix=/usr/local/nginx" \ "--sbin-path=/usr/local/nginx/sbin/nginx" \ "--conf-path=/usr/local/nginx/conf/nginx.conf" \ "--error-log-path=/usr/local/nginx/logs/error.log" \ "--http-log-path=/usr/local/nginx/logs/access.log" \ "--pid-path=/usr/local/nginx/var/nginx.pid" \ "--lock-path=/usr/local/nginx/var/nginx.lock" \ "--http-client-body-temp-path=/dev/shm//nginx_temp/client_body" \ "--http-proxy-temp-path=/dev/shm/nginx_temp/proxy" \ "--http-fastcgi-temp-path=/dev/shm/nginx_temp/fastcgi" \ "--user=www" \ "--group=www" \ "--with-cpu-opt=pentium4F" \ "--without-select_module" \ "--without-poll_module" \ "--with-http_realip_module" \ "--with-http_sub_module" \ "--with-http_gzip_static_module" \ "--with-http_stub_status_module" \ "--without-http_ssi_module" \ "--without-http_userid_module" \ "--without-http_geo_module" \ "--without-http_memcached_module" \ "--without-http_map_module" \ "--without-mail_pop3_module" \ "--without-mail_imap_module" \ "--without-mail_smtp_module" \ "--with-pcre" # make # make install # mkdir /dev/shm/nginx_temp 注:有时会因为pcre编译不过去,需要修改一下 --with-pcre=/usr/local/src/pcre-7.8,前提是已经下载了pcre源码包,并解压,不需要编译pcre。 nginx打开目录浏览功能nginx默认是不允许列出整个目录的。如需此功能,打开nginx.conf文件,在location server 或 http段中加入 autoindex on; 另外两个参数最好也加上去: autoindex_exact_size off; 默认为on,显示出文件的确切大小,单位是bytes。 改为off后,显示出文件的大概大小,单位是kB或者MB或者GB autoindex_localtime on; 默认为off,显示的文件时间为GMT时间。 改为on后,显示的文件时间为文件的服务器时间 详细参照:http://wiki.nginx.org/NginxChsHttpAutoindexModule 关于Nginx遇到*.php的错误页面不能跳转问题1、最简单的重定向404页面(404.html为自定义的页面) error_page 404 /404.html; 2、需要重定向4** 5** 的所有的页面(error.html为自定义页面) error_page 402 403 404 500 502 503 504 /error.html; 3、需要重定向请求错误的php页面 如果是一般的文件上面的都可以解决,但是如果是PHP的,就会出no input file specified.或者是直接在浏览器输出404 需要在主配置文件nginx.conf 中 fastcgi 位置加上 fastcgi_intercept_errors on; 默认是关闭的 PS:特别注意的是404.html(自定义的文件)文件页面大小要超过512k,不然会被ie浏览器替换为ie默认的错误页面。 总结:需要将*.php的错误页面跳转的三步骤: 1,自定义404.html或404.php的跳转页面,文件大小超过512k 2,主配置文件nginx.conf加入fastcgi_intercept_errors on参数 3,error_page设置,需要将哪些系统返回状态做跳转 【转帖】Nginx优化use参数epoll,kqueue,rtsig,eventport,poll源自:www.nginx8.cn下图对比了poll select epoll和kqueue的性能。select和poll是一个级别的,epoll和kqueue是一个级别的,相差不多。epoll用在linux上,kqueue用在bsd上,不能物理上共存。如果你的服务器cpu较好,linux内核新,可考虑用epoll. Basically what this says is that FreeBSD's kqueue out-performs Linux's epoll by a bit. select() and poll() are anachronisms. As an aside, libevent rocks and I use it all the time for writing portable network code. It allows you to use the best available I/O multiplexing functionality on a given platform without having to write seperate code for all of them via a fairly coder-friendly API, and has a nice little async DNS library with it to boot. Macro的某个机器(centos5.3,e7300)的nginx从默认的没有use设置改为use epoll后实际情况 load average: 0.14, 0.21, 0.26,负载似乎减少了0.1,可能并发请求量不大,暂时没看出有多大效果 : Active connections: 2548 server accepts handled requests 35279765 35279765 59264847 Reading: 13 Writing: 16 Waiting: 2519 freebsd里的kqueue和linux 2.6下的epoll 两个东西极其相似,写好了一个之后,移到别外一个平台下,只要稍作修改就可以了,原理是一样,个人认为,从功能角度来盾kqueue比epoll灵活得多。在写kqueue的时候,内核帮你考虑好了不少东西。但是从效率来看,从我作的压力测试来看epoll比kqueue强。看看我的实验结果吧 客户端: linux ,P3,256M ,pthread多线程程序,开1万个线程,可是实际运行结果是,在linux2.4上只能打开4000多个线程的时候就报资源不足,郁闷了好久,不知道是什么资源,最大打开文件数是够了,内存也够(通过设置16k的栈空间)。后来把客户端移到linux2.6内核下,很快开出1万个线程来了。 epoll服务器端:P3,256M,在一万个并发线程下,面不改色,有条不紊地处理着数据,并发数能达到8000个连接。 kqueue 服务器端:结果比较失望,在只能一条队列的情况下,并发数只能到2000,然后在客户端的读取数据时就会出现"connect reset by peer"的错误。后来改用了两条队列,一条用来接收新连接,一条用来处理原有的连接。在这种情况下,并发数也只能到3000,然后又会陆陆续续出现连接的错误。 Nginx优化use参数epoll,kqueue,rtsig,eventport,poll和select的区别 参考:http://wiki.nginx.org/NginxOptimizations Event ModelsNginx supports the following methods of treating the connections, which can be assigned by the use directive: select - standard method. Compiled by default, if the current platform does not have a more effective method. You can enable or disable this module by using configuration parameters --with-select_module and --without-select_module.poll - standard method. Compiled by default, if the current platform does not have a more effective method. You can enable or disable this module by using configuration parameters --with-poll_module and --without-poll_module.kqueue - the effective method, used on FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 and MacOS X. With dual-processor machines running MacOS X using kqueue can lead to kernel panic.epoll - the effective method, used on Linux 2.6+. In some distrubutions, like SuSE 8.2, there are patches for supporting epoll by kernel version 2.4.rtsig - real time signals, the executable used on Linux 2.2.19+. By default no more than 1024 POSIX realtime (queued) signals can be outstanding in the entire system. This is insufficient for highly loaded servers; it's therefore necessary to increase the queue size by using the kernel parameter /proc/sys/kernel/rtsig-max However, starting with Linux 2.6.6-mm2, this parameter is no longer available, and for each process there is a separate queue of signals, the size of which is assigned by RLIMIT_SIGPENDING. When the queue becomes overcrowded, nginx discards it and begins processing connections using the poll method until the situation normalizes./dev/poll - the effective method, used on Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+ and Tru64 UNIX 5.1A+.eventport - the effective method, utilized in Solaris 10. To avoid kernel panic, it is necessary to install this security patch. Nginx的主配置文件user www www;worker_processes 4; ##开启4个进程,经我测试2足够,如果你服务器cpu资源很多,那么就分配为cpu的1倍或2倍 #error_log logs/error.log; #error_log logs/error.log notice; #error_log logs/error.log info; pid var/nginx.pid; worker_rlimit_nofile 51200; ##指一个nginx进程打开的最大文件描述符个数,理论值应该和(ulimit -n )结果数值和nginx进程数值相除的结果一致,但实际中不可能有这样均匀,所以最好和ulimit -n 的值一致。 events { use epoll; ##使用epoll的I/O模型 worker_connections 4096; ##每个进程允许的最多连接数,理论上每台nginx服务器的最大连接数为worker_processes * worker_connections } http { include mime.types; default_type application/octet-stream; server_names_hash_max_size 512; server_names_hash_bucket_size 128; sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 1; ##keepalive超时时间 client_header_timeout 10; client_body_timeout 10; send_timeout 30; client_header_buffer_size 4k; ##客户端请求头部的缓冲区大小,这个可以根据你的系统分页大小来设置,一般一个请求头的大小不会超过1k,不过由于一般系统分页都要大于1k,所以这里设置为分页大小。分页大小可以用命令getconf PAGESIZE取得 # open_file_cache max=51200 inactive=20s; ##这个将为打开文件指定缓存,默认是没有启用的,max指定缓存数量,建议和打开文件数一致,inactive是指经过多长时间文件没被请求后删除缓存 # open_file_cache_valid 30s; ##这个是指多长时间检查一次缓存的有效信息 # open_file_cache_min_uses 1; ##open_file_cache指令中的inactive参数时间内文件的最少使用次数,如果超过这个数字,文件描述符一直是在缓存中打开的,如上例,如果有一个文件在inactive时间内一次没被使用,它将被移除。 large_client_header_buffers 4 4k; client_body_temp_path /dev/shm/nginx_temp/client_body 1 2; ###### ##一般情况下压缩后的html、css、js、php、jhtml等文件,大小能降至原来的25%,也就是说,原本一个100k的html,压缩后只剩下25k。这无疑能节省很多带宽,也能降低服务器的负载。 ###### gzip on; //打开gzip压缩 gzip_min_length 1024; ##设置允许压缩的页面最小字节数,页面字节数从header头中的Content-Length中进行获取,默认值是0,不管页面多大都压缩,建议设置成1024,小于1k可能会越压越大 gzip_buffers 4 8k; ##设置系统获取几个单位的缓存用于存储gzip的压缩结果数据流。例如 4 4k 代表以4k为单位,按照原始数据大小以4k为单位的4倍申请内存。 4 8k 代表以8k为单位,按照原始数据大小以8k为单位的4倍申请内存。如果没有设置,默认值是申请跟原始数据相同大小的内存空间去存储gzip压缩结果。 gzip_http_version 1.1; ##识别http的协议版本。由于早期的一些浏览器或者http客户端,可能不支持gzip自解压,用户就会看到乱码,所以做一些判断还是有必要的。注:现在除了类似于百度的蜘蛛之类的东西不支持自解压,99.99%的浏览器基本上都支持gzip解压了,所以可以不用设这个值,保持系统默认即可。 gzip_comp_level 5; ##gzip压缩比,1 压缩比最小处理速度最快,9 压缩比最大但处理最慢(传输快但比较消耗cpu)。 gzip_types text/plain text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript; ##匹配MIME类型进行压缩,(无论是否指定)"text/html"类型总是会被压缩的。 log_format main '$remote_addr - $remote_user [$time_local] $request ' '"$status" $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; ##记录日志的格式,这里的main是自定义的,目的是在后边的vhosts/* 中用到 access_log "logs/access.log" main; ##规定记录日志的文件,格式为main格式(上边定义的) include vhosts/*; //vhosts/目录下就是我们的虚拟主机配置文件了 } 【转】Nginx 的 server_names_hash_bucket_size 问题在 Nginx 0.6.35 的版本中,配置多个 server 虚拟主机,必须要在配置文档中 http { 里头加上 server_names_hash_bucket_size 64; 这么一句http { server_names_hash_bucket_size 64; include mime.types; default_type application/octet-stream; ………….省略 } 不然不但 nginx 启动不了,而且 nginx -t 测试配置文档的时候会提示 could not build the server_names_hash, you should increase server_names_hash_bucket_size: 32 2009/02/20 13:54:27 [emerg] 11372#0: the configuration file /opt/nginx/conf/nginx.conf test failed 下面是在中文wiki上摘抄的一段说明 保存服务器名字的hash表是由指令 server_names_hash_max_size 和 server_names_hash_bucket_size所控制的。参数hash bucket size总是等于hash表的大小,并且是一路处理器缓存大小的倍数。在减少了在内存中的存取次数后,使在处理器中加速查找hash表键值成为可能。如果 hash bucket size等于一路处理器缓存的大小,那么在查找键的时候,最坏的情况下在内存中查找的次数为2。第一次是确定存储单元的地址,第二次是在存储单元中查找键 值。因此,如果Nginx给出需要增大 hash max size 或 hash bucket size的提示,那么首要的是增大前一个参数的大小. |