访问一下看看结果：

可以看到ls命令成功的执行了，也就是说我们的正常文件是不会被拦截的，而只有upload目录中的文件会被拦截，这样做又会引发另一个弊端，倘若攻击者通过某种方法将shell写入正常的文件中，或是与业务结合起来，那么这种防御手段就很难生效了。具体如何防御还要结合其他的特征进行检测，并不是没有办法了，实际应用中不能只依靠检测文件路径这一条规则，需要结合业务进行部署防御方案。

另一种方法与这个hook三个OPCODE的方法类似，无非就是麻烦一点，感兴趣的同学可以围观下面的参考文献：http://security.tencent.com/index.php/blog/msg/19 ，这里描述了hook函数的比较详细的思路。

0x04 不谈业务的安全都是耍流氓

总结一下，拦截的方法大概就是上面两种，但是拦截的依据还没有决定，如何判断一个调用system()的脚本是否为webshell呢？如果我们的WAF放到生产环境，啥都不管乱杀，很有可能造成正常的业务无法工作。我自己总结了几个方法，可能联合起来使用效果更好一些。

根据目录判断 通常情况下，上传的文件一般都有专门的目录进行存放，例如upload/等，正常的业务文件是不在这其中的，于是我们可以简单的只对这个目录进行处理，其他目录的文件一律放行。

根据文件权限判断 这需要网站的维护者对网站的权限进行严格的控制，例如，所有的web文件均是644，且为root:root所有。上传的文件为www:www所有，根据权限的不同进行查杀，对于默认的web文件进行放行，对属于非root:root的文件进行查杀。也可以根据w标志判断，通过未知方式getshell的文件很多是带有w标志的，所以可以根据这些特征进行查杀。

变形检测 如果发现一个文件调用了assert、system、preg_replace /e等等，但是在源文件中没有发现这些关键字，还等什么，这个文件很大的可能就是shell了。(zend_get_executed_filename可以获得文件的标志以及文件的路径，例如出现了assert，说明该脚本使用了assert执行代码。)

黑名单检测 就像传统的杀软一样，总会有那么一部分的特征病毒库，我们也可以建立一部分的webshell特征库，先依靠特征库杀掉一部分，再根据其他的情况进行判断。如果将动态检测和静态检测结合起来，查杀、拦截效果应当都会有显著的改善。

0x05 所以这WAF有啥用

安全需要和业务结合起来进行，不谈业务的安全都是耍流氓。因为是扩展级别的WAF，在部署的时候可能需要重新编译，修改配置文件等等。批量式部署可能显得不是那么方便，而且要根据业务需要进行各种细微的调整。如果仅仅是几台服务器，相信这种WAF还是十分棒的，调整起来也十分方便。

如果能开发出适合批量部署的基于扩展的WAF，那么可能会比较容易普及，毕竟在业务上部署WAF不是一个简单的事情。

参考资料：

http://security.tencent.com/index.php/blog/msg/57 http://security.tencent.com/index.php/blog/msg/19 http://www.walu.cc/phpbook/ http://www.php-internals.com/book/?p=index http://www.nowamagic.net/librarys/veda/detail/1543