荣斌的BLOG

我的VPS，前端nginx，apache处理php，都使用www,www来运行，PHP基本上用默认配置，安全模式未开，disable_functions为空。网站程序的文件，隶属于www,www。

昨天看一朋友的博客，感觉自己的配置存在隐患。哪天出问题，被上传有问题的php文件，加上用php执行系统命令，那我就要哭了。

例如用这句读取文件的内容

<?php
echo readfile(/etc/passwd);
?>

昨天好好谷歌了一把，发现php原来也是挺脆弱的呀。这也让我开始慢慢喜欢上centos，之前我是一个ubuntu迷，一出新版，我必升。而在centos下，时常五六天，甚至更久，yum update都是0。网罗了下，发现网络上提到了有以下三种。

1、在apache里头给虚拟主机增加open_basedir，让php可执行限定在特定目录。只是有文章说，这样会影响IO性能，想想也是，多了一个环节检查 ，能省则省也好，另外就单独使用open_basedir，按照我前面的权限配置，虚拟主机还是会被迫害。

2、在php.ini里设定disable_functions。目的是让相应的函数不被支持，这个主意不错，只是默认php.ini配置上就没限制，应该也有它的考虑才是， 一般我们没跑面板管理程序的话，涉及到系统类的函数我们是可以放心禁用掉的，这个是不错，但我暂时不采取。

3、通过配置磁盘文件的用户权限，让apache在相应网站目录里的执行权限降低，从底层上，不让相应木马php之类的文件有机可乘。这个当前最合 我意。

因为VPS就我一人独用；二来，运行的程序也就在wordpress,phpwind,discuz之类的开源，安装插件个人也小心，最大的隐患是有人刻意在这些代码里下套，那样算我认栽，但应该也不至于就此沦陷。

我大概说下网站目录图（PS：肯定不是我真实服务器上存放的目录）
＋/var/www根目录
＋　　　　/var/www/a 网站a.com
＋　　　　　　　　/var/www/a/upload 附件上传目录
＋　　　　/var/www/b 网站b.com
＋　　　　/var/www/c 网站c.com

下面是操作，一共分为两个步骤，一个是文件权限的操作，一个是nginx补充配置。

先是第一部分：

shell>chown root:www /var/www
shell>chmod 710 /var/www

//除了www可以执行网站程序，剩下root账号才有权进入该目录。

shell>chown -R root:root /var/www/*

//默认情况下想创建或修改文件，非root不可

shell>chhown -R www:www /var/www/a/upload

//设定一个目录，可供上传

第二部分，对可供上传upload目录在nginx做相应的补充。

打开虚拟站点a的配置文件，在php转发到apache之前语句，加上

location ~* ^/upload/.*\.php$ {
deny all;
}

//这样，唯一对www开放权限的目录，把从上传时，不幸逃过的php文件，在传送给apache之前，拦截下来。

总结一下：系统里的文件，包括程序文件的修改，只能通过root来；可供上传的目录，你可以上传文件，但PHP文件的话，上传了也没用。

不方便的地方，这样wordpress后台的直接升级功能将不能用，不过我到时候会采取，在升级之前，先改变磁盘文件上的权限，等升级完毕后，再重新将其改回来，毕竟又不是十天半个月就做升级的。

我有这样一个需求，我需要利用N个二级域名来建立N个站点。出于简化日后对二级域名管理的难度，以及nginx的性能，我选择了在DNS端，设定一条泛解析的A记录。然后由nginx来将相应的二级域名解析到二级目录中。当相应的域名没有相应的二级目录对应时，就返回404错误。

同时，在apache端（我的配置是前端跑nginx，处理动态交给apache的形式），也进行相应的二级域名转发，这样，从nginx接收过来php，也能立马处理。

这里说下主机端这边的配置，如果有纰漏的，还请看到的人，帮忙指出，我不想让自己的主机因为我的设置，有朝一日变成肉鸡，呵呵。

server {
server_name *.test.com; //泛解析

index index.html index.htm index.php;

if ( $host ~* (\w+)\.\w+\.\w+ ) { //获取二级域名
set $subdomain /$1;
}
root /srv/www/test$subdomain; //设定二级域名的root目录

...... //剩余部分省略

}

我看过一些网络上的文章，一般对指定root目录的时候，一般都是放在location / {} 不过在我这，我没法这么设定，另外这样设定还有一些局限性，在我的配置里头，还有对一些文件后缀做expires设定，以及反盗链的设定。这部分设定同样也是通过location来进行的。例如我的这部分配置文件为：

location ~ \.(gif|jpg|jpeg|png|bmp|ico|swf|js|css)$ {
		expires 7d;

		valid_referers none blocked *.test.com;
		if ($invalid_referer) {
			rewrite ^/ http://$server_name;
			#return 500;
		}
}

所以当匹配到css文件之类时，对于这部分内容，会由于它缺少正确的root设置而导致相应的CSS文件找不到。当然会出现这样的错误，也同我的配置有关系，我是将上面这段，直接写成一个文件，然后在各个虚拟机中使用include来调用的，因此这就需要保证这个文件通用性。否则可以通过在上面这段location中，再次增加一个root，也可以解决，呵呵，我个人还是喜欢简介，高效性的配置。

接下来是后端的apache的接收部分，经过我验证，保证能运行。这里有段小插曲，这段rewrite还是从国外的网站找到的，不知道是不是我的搜索水平有问题，我发现中文的技术文章，大家写的都是一样的，多统一呀，呵呵。但在我这，还是没能成功跑起来。

<VirtualHost 10.241.116.8> //用这个IP，而不是127.0.0.1，是由于我在两台服务商都架设了apache来跑php
	DocumentRoot /srv/www/test
	ServerAlias *.test.com //这里设定泛解析，我发现设定了这条之后，是可以不再设定ServerName的，所以我就也给省了。
	RewriteEngine on
	RewriteCond %{HTTP_HOST} ^([^.]+)\.qdun\.net$ [NC] //这里是获取二级域名头，我还是给加上了nc，将其转化成小写的终归不会有错误(2012年2月27日纠正：nc为忽略大小写，而非转换成小写)
	RewriteCond /srv/www/test/%1 -d //判断二级域名的相应目录时候是否存在
	RewriteRule ^(.*) /%1/$1 [L] //当两者条件都成功之后，才进行重定向
</VirtualHost>

PS：写完收工，希望这个月备案能下来，已经由于某某原因被拖了一个月，真是烧钱哪。还有人生大事上也能有点进展，我对2012还是很敬畏的。

我发现玩服务器配置，挺好玩的。刚开始只玩一个，后来知道阿里云有一个负载均衡功能，就再入手了一个。玩到现在，差不多就要满一个月的时间了。

首先说备案，很悲剧，我的备案由于浙江监管局的一些临时变化，再审核到我这一批时，统统被拒绝了。原因有两方面，我觉得管局和阿里云备案都有些责任。管局应该也是这个星期开始执行新制度，对备案的网站，都需要备案人员的身份证复印件还有其它等等云云，也就是说，之前并没有这些东西也给过。阿里云的备案问题在于，管局提到的这些东西，作为我们来说，都已经准备妥当，快递到了杭州的阿里云，只是在提交上，阿里云备案人员，按照之前的习惯，也就没把这些东西继续再往上递。因此最吃亏的就是我们这些要备案的人，截止目前为止，我算是已经白白的被搭进了1个月的使用费用。

再来就是主机了，说句实话，排除掉可供选择的linux发行版有限这个问题外，我个人对阿里云提供的主机很满意。每台主机上面都有一个内网IP和外网IP。有意思的是，如果我们拥有两台阿里云主机的话，里头的这个内网IP是可以互通的，这样就让对整合多台服务器，处理不同的任务成了可能。安全方面不用担心，事实证明，不同用户之间的阿里云主机，内网是不相通的。

在我购买第二台阿里云时，主要是阿里云的负载均衡吸引了我。事实上也的确有点效果，只是让我体验完之后，我发现这种模式我不喜欢。只要有两台阿里云主机，就可以申请使用阿里云的负载均衡，申请成功后，会再给分配一个公网IP，当前是免费的。然后我们把域名解析到这个IP上之后，当用户发生访问时，阿里云会自动帮我们分配到不同的主机上。而且经过我的测试，还发现，当组合成一个负载均衡之后，即便其中一台主机处于没有服务的状态，带宽居然有一个叠加的功效，原本1台带宽是5Mbps，那现在通过负载均衡分配的IP访问，速度会增加到10Mbps。

呵呵，看到这里应该有些兴奋吧，毕竟如果单独购买阿里云带宽的话，费用还是蛮高的，多增加5M带宽费用在900元左右一个月。那个时候，我都已经觉得自己是一个幸运儿了。不单单带宽增加了，还能白白多出一台主机，这是多美的事呀。可哪知道，阿里云现在的负载均衡对我个人来说还是有些致命的缺陷。

通过阿里云的负载均衡进来的IP，到达我们自己购买的阿里云主机时，请求的IP将自动转化成阿里云的内网IP，那这样子的话，防火墙将等价于失效，不论是正常连接还是捣蛋者的IP都将可以伪装成阿里云的内部IP。这个时候，你想限制单个IP的连接数，想禁止一些不正常的连接，HOHO，那就是做梦。还有现在还有不少人运行论坛的，本来还筹划着针对一个IP一天只能注册一个用户。那如果都变成了阿里云的内网IP后，我看你还要怎么设置。

当时我差点要蒙了，毕竟我已经下单了，新的一台阿里云已经入手了，不买，不测试，鬼知道会有这样一个问题呢（这也是我第一次同时把玩两台主机，而且想着让其协调工作）。幸好黄太不负有心人，早前就听说负载均衡有各种形式，既然这种形式走不通，就试图走下其他途径，例如DNS负载均衡，当然最终我用得也就是这种形式，这里要大大的感激dnspod一回，如果没有DNSPOD的话，另外一台阿里云很可能就砸在我手里了。这里省略N字，不详细说如何让两台电脑协调了。

总体来说，阿里云还是很给力的，DNSPOD也相当给力，哈哈。

PS：我发现现如今有太多的人再玩暴破了，这SSH端口号不改，心里还真是难受，今天就收到了好几份由于测试我的SSH导致的IP被系统自动禁止的邮件，最后一索性，还是把端口号给改了。然后通过增加.ssh/config文件，实现了在使用ssh命令时还是如同“没有修改”一样的便利，这样，估计会安静不少了。LINUX真的挺好玩的，特别是多台之间的协作，就更加好玩了。