webshell检测⽅法归纳
背景
webshell就是以asp、php、jsp或者cgi等⽹页⽂件形式存在的⼀种命令执⾏环境，也可以将其称做为⼀种⽹页后门。⿊客在⼊侵了⼀个⽹站后，通常会将asp或php后门⽂件与⽹站服务器WEB⽬录下正常的⽹页⽂件混在⼀起，然后就可以使⽤浏览器来访问asp或者php后门，得到⼀个命令执⾏环境，以达到控制⽹站服务器的⽬的。
webshell检测模型
Webshell的运⾏流程：hacker -> HTTP Protocol -> Web Server -> CGI。简单来看就是这样⼀个顺序：⿊客通过浏览器以HTTP协议访问Web Server上的⼀个CGI⽂件。棘⼿的是，webshell就是⼀个合法的TCP连接，在TCP/IP的应⽤层之下没有任何特征（当然不是绝对的），只有在应⽤层进⾏检测。⿊客⼊侵服务器，使⽤webshell，不管是传⽂件还是改⽂件，必然有⼀个⽂件会包含webshell代码，很容易想到从⽂件代码⼊⼿，这是静态特征检测；webshell运⾏后，B/S数据通过HTTP交互，HTTP请求/响应中可以找到蛛丝马迹，这是动态特征检测。
静态检测
海参的保存方法青岛沙滩
静态检测通过匹配特征码，特征值，危险函数函数来查找webshell的⽅法，只能查找已知的webshell，并且误报率漏报率会⽐较⾼，但是如果规则完善，可以减低误报率，但是漏报率必定会有所提⾼。优点是快速⽅便，对已知的webshell查找准确率⾼，部署⽅便，⼀个脚本就能搞定。缺点漏报率、误报率⾼，⽆法查找0day型webshell，⽽且容易被绕过。对于单站点的⽹站，⽤静态检测还是有很⼤好处，配合⼈⼯，能快速定位webshell，但是如果是⼀个成千上万站点的⼤型企业呢，这个时候再⼈⾁那⼯作量可就⼤了。所以⽤这样⼀种思路：强弱特征。即把特征码分为强弱两种特征，强特征命中则必是webshell；弱特征由⼈⼯去判断。加⼊⼀种强特征，即把流⾏webshell⽤到的特征作为强特征重点监控，⼀旦出现这样的特征即可确认为webshell⽴即进⾏响应。要解决误报和漏报，就不能拘泥于代码级别了。可以换个⾓度考虑问题：⽂件系统。我们可以结合⽂件的属性来判断，⽐如apache是noboy启动的，webshell的属主必然也是nobody，如果我的Web⽬录⽆缘⽆故多了个nobody属主的⽂件，这⾥就有问题了。最理想的办法是需要制度和流程来建设⼀个web⽬录唯⼀发布⼊⼝，控制住这个⼊⼝，⾮法进来的Web⽂件⾃然可以发现。
动态检测
webshell传到服务器了，⿊客总要去执⾏它吧，webshell执⾏时刻表现出来的特征，我们称为动态特征。先前我们说到过webshell通信是HTTP协议。只要我们把webshell特有的HTTP请求/响应做成特征库，加到IDS⾥⾯去检测所有的HTTP请求就好了。webshell起来如果执⾏系统命令的话，会有进程。
Linux下就是nobody⽤户起了bash，Win下就是IIS Ur启动cmd，这些都是动态特征。再者如果⿊客反向连接的话，那很更容易检测了，Agent和IDS都可以抓现⾏。Webshell总有⼀个HTTP请求，如果我在⽹络层监控HTTP，并且检测到有⼈访问了⼀个从没反问过得⽂件，⽽且返回了200，则很容易定位到webshell，这便是http异常模型检测，就和检测⽂件变化⼀样，如果⾮管理员新增⽂件，则说明被⼈⼊侵了。缺点也很明显，⿊客只要利⽤原⽂件就很轻易绕过了，并且部署代价⾼，⽹站时常更新的话规则也要不断添加。还有⼀个思路利⽤函数劫持。回忆⼀下，我们调试⽹马的时候，怎么还原它各种稀奇古怪的加密算法呢，简单，把eval改成alert就好了。类似的，所以我们可以在CGI全局重载⼀些函数（⽐如ASP.Net的global.asax⽂件），当有webshell调⽤的时候就可以发现异常。已js为例（php，asp等语⾔思路⼀样的，都是保存原函数，然后从新定义原函数，最后在调⽤保存的原函数），⽐如下⾯就是把eval重载，还可以弹出个危险提⽰等，吓退⼀些没经验⿊客。
<script type="text/javascript">
<!--
var _eval = eval;
eval = function(s) {
if (confirm("eval被调⽤\n\n调⽤函数\n" + eval.caller + "\n\n调⽤参数\n" + s)) {
_eval(s);
}
⽇志检测
许飞使⽤Webshell⼀般不会在系统⽇志中留下记录，但是会在⽹站的web⽇志中留下Webshell页⾯的访问数据和数据提交记录。⽇志分析检测技术通过⼤量的⽇志⽂件建⽴请求模型从⽽检测出异常⽂件，称之为：HTTP异常请求模型检测。例如：⼀个平时是GET的请求突然有了POST请求并且返回代码为200、某个页⾯的访问者IP、访问时间具有规律性等。
webshell的访问特征(主要特征)
1. 少量ip对其发起访问
2. 总的访问次数少
3. 该页⾯属于孤⽴页⾯
当然不是所有的孤⽴页⾯都是webshell，以下情况也会造成孤⽴页⾯
（1）隐藏管理后台等正常孤⽴页⾯的访问
抉择作文
（2）扫描器⾏为，常见漏洞扫描，PoC扫描，Webshell扫描（⽇志中经常可以看到常见webshell路径加⼀句话payload的扫描）——这是最主要的⼲扰数据，需要剔除
对于情况（1）采⽤⽩名单的⽅式，对于情况（2）扫描器识别
（p.s. 爬⾍技术、指纹识别技术、扫描器识别（⼴义的可衍⽣到⼈机识别）可以称为web安全技术的三驾马车，总也绕不过去）
优点：采⽤了⼀定数据分析的⽅式，⽹站的访问量达到⼀定量级时这种检测⽅法的结果具有较⼤参考价值。
缺点：存在⼀定误报，对于⼤量的访问⽇志，检测⼯具的处理能⼒和效率会⽐较低。
语法检测
语法语义分析形式，是根据php语⾔扫描编译的实现⽅式，进⾏剥离代码、注释，分析变量、函数、字符串、语⾔结构的分析⽅式，来实现关键危险函数的捕捉⽅式。这样可以完美解决漏报的情况。但误报上，仍存在问题。
连杆轴承
public function startLexing($code)裂冰
{
if (preg_match('/<\?(php)?\s*@Zend;[\r\n|\n]+\d+;/', $code)) {
$this->errMsg = 'Encrypt with Zend optimizer.';
return fal;
}
$this->retErrors();
$this->tokens = token_get_all($code);
$this->code = $code;
$this->pos = -1;
$this->line = 1;
return$this->checkError();
}
误报问题所在，⼀是被检测⽂件是否为合法php语法⽂件，token_get_all函数的实现，是不验证是否问合法php语法⽂件的，只是对其进⾏扫描，分析。服务器云判断是⼀种根据恶意代码串的指纹，根据⼤量后门数据，做语法、语义分析，做业务逻辑分析，理解这段代码的⽤途，给出其是否为恶意代码的定位，⽽其他使⽤者，直接可以得到该代码⽚段是否为恶意代码的结果反馈。Pecker Scanner⾸先是基于语法分析，剥离token、注释、字符串、变量、语⾔结构，再进⾏php语法检测，提取恶意代码的扫描⼯具，来解决漏报问题。同时⽀持服务器云判断，尽量避免误报问题。基于语法的检测⼯具
统计学检测
NeoPi使⽤以下五种检测⽅法：
1. 信息熵(Entropy)：通过使⽤ASCII码表来衡量⽂件的不确定性;
2. 最长单词(LongestWord)：最长的字符串也许潜在的被编码或被混淆;
3. 重合指数(Indexof Coincidence)：低重合指数预⽰⽂件代码潜在的被加密或被混效过;
猪八戒戴花歇后语
4. 特征(Signature)：在⽂件中搜索已知的恶意代码字符串⽚段;
5. 压缩(Compression)：对⽐⽂件的压缩⽐
戒烟怎么戒采⽤这种也存在明显的弱点，NeoPi的检测重⼼在于识别混淆代码，它常常在识别模糊代码或者混淆编排的⽊马⽅⾯表现良好。未经模糊处理的代码对于NeoPi的检测机制较为透明。如果代码整合于系统中的其它脚本之上，这种“正常”的⽂件极可能⽆法被NeoPi识别出来。
变形、窃密型webshell检测
变形webshell可以由上⾯所说的统计学NeoPI⼯具检测，也可以动态检测。⽐如，⼀个正常的程序员如果使⽤eval、system是不会刻意的转换隐藏的，如果发现某个函数执⾏了，代码中却找不到这个函数名，我们认为这是⼀个异常⾏为。所以变形加密也可以⽤这种⽅式查找，在⽇志中找到某个⽂件执⾏system等命令，但在原⽂件中没找到这个⽂件代码，说明⽂件是后门⽂件。
针对窃密型Webshell必须具有操作数据库的能⼒，可以引申出⼀种新的检测⽅法，通过分析正常WEB脚本⽂件和窃密型Webshell对数据库操作的差异进⾏分析是本检测⽅法所重点研究的⽅向。正常情况下WEB站点进⾏数据操作的过程应该是重复性且较为复杂的查询过程，这种查询通常精确度⾮常⾼，查询过程不会出现类似于“lect * from”这种查询语句。正常的WEB脚本在进⾏数据库操作的过程中也不会出现跨越数据库查询的情况，⼀旦出现这种现象基本可以判断为⾮正常的WEB脚本操作过程。
就以上思路设计如下的检测⽅案：
审计数据操作记录。通过审计数据库操作记录可以单独的为每⼀个WEB站点甚⾄WEB站点中的每⼀个脚步⽂件建⽴查询请求模型，通过⼏天甚⾄数⽉的⾃我学习过程来学习并维护⼀份查询请求数据库。该数据库的内容包含了每次查询操作的详细信息、请求归类和分析结果。并且建⽴动态查询请求规则，Agent⼀旦检测到违反该规则的查询请求后会向Server端传递相关信息，Server端再结合其它的扫描过程综合判断发起请求的⽂件是否为Webshell，并最终决定是否向管理员报警。
总结
没有最好的检测⽅法，应该根据实际情况和公司业务合理应⽤。
