专栏名称: 君哥的体历
闲暇时间,逼迫自己,记录分享体验与经历,不求正确统一,但求真、善、美。
目录
相关文章推荐
数据何规  ·  CAC举办欧企数据跨境座谈会 ·  昨天  
数据何规  ·  爱尔兰TikTok数据跨境调查结果要出了! ·  2 天前  
数据何规  ·  爱尔兰TikTok数据跨境调查结果要出了! ·  2 天前  
电子商务研究中心  ·  Temu韩国放大招 亚马逊涉嫌逃税遭调查 ... ·  3 天前  
51好读  ›  专栏  ›  君哥的体历

WebShell检测-ArcSight实战系列之七

君哥的体历  · 公众号  ·  · 2018-07-08 21:48

正文


引言


#新书预告#由君哥和另外两位甲方金融企业工作的朋友,基于各自十余年甲方企业安全建设实践,致力于解决企业安全建设最后一公里问题,合著了 《企业信息安全建设:金融行业安全架构与技术实战》 一书,由机械工业出版社出版,将于2018年底面市发售,希望能给企业安全建设的朋友日常工作和实践中一些启发和帮助(文末有本书目录首发)。


本书是三位甲方人员在平常繁重的工作之余,将从业十余年的一些体验和经历分享出来, 体系化的将如何在企业做安全建设的思路和实践开源,特别是已经经过实战检验的一线安全建设方案和实践,尤为难得,敬请期待。



1. 概述


检测WebShell的行为一直是Web攻防的重要课题之一,以下介绍使用ArcSight基于Web访问日志来检测WebShell的一种思路及具体实现方法。


兜哥在freebuf上有篇文章《企业安全建设之搭建开源SIEM平台(下)》,其中提到满足WebShell特征:


  1. 入度出度均为0

  2. 入度出度均为1且自己指向自己


简而言之我们的理解就是:


  1. Web的请求日志里会有请求的URL信息Request URL信息;

  2. 某些Web的请求日志里会有Referer URL信息;

  3. 正常的网站URL会被其它URL请求,同时该URL也会作为Referer引用其它的URL;

  4. 大多数的WebShell的注入点应该是黑客搞出来的,正常的访问应该不会访问该URL,而该URL被引用的概率极低,所以某个URL一直没有引用其它URL或从来没有被其它URL引用过,或者引用该URL的就是其自己,这两种情况可以视为高度疑似WebShell的URL请求。


当然这种模式不是必然为WebShell行为,但是我们经过靶机的测试,发生WebShell行为的模式的确会被这种逻辑规则发现出来,因此,尽管依旧会有不少误报,但在没有更好的日志分析方法情况下,我们还是按上述思路做了相应的UseCase,并不断优化。


2. Use Case简介


2.1 日志源准备


首先配置各日志源的日志记录配置,日志记录的参数中必须要记录Referer URL的信息。


将所有Web访问日志通过Syslog发送至ArcSight的采集器(Connector)进行规范化处理,为方便后续处理,我们在采集器这层就将URL做了预处理,将URL的参数部分去掉,对于请求的文件名称模式、后缀单独拆解放置在不同的字段中。


URL预处理分别针对Request URL和Referer URL进行。


(1)P1流程


(2)P2流程


2.2 规则定制


2.2.1 Request URL引用过Referer URL的计算


通过Lightweight类型的规则对于某个Request URL是否有Referer URL的情况进行统计累加,如果有引用过其它URL的情况,相关计数数值+1,否则+0,相关逻辑示意图如下:


A1流程


相关的规则定义如下:


其中累加数值的判断由变量来完成:


相关的记录列表配置如下:


2.2.2 Referer URL源自的Referer URL计算


通过Lightweight类型的规则对于某个Referer URL是否源自某个Request URL的情况进行统计累加,如果该URL有被其它URL引用的情况,相关计数数值+1,否则+0,相关逻辑示意图如下:


A2流程



相关的规则定义如下:


其中累加数值的判断由变量来完成:


相关的记录列表配置如下:


2.2.3 基于Request URL引用计算结果的规则

通过Standard类型的规则基于某个Request URL的引用统计次数发送通知信息,由人工进行判断并优化,相关逻辑示意图如下:


B1流程


相关的规则定义如下:


2.2.4 基于Referer URL被引用计算结果的规则


通过Standard类型的规则基于某个Referer URL的被引用统计次数发送通知信息,由人工进行判断并优化,相关逻辑示意图如下:


B2流程


相关的规则定义如下:


2.2.5 总体逻辑处理流程


总体上来说上述的Use Case涉及资源情况如下:


总体上来说上述的相关规则交互关系如下图所示:


通知报警邮件的内容如下所示:


2.3 需要后续改进的问题


  1. 由于生产环境将404的页面都自动跳转到网站主页,因此很多原本返回值为404的请求依旧会显示为200,这样导致很多误报。

  2. Weblogic Httpd没有办法通过配置来记录Referer URL信息,因此很多该服务提供的访问日志无法有效纳入Use Case。

  3. 实际情况下依旧会有某些合法URL就是不会被引用,需要积累数据将其加入白名单。

  4. 报警率还是有点高,但可以看到报警中的信息有不少的确是可疑的,如果能结合主机上的其它审计日志或WebShell的检测工具应该可以大大提高检测精准率。


即使是吹的神乎其神的公安人脸识别抓逃犯其实也类似,并非像报道的那样精准,至少目前还是没法一查即中的,未必完全精确但是个有价值的方法。本文介绍了一种WebShell检测思路实现方法,希望抛砖引玉。


往期文章推荐

ArcSight实战系列:

ArcSight简介            -ArcSight技术系列之一

实施规划和架构设计 -ArcSight实战系列之二

ESM安装配置指南    -ArcSight实战系列之三

Syslog类型Connector安装配置-ArcSight实战系列之四

日志源有效性监控UseCase-ArcSight实战系列之五

ArcSight UseCase常见类型简介-ArcSight实战系列之六


时间有限?看此篇

金融业企业安全建设之路


----------------------------------------------

#新书预告#由君哥和另外两位甲方金融企业工作的朋友,基于各自十余年甲方企业安全建设实践,致力于解决企业安全建设最后一公里问题,合著了 《企业信息安全建设:金融行业安全架构与技术实战》 一书, 由机械工业出版社出版,将 2018年底面市 发售,希望能给企业安全建设的朋友日常工作和实践中一些启发和帮助。目录简介如下:


第一部分:安全架构

1章 企业安全建设简介

2章 安全规划

3章 安全管理

4章 内控合规管理

5章 外包安全管理

6章 安全团队建设

7章 安全培训

8章 安全考核

9章 安全认证

10章 其他

10.1 安全预算

10.2 厂商管理

10.3 安全总结

10.4 安全汇报







请到「今天看啥」查看全文