nginx rewrite 参考资料
nginx rewrite 正则表达式匹配,其中:
~ 为区分大小写匹配
~* 为不区分大小写匹配
!~和!~*分别为区分大小写不匹配及不区分大小写不匹配
文件及目录匹配,其中:
-f和!-f用来判断是否存在文件
-d和!-d用来判断是否存在目录
-e和!-e用来判断是否存在文件或目录
-x和!-x用来判断文件是否可执行
flag标记有:
last 相当于Apache里的[L]标记,表示完成rewrite
break 终止匹配, 不再匹配后面的规则
redirect 返回302临时重定向 地址栏会显示跳转后的地址
permanent 返回301永久重定向 地址栏会显示跳转后的地址
一些可用的全局变量有,可以用做条件判断(待补全)
1 | $args |
多目录转成参数
1 | abc.domian.com/sort/2 => abc.domian.com/index.php?act=sort&name=abc&id=2 |
目录对换
1 | /123456/xxxx -> /xxxx?id=123456 |
例如下面设定nginx在用户使用ie的使用重定向到/nginx-ie目录下:
1 | if ($http_user_agent ~ MSIE) { |
目录自动加“/”
1 | if (-d $request_filename){ |
禁止htaccess
1 | location ~/\.ht { |
禁止多个目录
1 | location ~ ^/(cron|templates)/ { |
禁止以/data开头的文件
可以禁止/data/下多级目录下.log.txt等请求;
1 | location ~ ^/data { |
禁止单个目录
不能禁止.log.txt能请求
1 | location /searchword/cron/ { |
禁止单个文件
1 | location ~ /data/sql/data.sql { |
给favicon.ico和robots.txt设置过期时间;
这里为favicon.ico为99天,robots.txt为7天并不记录404错误日志
1 | location ~(favicon.ico) { |
设定某个文件的过期时间;这里为600秒,并不记录访问日志
1 | location ^~ /html/scripts/loadhead_1.js { |
文件反盗链并设置过期时间
这里的return 412 为自定义的http状态码,默认为403,方便找出正确的盗链的请求
1 | rewrite ^/ http://leech.onexin.com/leech.gif; #显示一张防盗链图片 |
只充许固定ip访问网站,并加上密码
1 | root /opt/htdocs/www; |
将多级目录形式转成一个文件形式,增强seo效果
1 | /job-123-456-789.html 指向/job/123/456/789.html |
将根目录下某个文件夹指向2级目录
如/shanghaijob/ 指向 /area/shanghai/
如果你将last改成permanent,那么浏览器地址栏显是/location/shanghai/
1 | rewrite ^/([0-9a-z]+)job/(.*)$ /area/$1/$2 last; |
上面例子有个问题是访问/shanghai 时将不会匹配
1 | rewrite ^/([0-9a-z]+)job$ /area/$1/ last; |
这样/shanghai 也可以访问了,但页面中的相对链接无法使用,
如./list_1.html真实地址是/area/shanghia/list_1.html会变成/list_1.html,导至无法访问。
那我加上自动跳转也是不行咯
(-d $request_filename)它有个条件是必需为真实目录,而我的rewrite不是的,所以没有效果
1 | if (-d $request_filename){ |
知道原因后就好办了,让我手动跳转吧
1 | rewrite ^/([0-9a-z]+)job$ /$1job/ permanent; |
文件和目录不存在的时重定向:
1 | if (!-e $request_filename) { |
域名跳转
1 | server |
多域名转向
1 | server_name www.onexin.com www.onexin.net; |
三级域名跳转
1 | if ($http_host ~* “^(.*)\.i\.onexin\.com$”) { |
域名镜向
1 | server |
某个子目录作镜向
1 | location ^~ /job { |
关于神奇的收录
看来,半个月还不足以使我的博客死彻底,昨天刚刚抱怨了,我的博客因为停站半月备案,导致百度收录只剩一条,Google PR消失,但是刚才我又查了一下,18号,也就是半个小时前的昨天,在我抱怨后的12个小时里,我的博客被百度新收录了一条,而现在的seo综合查询结果,又和我停站备案前的数据相同了,也就是说,原来的好几百百度收录外加PR值3都恢复回来了。具体是什么情况真的不是很清楚。初步推测是3000多的外链起作用了,该观点有待验证。
另外,我发现了一个免费cdn加速器,不过需要备案号。http://www.webluker.com/
还有,自从给评论加上验证码功能后,世界瞬间就安静啦,o(∩∩)o…哈哈
最后一个事,从这篇开始,要结束文章链接是数字的窘态,练习练习英文。不过这个变动的影响就是,如果不采取措施的话,以前被搜索引擎收录的文章将失效了。。。采取的措施就是使用rewrite了,在nginx的配置文件里加入
rewrite ^/archives/(\d+)\.html /\?p=$1 last;
这次备案的损失
这两天我才发现我这次备案自己的博客,停站半个月的损失是什么。最初以为也就是少了点百度收录而已,但是事实却是,我的百度收录现在仅剩一条了,并且最痛心的是Google的PR值没有了,我的pr值原来为3阿,这是多么不容易积攒起来的阿。。。唉,看来一切又要从头再来了,既然现在是假期了,每天就要坚持发发博文了。希望能尽快回升回去。
WebShell检测思路浅谈
什么是webshell?我相信如果看官能有兴趣看这篇文章,一定对webshell有个了解。不
过不了解也没关系,那就请先搜索下相关资料[1]。当然,本着“know it then hack it”
的原则,建议你还是搭个环境,熟悉下先,毕竟纸上谈兵是要不得的。
随着网络的发展,Web站点的增加,webshell这种脚本后门技术也发展起来了,多少黑
客故事都是从一个小小的webshell开始的。所以对于网站,特别是站点和应用众多的互联网
企业,能够在出现webshell的阶段及时发现和响应就显得尤为重要。
本文以笔者多年从事相关工作的经验来探讨下webshell的检测手段。
记得当年第一个ASP木马出来的时候号称“永不被杀的ASP木马”(请大家虔诚地起立,
我们一起来膜拜一下海洋顶端ASP木马之父LCX大叔),因为它使用正常端口,且脚本容易变
形,使得查杀它变得困难。但是,Webshell这种特殊的Web应用程序也有两个命门:文件和
HTTP请求。
我们先来看下Webshell的运行流程:hacker -> HTTP Protocol -> Web Server -> CGI。
简单来看就是这样一个顺序:黑客通过浏览器以HTTP协议访问Web Server上的一个CGI文件。
棘手的是,webshell就是一个合法的TCP连接,在TCP/IP的应用层之下没有任何特征(当然
不是绝对的),只有在应用层进行检测。
黑客入侵服务器,使用webshell,不管是传文件还是改文件,必然有一个文件会包含
webshell代码,很容易想到从文件代码入手,这是静态特征检测;webshell运行后,B/S数
据通过HTTP交互,HTTP请求/响应中可以找到蛛丝马迹,这是动态特征检测。
静态特征检测是指不执行而通过围观的方式来发现webshell,即先建立一个恶意字符串
特征库,然后通过在各类脚本文件中检查是否匹配。这是一种最简单也是最常见的技术,高
级一些的,可能还涉及到语义分析。笔者06年开发的“雷客图ASP站长安全助手”[2]即是通
过此类办法查找ASP类型的webshell的。
静态特征检测面临的一个问题是误报。因为一些特征字符串正常程序本身也需要用到。
比如PHP里面的eval、system等,ASP里面的FileSystemObject、include等。所以雷客图在
设计之初就是一个辅助工具,最终还需要有相关安全经验的人来判定。
对于少量站点可以用这样人肉去检查,如果是一个成千上万站点的大型企业呢,这个时
候再人肉那工作量可就大了。所以用这样一种思路:强弱特征。即把特征码分为强弱两种特
征,强特征命中则必是webshell;弱特征由人工去判断。加入一种强特征,即把流行webshell
用到的特征作为强特征重点监控,一旦出现这样的特征即可确认为webshell立即进行响应。
比如PHPSpy里面会出现phpspy、wofeiwo、eval($_POST[xxx]) 等,
ASP里面出现Shell.Application等。
当然,黑客完全可以变形躲过,没关系,还有人工检查的弱特征。
另一个问题是漏报。程序的关键是特征字符串,它直接关系着结果,如果你的特征库里
面没有记录的甚至是一种新的webshell代码,就可能束手无策了。雷客图第一版出来后,我
自以为所有的ASP webshell都可以查了,但是我错了,因为不断会有新的方式出来绕过,最
终结果就是特征被动的跟着webshell升级而升级,同时还面临未知的webshell——这个情况
和特征码杀毒软件何其相似。
要解决误报和漏报,就不能拘泥于代码级别了。可以换个角度考虑问题:文件系统。我
们可以结合文件的属性来判断,比如apache是noboy启动的,webshell的属主必然也是nobody,
如果我的Web目录无缘无故多了个nobody的文件,这里就有问题了。最理想的办法是需要制度
和流程来建设一个Web目录唯一发布入口,控制住这个入口,非法进来的Web文件自然可以发
现。
webshell传到服务器了,黑客总要去执行它吧,webshell执行时刻表现出来的特征,我
们称为动态特征。
先前我们说到过webshell通信是HTTP协议。只要我们把webshell特有的HTTP请求/响应
做成特征库,加到IDS里面去检测所有的HTTP请求就好了。
这个方案有个问题就是漏报。首先你得把网上有的webshell都搜集起来抓特征,这是个
体力活,新的webshell出来还要去更新这个库,总是很被动,被动就算了,但是一些不曾公
开的webshell通信就会漏掉。那么这个方案有没有效果,只能说效果有限吧,对付拿来主义
的菜鸟可以,遇到高级一些的黑客就无效了。杀毒软件都搞主动防御了,webshell也不能老
搞特征码是吧。
webshell起来如果执行系统命令的话,会有进程。Linux下就是nobody用户起了bash,
Win下就是IIS User启动cmd,这些都是动态特征,不过需要看黑客是否执行命令(多半会这
样),还有就是你的服务器上要有一个功能强大的Agent。要是黑客高兴,再反连回去,这
下就更好了,一个TCP连接(也可能是UDP),Agent和IDS都可以抓现行。这里还涉及到主机
后门的一些检测策略,以后有机会再另文叙述。
回到网络层来,之前我们探讨过,Webshell总有一个HTTP请求,如果我在网络层监控HTTP
请求(我没有监控Apache/IIS日志),有一天突然出现一个新的PHP文件请求或者一个平时
是GET请求的文件突然有了POST请求,还返回的200,这里就有问题了。这种基于区别于正常
请求的异常模型,姑且称之为HTTP异常请求模型检测。一旦有了这样的模型,除了Webshell,
还可以发现很多问题的。
还有一个思路来自《浅谈javascript函数劫持》[3]和某款代码审计软件。回忆一下,
我们调试网马的时候,怎么还原它各种稀奇古怪的加密算法呢,简单,把eval改成alert就
好了!类似的,所以我们可以在CGI全局重载一些函数(比如ASP.Net的global.asax文件),
当有webshell调用的时候就可以发现异常。例如以下ASP代码就实现了对ASP的execute函数
的重载:
1 | <% |
这个方法在应用层还是有些问题,所以如果在CGI引擎内核里面改可能会好些。根据小
道消息,这期ph4nt0m的webzine会有一篇文章涉及PHP内核中防webshell的,有兴趣的同学
可以关注。
本文只探讨了检测Webshell的一些思路,希望对你有些帮助,如果你有更好的方案,也
可以和我探讨。至于一些工具和特征,由于这样那样的原因就不公开了,我始终认为,相比
于工具,思路永远是最重要的。
文章作者:lake2 - 这个ID不用我解释,某组织的牛淫
运气不错,半个月搞定网站备案~
从2012年1月4日开始准备资料,到1月5号开始提交资料,再到今天1月16号备案号批下来,貌似一路很顺利,就是中间等待的时候,比较让人心急啊。。。。
由于这次备案是闭站备案,所以说这段时间,我的这个网站是一直无法访问的,不过我还是给自己预留了一个通道可以访问到的~
有了备案号就可以去百度申请广告了吼吼
虽然我的这个站的流量实在是可怜,但是我相信,这只是现状。
处理Nginx出现的413 Request Entity Too Large错误
处理Nginx出现的413 Request Entity Too Large错误
这个错误一般在上传文件的时候出现,打开nginx主配置文件nginx.conf,找到http{}段,添加
client_max_body_size 8m;
要是跑php的话这个大小client_max_body_size要和php.ini中的如下值的最大值一致或者稍大,这样就不会因为提交数据大小不一致出现的错误。
post_max_size = 8M upload_max_filesize = 2M
利用php重启apache进程
问题
通过php重启apache可以把apache的控制放到web页面上。
但是由于php本身的运行模式,一般而言,除非apache具备root权限,否则php连/etc都访问不了,更不用说反过来控制apache了。
因此,我们需要找到别的方法。
思路
通过system,exec等方法,PHP可以呼出一些权限之内的命令,或者执行一些可执行的程序。
因此我们可以事先编译一个重启apache的可执行程序,并赋予其root权限,然后让php调用该程序来实现apache的重启动。
具体方法
首先我们建立sample.c文件,并进行编译:
1 | #include <stdio.h> |
编译完该文件之后,我们需要对执行文件的权限进行一下处理
chmod u+s sample
sample是由root建立,root编译,因此原本也只能由root执行调用。
但通过上面这个命令,其他用户也可以调用这个文件了。
然后我们在PHP中调用这个文件就可以重启apache了。
一些关键点的解说
1:
重启Apache的系统命令很多,比起代码中的调用,更有名的应该是/etc/init.d/httpd restart,但是很遗憾,在本应用中这个系统命令是不能调用的,如果使用这个命令,那么Apache会在中止掉自己进程的瞬间,终止这个程序的继续运行,也就无法对自身进行重启动,因此我们需要通过发送信号给Apache,在不中止进程的情况下重启Apache,这一点非常重要。
关于apachectl -k restart的详细信息,可以参照下面的网址
http://man.chinaunix.net/newsoft/Apache2.2_chinese_manual/stopping.html
2: 双重fork。 如果只是重启apache,而不在乎程序本身的动作,那么我们可以直接在代码中执行system(“apachectl -k restart”)而不必产生新的进程。
但是,考虑一下整个流程,如果我们这样做了,那么当我们访问PHP页面的时候,PHP(Apache)调用文件,瞬间重启自身,那么很自然,结果就是页面崩溃。
当然,Apache依然可以重启成功,但是,这一点也不优雅。
因此,使用双重fork可以让我们避免当前页面崩溃而对Apache进行重启动。
3: 更进一步的安全措施:
编译完sample后,计算其MD5值,并把该值固化到PHP中,然后在PHP中加入校验代码,以防止sample被恶意替换。
Linux vps生成100mb.bin文件测试下载速度
大家买了vps之后是不是都迫不及待的想让朋友们帮忙测试下下载速度,很多vps商或者独立服务器都提供100mb.bin 或者1000mb.bin的文件下载,当然这些文件都不是上传上去的,用服务器自动生成即可。
进入你的网站目录,指向命令:
dd if=/dev/zero of=100mb.bin bs=100M count=1
其中的文件大小和数量,你自己决定吧!
生成之后可以直接在浏览器输入文件的网址,测试单线程的下载速度,如果想测试极限速度可以找几家国外的vps或者服务器,下载你的文件试试。
VIM做PHP开发环境
转自:http://blog.163.com/shangshujie_1005/blog/static/186713514201171511835578/
更换了注释插件NER_commenter,函数出错找不到解决办法,于是更换为插件EnhancedCommentify
折腾了四天终于把 vim差不多搞定了 实现了目录,函数跳转,注释和php自动缩进,自动补全。有待日后完后
vimrc代码如下:
1 | " 设置leader为, |
所安装的插件列表如下:
omnicppcomplete-0.41.zip:实现自动补全 Tab键或者ctrl+l
vim-php-manual.tar.gz : php函数文档 K键
supertab.vba: 实现tab键补全
taglist_45.zip: 生成右侧的函数列表
NERD_tree.zip : vim界面左侧目录树
mattn-zencoding-vim-88d8991.zip :生成html
//NERD_commenter.vim 注释代码用的,
EnhancedCommentify 注释插件
php的字典文件
mark.vba.gz 标记
javascript.zip
css.vim
php.vim(PHP-correct-Indenting 最新修订的php缩进vim)
参考http://koch.ro/blog/index.php?/archives/63-VIM-an-a-PHP-IDE.html
参考http://yinqiongjie.blog.163.com/blog/static/5619762008102823227166/
另有人的配置见连接:http://nootn.com/blog/Tool/22(附各种插件)