限定某个目录禁止解析php，限制user_agent，php相关配置
限定某个目录禁止解析php，限制user_agent，php相关配置
笔记内容：
- 11.28 限定某个目录禁止解析php
- 11.29 限制user_agent
- 11.30/11.31 php相关配置
笔记日期：
11.28 限定某个目录禁止解析php
如果我们的网站有一个目录，可以上传图片，可能保不准有些别有用心的人会通过一些手段，上传php文件到这个目录下。那么这个php文件就会被apache执行，如果这个php文件里写的是恶意代码，你的服务器自然就会遭到***。毕竟开放了这样一个权限，肯定会被人上传***文件，如果被夺取了你的服务器root权限就很危险了。
要禁止php解析，首先配置虚拟主机配置文件，加上以下内容：
<Directory /data/wwwroot/111.com/upload>
php_admin_flag engine off
<FilesMatch (.*)\.php(.*)>
Order allow,deny
Deny from all
</FilesMatch>
</Directory>
修改完成并重新加载配置文件后，先创建一个目录，然后拷贝一个php文件过去：
接下来就可以进行测试了，状态码为403就没问题：
浏览器就会先显示Forbidden：
现在把FilesMatch那一行注释掉，看看是否会看到php文件的源代码：
可以看到直接显示了我源代码，并没有进行解析。
如果是在浏览器中访问的话，就会直接下载了，因为无法解析：
常识：在服务器中存放静态文件的目录，99%是不允许存放php等文件的，所以不用担心禁止解析的问题。
11.29 限制user_agent
访问控制-user_agent的需求背景：比如说我们的网站，有可能会受到CC***，CC***的大概原理就是***的人，他通过一些手段，例如他通过发动肉鸡的方式，使用几千或上万台肉鸡同时访问一个网站。那么这个网站就会同时有几千上万个请求，一般普通的网站是承受不了这么大的并发量的，所以这个网站就会很容易就崩掉，这就是所谓的CC***。这种CC***是有一定的规律的，例如它们的-user_agent就是一致的，所以我们也可以以此来判定这是CC***。遇到这种-user_agent很规律或完全一致的请求，我们就可以通过限制-user_agent，来减轻服务器的压力。
同样的要限制-user_agent，首先配置虚拟主机配置文件，增加以下内容：
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} .*curl.* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} .*baidu.com.* [NC]
RewriteRule .* - [F]
</IfModule>
修改完成并重新加载配置文件后，就可以进行测试了，先用curl命令访问，状态码为403就没问题：
自定义-user_agent后再试一下，使用-A选项模拟-user_agent，状态码为200就没问题，因为配置文件里的限制条件里只限制了curl和baidu.com：
这时查看日志文件也可以查看到-user_agent的确是我们自定义的名称，所以仅仅只会匹配限制条件里定义的-user_agent：
11.30/11.31 php相关配置
关于php配置文件位置的问题，这里要注意一点：有时候使用-i选项去找这个配置文件的话，可能找到的是与你浏览器上网站所使用的php.ini不是同一个，想要精确一点去找这个配置文件最好使用phpinfo去找。
例如111.com，我想找到这个网站所使用的php.ini文件在哪里，那就要在这个111.com的网站目录下创建一个phpinfo的页面。然后通过浏览器去访问，就可以看到这个php.ini文件在哪。
创建一个php文件：
文件内容如下：
使用浏览器访问这个页面：
因为没有加载配置文件，所以得去php的源码包里拷贝一份这个配置文件，拷贝完之后还要重新加载Apache的配置文件：
cd /usr/local/src/php-7.1.6/
cp php.ini-development /usr/local/php7/etc/php.ini
/usr/local/apache2.4/bin/apachectl graceful
现在我们就可以打开php.ini文件进行一些配置了：
vim /usr/local/php7/etc/php.ini
简单介绍几种常用的配置：
1.配置disable_functions，可以禁止某些危险函数的解析。比如一句话***就用到了其中的eval函数，代码示例：
禁用掉eval函数的话，这种***就无法被解析了。
列举一些比较危险的函数：
eval,assert,popen,passthru,escapeshellarg,escapeshellcmd,passthru,exec,system,chroot,scandir,chgrp,chown,escapeshellcmd,escapeshellarg,shell_exec,proc_get_status,ini_alter,ini_restore,dl,pfsockopen,openlog,syslog,readlink,symlink,leak,popepassthru,stream_socket_server,popen,proc_open,proc_close
配置disable_functions，这个属性默认是空的：
现在我们把刚刚列举的那些危险的函数都配置进去，把它们都给禁掉：
在大多数的公司会在生产环境中把phpinfo给禁掉，因为怕有时候不小心将phpinfo页面上传到了线上去了。如果这个页面被外部的***访问到的话，就能看到你服务器上的一些目录。那么***获取到了这些信息后，就可以更容易的进行***。
所以为了安全起见也要把phpinfo给禁止掉：
禁止phpinfo后，测试一下看看能不能解析，显示如下内容就是这个函数已经被禁止解析了：
2.date.timezone 的配置，配置date.timezone 就是定义一下时区，不然有时候会有一些警告信息。
例如我定义时区为上海：
3.日志相关的配置：
error_log, log_errors, display_errors, error_reporting
如果没有配置日志就会像刚才那样直接显示在浏览器上。
display_errors属性是用于定义是否显示日志信息在在浏览器上：
直接显示在浏览器上会暴露目录，所以要把这个值改为Off：
这时候再访问就不会显示日志信息了：
然后就是配置错误日志：
log_errors属性用于定义错误日志是否开启：
error_log属性用于定义错误日志的存放路径：
error_reporting属性是用于定义error_log的级别，如果定义的级别比较高的话，就只会记录比较严重的错误，警告之类的就不会记录。error_reporting属性默认为E_ALL级别，E_ALL就是把所有的错误都记录，级别比较低。在生产环境中，一般使用E_ALL & ~E_NOTICE级别。
配置完成后，重新加载Apache的配置文件，然后测试一下看看在tmp下是否会生成错误日志：
可以看到这个文件的属主和属组都是daemon：
daemon是httpd的属组，所以这个日志实际上是以http这个进程的身份生成的：
有时候这个日志定了路径却没有生成的话，就得查看一下是否是权限的问题，也可以自己事先在定义的路径下创建好日志文件，并定义权限为777。
再来模拟一个错误：
创建一个php文件：
vim /data/wwwroot/111.com/2.php
随便写些内容：
访问这个文件的话，状态码就会为500：
查看错误日志可以看到这个错误为error：
open_basedir是一个安全选项，如果你一台服务器上跑了n多个站点，保不准某个站点的代码有问题写得比较差漏洞比较多，所以如果这个站点被黑了，被人拿到了权限后继续***的话，可能会***到其他的站点，和俗话说的一颗老鼠屎坏了一锅粥的道理一样。但是这时候如果增加了open_basedir的话，那么就可以能黑不了其他网站，例如：A网站放在A目录下，B网站放在B目录下，然后给这两个目录做一个隔离，所以即使A目录被黑了，也黑不到B目录下，因为无法查看到B目录。
配置php.ini文件：
我现在故意把目录写成1111.com，模拟一下这种情况：
这时使用curl命令去访问就会出现500状态码：
查看日志文件可以知道，访问的文件并没有在允许的目录下：
现在把open_basedir改为111.com，再测试一下，这时就正常了：
但是配置php.ini的open_basedir并没有意义，因为这样的配置只能是配置全部站点的，因为所有的站点都放在一个目录下，不能针对单个站点去做，所以和没有配置没差别，例如只能这样配置，但是没有意义：
想要针对单个站点去配置open_basedir的话，需要在apache的虚拟主机配置文件里面去配置，配置的语法如下：
php_admin_value open_basedir "/data/wwwroot/111.com:/tmp/"
我们可以在这个文件里针对不同的虚拟主机，配置不同的open_basedir。