WebShell检测-ArcSight实战系列之七

释放双眼,带上耳机,听听看~!

引言


#新书预告#由君哥和另外两位甲方金融企业工作的朋友,基于各自十余年甲方企业安全建设实践,致力于解决企业安全建设最后一公里问题,合著了
《企业信息安全建设:金融行业安全架构与技术实战》一书,由机械工业出版社出版,将于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 安全汇报

 

第二部分 安全技术实战

 

11章 互联网应用安全

12章 内网安全

13章 数据安全

14章 移动应用安全

15章 业务安全

16章 安全检测

17章 安全运营

18章 SOC安全总控中心

19章 资产管理和矩阵式监控

20章 邮件安全

21章 活动目录安全

22章 应急响应

23章 安全热点解决方案

24章 安全趋势和安全从业者的未来 

25章 附录

25.1 企业安全建设技能树

写书不易,希望大家能多多鼓励和支持。

———————————————-

企业安全建设,离不开“守望相助”。金融业企业安全建设微信群,在历次安全事件、安全应急中有大量实况直播,处置措施及时性、有效性,让我自己也获益良多。有兴趣加入的企业安全负责人,请关注微信公众号“君哥的体历”,后台留言,微信号+公司名称,验证身份后入群。


附注:

  • 聂君,信息安全从业人员,十余年金融行业信息安全从业经历,默默无闻。好读书,不求甚解。性格开朗,爱好足球。

  • 本订阅号文章是个人对工作生活的一些体验和经历分享,站在不同角度和立场解读会有偏差,见仁见智,不求正确统一,但求真、善、美。


长按识别二维码,和我交流


本文源自微信公众号:君哥的体历

人已赞赏
安全工具

送书活动-《安全村文集(第一辑)》

2019-10-16 13:53:00

安全工具

《管理学原理》自学笔记

2019-10-16 13:53:06

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索