webshell webshell检测－日志分析 网站安全

一直认为日志分析的最终奥义是取证与预测——讲述完整的已发生、正在发生的、将来会发生的攻击故事。而本文之所以讲如何识别webshell，就是想从确定的攻击事件来回溯已发生的攻击事件,被植入的webshell毫无疑问就属于确定的攻击事件，只要曾经被传入过，就有很高的概率一直被黑webshell检测不是新鲜事，主流有杀毒软件与入侵检测系统两种做法，而这两种方法除了技术上的缺陷外，更多时候，由于无法拿到完整的文件样本，或无法拿到完整的流量信息，而采用成本较低的日志分析方法。本文重点讲webshell检测的日志分析方法，包括模型是如何建立与实现的，最后会简单的提一下传统的检测方法与之对比。一、分析总的思路：先找到异常日志，再找到攻击日志，整个过程分为两个步骤：webshell提取 ＋ webshell确认1、webshell提取根据安全经验，我们可以给出以下假设webshell 的访问特征1）少量的IP对其发起访问2）总的访问次数少3）该页面属于孤立页面注意红色标记的词汇都是抽象的形容词，我们需要将这些特征量化，比如说少量，多少算少量？什么是孤立页面？接下来常见的描述性统计方法上场，我们来统计1）单个URL每天的总访问分布2）单个URL的独立访问IP数目分布3）单个URL的入度、出度分布 下面，小小科普一下有向图的基本概念节点vertices：1，2，3，4，5，6，7，8 相当于访问日志中的url边edge：1->2 1->3 4->1 5->1 6->5 7->7 相当于从A url跳转到B url入度in-degree出度out-degree节点1的入度为2， 出度为2节点2、节点3的入度为1，出度为0节点4、节点6的入度为0，出度为1 ，属于悬挂节点，比较特殊，例如404跳转到首页会产生这样的节点节点5的入度为1，出度为1节点7的入度为1，出度为1，但自己指向自己，属于自回路，大多数有验证的webshell都属于这种节点8的入度为0，出度为0，属于孤立节点而节点7、8就属于webshell访问特征中的该页面属于孤立页面补充20151103：对于出度入度>1的webshell也是存在的，什么是孤立，与其他页面的交互度为多少算孤立，都是相对的。当webshell采用标签列出当前目录下的文件的时候，就会产生与其他页面的交互。当需要多个脚本协同作用的webshell也会产生交互。当然不是所有的孤立页面都是webshell，以下情况也会造成孤立页面隐藏管理后台等正常孤立页面的访问扫描器行为，常见漏洞扫描，PoC扫描，Webshell扫描——这是最主要的干扰数据，需要剔除对于情况采用白名单的方式，对于情况扫描器识别可以称为web安全技术的三驾马车，总也绕不过去）补充20151103：模型运行了1个多月后，发现孤立页面的情况真是五花八门，一些站点放了个“安全”检测工具，“上传压缩密码重置”便捷工具都不带删的。webshell 的path特征除了weshell特有的访问特征，我们也可以用path特征来辅助提取我们来看一批真实的webshell会发现不同手段植入的webshell路径各有特征，例如上传的webshell，如果上传组件有保护措施的会进行文件名重写，并在路径中还有日期特征，这类webshell还极易出现在静态资源目录下。补充20151103：批量写马的时候，特别是利用漏洞进行的批量写马，会用脚本来自动生成文件名，然后放在特定的目录下，对path的相似性分析会发现这个规律。webshell的时间特征将新增的页面视为异常页面，但这种方案的缺陷非常明显会漏掉已存在页面写马的情况会误判正常的站点更新于是将该特征当做辅助特征，用来还原webshell植入的过程，如果接入了例如WAF这种防御产品，还可以探究是不是绕过了防御补充20151103: 文件的时间属性也是可以修改的webshell Payload特征WAF、IDS等基于流量的安全检测防御工具，会把网络通信中的payload特征%26"cute:Ex"%26cHr%26"cute):Response.Write:Response.End"")")"但在日志分析中只能当成辅助特征，有两个原因：a. 日志字段不全的问题，无法使用payloadb. 攻击者很多时候只是在做webshell存活性探测，不会产生攻击特征，或者将会攻击payload进行加密处理来绕过特征检测如下例wso 2.5.1 的payload为a=RC但也不要轻视了这种直观的特征，常规webshell是占较大比例的，并且在webshell特别是只有回显信息无GUI的小马而言，确认上也能起到不容忽视的作用。2、webshell确认想想砖家们们如何确认一个页面是不是webshell的，打开ta，看看页面长啥样，也就是请求回放。在进行请求回放的时候，有两类问题需要考虑回放是否会造成破坏性操作，例如造成站点压力，，还有删除文件、重置账户、系统重装等操作，这也是为啥不直接回放每条访问日志的原因之一回放是否侵犯用户隐私，严格的日志存储规定不能存储cookie，post等会涉及用户敏感数据的字段，或必须做脱敏处理再存储，然后由用户授权再查看，当然不存储的更重要的原因是存储资源的巨大耗费。实例1 webshell登陆口align=center> method=post>Password: type=password name=pass> type=submit value=">>">登陆框非常非常见webshell 攻击关联特征 "如果发现一个站点植入webshell，那远远不只一个站点被植入"“如果发现一个站点被植入一个webshell，那远远不只一个webshell被植入”搜索的优势在这个时候就可以发挥了，用确认webshell的访问者特征利用搜索将数据关联起来，按时间线进行还原，讲述了个有意思的故事。补充20151103：讲到搜索，有两个难点：如何将结果按时间线与行为关联展示基础数据设施建设的如何，比如说使用elasticsearch，保留多久的数据量，索引如何建立，集群的负载均衡等二、实现1. 数据获取数据源：web访问日志获取方式：如果存储在hdfs里，采用distcp的方式拷贝到模型计算集群上p.s. 光数据的获取，就遇到了很多坑，不同版本的hadoop之间的数据传输2.feature提取http_hostroot_domainurlpathquery 查询字符串refereriptimestamphttp_response_codehttp_methodrequest_body 请求体 非必要字段cookie 非必要字段user_agent3.预处理在统计之前我们需要对数据做预处理预处理1:按小时切割日志预处理2: 提取响应码为2xx，3xx的日志预处理3: 特征规范化处理，非常重要，如果不做预处理，将会形成一个超级大的有向图，mapreduce这种批处理会处理不过来Host规范化： 将*.xxx.com或.xxx.com 变成 www.xxx.comPath规范化：归并多个/,替换为/referer规范化：将相对地址还原为绝对地址，e.g. /a.php => www.xxx.com/a.php将host部分非本域、空字段、不符合referer规范的referer字段皆设置为空去除query部分4.模型建立1）webshell提取第一步：建立有向图，提取孤立页面与自回路页面webshell 的访问特征第二步：去除不符合规范的path?[-./\w] ）第三步：去除静态path第四步：去除白名单path 与扫描器行为来去除）第七步：去除响应码非200的path第八步：按path特征定义webshell的可信度，符合特征的标记为1webshell 的path特征第九步：按webshell payload特征定义webshell的可信度，符合特征的标记为1，等同于WAF中的webshell检测规则，如果日志中有WAF检测结果标记字段，可以直接用该字段来标记webshell可信度 webshell Payload特征第十步：去除独立IP访问数与path访问请求总数超过阈值的path2）webshell确认第一步：对webshell 提取的path进行GET回放，若有参数，带参数回放第二步：去除响应码非200的path补充：修改为保留401的请求，避免漏掉通过http basic认证的webshell第三步：去除404重写path方法一：随机生成2个文件名，回放，看response body的大小是否一样，若一样，则存在重写方法二：神奇的fuzz hashing又要发挥作用了，可以对重写的response content求fuzz hashing值，设置相似度阈值，在阈值范围内的判定为404,例下图所示，将安全狗重写页面剔出