php安全配置记录和常见错误梳理(总结)

[HOST=www.wangshibo.com] 
open_basedir=/home/www/www.wangshibo.com:/tmp/:/proc/
[PATH=/home/www/www.wangshibo.com] 
open_basedir=/home/www/www.wangshibo.com:/tmp/:/proc/ 

open_basedir=/home/www/www.wangshibo.com:/tmp/:/proc/ 

disable_functions = pcntl_alarm, pcntl_fork, pcntl_waitpid, pcntl_wait, pcntl_wifexited, pcntl_wifstopped, pcntl_wifsignaled, pcntl_wexitstatus, pcntl_wtermsig, pcntl_wstopsig, pcntl_signal, pcntl_signal_dispatch, pcntl_get_last_error, pcntl_strerror, pcntl_sigprocmask, pcntl_sigwaitinfo, pcntl_sigtimedwait, pcntl_exec, pcntl_getpriority, pcntl_setpriority, eval, popen, passthru, exec, system, shell_exec, proc_open, proc_get_status, chroot, chgrp, chown, ini_alter, ini_restore, dl, pfsockopen, openlog, syslog, readlink, symlink, popepassthru, stream_socket_server, fsocket, chdir

[root@i-v5lmgh7y etc]# /usr/local/php/sbin/php-fpm 
[root@i-v5lmgh7y etc]# ps -ef|grep php 
[root@i-v5lmgh7y etc]#lsof -i:9000 
[root@i-v5lmgh7y etc]# 
 
查看错误日志发现问题： 
[root@i-v5lmgh7y log]# tail -f php-fpm.log 
[15-Nov-2015 23:53:15] NOTICE: fpm is running, pid 18277 
[15-Nov-2015 23:53:15] ERROR: failed to prepare the stderr pipe: Too many open files (24) 
[15-Nov-2015 23:53:16] NOTICE: exiting, bye-bye! 
[15-Nov-2015 23:53:59] NOTICE: fpm is running, pid 18855 
[15-Nov-2015 23:53:59] ERROR: failed to prepare the stderr pipe: Too many open files (24) 
[15-Nov-2015 23:54:00] NOTICE: exiting, bye-bye! 
 
发现是系统允许打开的文件数超了预定的设置。需要调大这个值： 
[root@i-v5lmgh7y etc]# ulimit -n 
1024 
[root@i-v5lmgh7y etc]# ulimit -n 65535  //临时解决办法 
[root@i-v5lmgh7y etc]# ulimit -n 
65535 
 
 
永久解决办法： 
在/etc/security/limits.conf文件底部添加下面四行内容： 
[root@i-v5lmgh7y etc]# cat /etc/security/limits.conf 
......... 
# End of file 
* soft nproc unlimited 
* hard nproc unlimited 
* soft nofile 65535 
* hard nofile 65535 
 
然后再次启动php-fpm程序，9000端口就能正常启动了 
[root@i-v5lmgh7y etc]# /usr/local/php/sbin/php-fpm 
[root@i-v5lmgh7y etc]# ps -ef|grep php 
root 21055 1 0 00:12 ? 00:00:00 php-fpm: master process 
(/usr/local/php/etc/php-fpm.conf) 
nobody 21056 21055 0 00:12 ? 00:00:00 php-fpm: pool www 
nobody 21057 21055 0 00:12 ? 00:00:00 php-fpm: pool www

1）request_terminate_timeout的值如果设置为0或者过长的时间，可能会引起file_get_contents的资源问题。 
如果访问请求的远程资源反应过慢，php-cgi进程就会一直卡在那里不会超时。虽然php.ini文件里面max_execution_time可以设置PHP脚本的最大执行时间，但是，在php-cgi(php-fpm) 中该参数不会起效。真正能够控制PHP脚本最大执行时间的是php-fpm.conf配置文件中的request_terminate_timeout参数。 
 
request_terminate_timeout默认值为0秒，也就是说，PHP脚本会一直执行下去。这样当所有的php-cgi进程都卡住时，这台Nginx+PHP的WebServer已经无法再处理新的PHP请求了，Nginx 将给用户返回“502 Bad Gateway”。 
修改该参数，设置一个PHP脚本最大执行时间是必要的，但是治标不治本。例如改成30s，如果发生访问获取网页内容较慢的情况，这就意味着150个php-cgi进程，每秒钟只能处理5个请求，WebServer同样很难避免”502 Bad Gateway”。 
 
解决办法是request_terminate_timeout设置为10s或者一个合理的值。 
 
2）max_requests参数配置不当，可能会引起间歇性502错误 
设置每个子进程重生之前服务的请求数. 对于可能存在内存泄漏的第三方模块来说是非常有用的. 
如果设置为0，则一直接受请求，等同于php_fcgi_max_requests环境变量。默认值为 0. 
比如：pm.max_requests = 1000 这个配置的意思是，当一个 php-cgi 进程处理的请求数累积到500个后，自动重启该进程。 
 
但是为什么要重启进程呢？ 
一般在项目中，多多少少都会用到一些PHP的第三方库，这些第三方库经常存在内存泄漏问题，如果不定期重启php-cgi进程，势必造成内存使用量不断增长。因此php-fpm作为php-cgi的管理器，提供了这么一项监控功能，对请求达到指定次数的php-cgi进程进行重启，保证内存使用量不增长。正是因为这个机制，在高并发的站点中，经常导致502错误， 
目前解决方法是，把这个值尽量设置大些，尽可能减少php-cgi重新SPAWN的次数，同时也能提高总体性能。在实际的生产环境中发现，内存泄漏如果不明显，可以将这个值设置得非常大（比如204800）。要根据自己的实际情况设置这个值（比如我们线上设置1024），不能盲目地加大。 
话说回来，这套机制目的只为保证php-cgi不过分地占用内存，为何不通过检测内存的方式来处理呢？通过设置进程的峰值内在占用量来重启php-cgi进程，会是更好的一个解决方案。 
 
3）php-fpm的慢日志，debug及异常排查神器 
request_slowlog_timeout设置一个超时的参数，slowlog设置慢日志的存放位置