大数据安全分析:我们从日志中得到的(一)

2014-02-13 +9 619143人围观 ,发现 22 个不明物体 WEB安全网络安全

文章中涉及的代码都会开源,欢迎大家一起加入。

简介

在一个嘈杂的环境中,怎样才能尽可能的发现异常?不外乎黑白名单。
黑名单,又可以总结出两种方式:

1.基于特征的检测,2.基于行为的检测

基于特征,是一种立竿见影的手段,对于一般的攻击很有效,但是永远不可能做到百分百,并且实效性极强,需要强大的响应队伍,对新漏洞尽可能快地做成特征库。
基于行为,是一种较为复杂的方式,是通过数学统计的方式来寻找异常,通过模式学习来寻找异常,但缺点是准确度不确定,可以做到很高,但误报率也很高。

为了能够防范未知漏洞和实时性的要求,同时能够灵活变通,我开始建立以hadoop,mongodb,python为基础的大数据分析平台,用来从公司的流量以及web日志中进行数据挖掘。

在进行了一段时间的思考和调研后,初步确定了下面的架构:

采集部分:

IIS-》flume-》hdfs
snort-》flume-》hdfs

无标题

统计分析模块:

M/R python 分析程序-》hdfs

白名单模块:

M/R python 过滤-》 hdfs

规则分析模块:

M/R python 规则-》mongodb

可视化模块:

php jquery -》监控平台

其他联动模块:
ips
扫描器
防火墙

无标题

无标题

通过这个架构,可以让我对整个公司web应用的访问情况,服务器的负载情况,攻击情况,异常访问进行直观的展示。
同时为整个互联网区域提供基础的分析平台。

Flume采集部分

由于公司使用的是IIS,所以在采集的时候遇到了一些困难:

1.Flume在linux下工作良好,但是在windows下用的人相对较少,版本也不够新; 
2.IIS日志格式较为复杂,一个日志目录下,多个子站点的文件夹,每个文件夹的名字是随机的,并且设置了日志切分,文件会不断刷新,而flume的日志采集是基于tail的; 
3.windows下的tail(gnu32)工作不稳定,出现各种崩溃错误。
为了解决这些问题,需要对flume进行一些配置和编写自己的程序。 
  1)使用静态编译的flume1.31-bin版本,测试过后发现没问题。 
  2)编写了pathtail.py,编译成exe来代替tail.exe,兼顾目录监控,同时整合所有的web日志成一个flume进程输出,还可以跟踪最新的日志文件。。 
  3)将flume打包注册成service,方便管理。 
4.扩展pathtail.py,编写监控模块,用来监控实时的访问流量和负载。

针对某个业务系统的IIS服务器,总共使用12个Agent,1到2个汇聚服务器,1个Sink连接。每天的日志量为,15G(单台)*12 = 180G 一年为180*365 = 65.7 TB,按照HADOOP的冗余架构,整体数据量为65.7*3 = 197.1TB。压缩后的IIS一天IIS日志约为400M,12台为4.8G,一年为1752G,冗余后为5.256T。

为了实现IIS日志的准实时性分析,需要计算每分钟负载,设定每天高峰交易时间为早上8点至晚上9点,共13个小时,计算得到每5分钟负载约为:180G/24*13/60*5  约为10G。

根据目前在实验环境进行的测试得结果:

计算节点数量 计算量 消耗时间 结果统计 总耗时
3 73.5G 约15分钟 约30秒 约16分钟

推测计算时间为:

计算节点数量 计算量 消耗时间 结果统计 总耗时
3 10G 约3分钟 约10秒 约4分钟

勉强能够完成任务。

因此为了保证实时性,计划部署的初期HADOOP集群为:

计算节点数量 计算量 消耗时间 结果统计 总耗时
6 10G 约3分钟 约10秒 约4分钟

代码在这里 http://linxinsnow.me/?p=108
flume 配置 http://linxinsnow.me/?p=119

IIS日志分析

根据flume的配置,我们将IIS的日志进行一分钟切割,按照每分钟一个文件夹,每个文件夹按照10秒钟/128M文件进行切割,然后通过M/R框架,对文件夹的日志进行1初步统计分析。这里的统计内容为日志内字段的关联结果。
IIS的日志字段,根据配置的不同,可以多达22个字段,分别是:

date:发出请求时候的日期。time:发出请求时候的时间。
注意:默认情况下这个时间是格林威治时间,比我们的北京时间晚8个小时,下面有说明。
c-ip:客户端IP地址。
cs-username:用户名,访问服务器的已经过验证用户的名称,匿名用户用连接符-表示。
s-sitename:服务名,记录当记录事件运行于客户端上的Internet服务的名称和实例的编号。
s-computername:服务器的名称。
s-ip:服务器的IP地址。
s-port:为服务配置的服务器端口号。
cs-method:请求中使用的HTTP方法,GET/POST。
cs-uri-stem:URI资源,记录做为操作目标的统一资源标识符(URI),即访问的页面文件。
cs-uri-query:URI查询,记录客户尝试执行的查询,只有动态页面需要URI查询,如果有则记录,没有则以连接符-表示。即访问网址的附带参数。
sc-status:协议状态,记录HTTP状态代码,200表示成功,403表示没有权限,404表示找不到该页面,具体说明在下面。
sc-substatus:协议子状态,记录HTTP子状态代码。
sc-win32-status:Win32状态,记录Windows状态代码。
sc-bytes:服务器发送的字节数。
cs-bytes:服务器接受的字节数。
time-taken:记录操作所花费的时间,单位是毫秒。
cs-version:记录客户端使用的协议版本,HTTP或者FTP。
cs-host:记录主机头名称,没有的话以连接符-表示。注意:为网站配置的主机名可能会以不同的方式出现在日志文件中,原因是HTTP.sys使用Punycode编码格式来记录主机名。
cs(User-Agent):用户代理,客户端浏览器、操作系统等情况。
cs(Cookie):记录发送或者接受的Cookies内容,没有的话则以连接符-表示。
cs(Referer):引用站点,即访问来源。

这些字段就是我们寻找用户行为和攻击行为的切入点。
一个简单的例子:
从IIS字段中,我们选取几个要素IP,返回码,访问URL,即

c-ip,sc-status,cs-uri-stem

如果对这三个字段进行分别统计分析,我们可能可以得到一定时间范围内,服务器的访问情况,URL请求情况,返回码情况,是无法检测出一定异常的,因此我会对这三个字段进行关联分析,如:
1.每个IP在访问服务器的时候,他的状态码比例是如何的,如果是相同的业务访问,状态码的比例波动应该变化不大
2.对于一个IP,访问的URL应该是离散的,而不是聚合(收束)的,就是说,如果出现一个IP访问特定的几个URL的频率很高,那么很有可能这个就是个采集器,或者正在进行漏洞的验证。
3.对于特定的URL,其相关请求,如URL之间的关联关系,应该是类似的,因为所有页面请求基本有一样,同理同样的URL请求,它的状态码应该也是一样的,不应该出现较大波动,比如访问index.aspx,那肯定会访问index.css,如果没有,那可能就是自动化提交的工具。
4.URL的rank值在很大程度上也是有规律的,即IP用户的入口点是有规律的,在总结了所有的高可能性入口点后,如果出现某个IP突然访问一个新的入口点,那么这个IP可能是被XSS或者CSRF或者是webshell。

无标题

我们对IIS日志的所有22个字段都进行了这样的单独分析和关联分析,通过1维,二维,三维,多维的关联,进行统计分析,得出异常行为和用户的访问模式,变成插件的形式加载入M/R框架进行分析。
代码例子 http://linxinsnow.me/?p=98

项目还在进行中,后续会不断更新进展..

这些评论亮了

  • anlfi (5级) 回复
    大数据预测?分析?xxx算法 信息层 离散型数学
    那你还是说说哪个股票赚钱吧
    金融大数据那么多 结果貌似都不怎么准啊呵呵
    仅仅分析出一个意向就大动干戈这
    本身就是不安全的行为所挖的坑
    "在一个嘈杂的环境中,怎样才能尽可能的发现异常?不外乎黑白名单。"
    这让我想到 一个编程复合的数学问题 那就是计划在多达1000人的吵杂宴会里监听并识别一个人或者几个人的对话并区从混合的音频里分开了
    最后直到现在也未解决 并设计了很多很多算法 多线 标识 离散 但1000人的场所仅可以捕捉字言片语
    每增加1000人的场所难度几何倍数增加
    最后的结果以结论是我们可以无限接近于答案 但已知答案永不等于现实
    而你又总只能追随已发生的事不断的去分析不断的去付出不必要的代价
    有点像图灵理论 看着对方说的那么厉害那么多 最终实际上事实也就只能一笑而过
    M/R框架 Hadoop 说的应该是阿里他们的云日志分析吧
    还是那句话 程序写的好 要饭要到老
    )29( 亮了
  • @anlfi 
    朋友你好,我想对你的评论进行三点评价
    1.“金融大数据那么多 结果貌似都不怎么准啊” 我能看出朋友你对“准”的要求肯定是很高很高的,但你也需要承认基于数据的分析、预测甚至推荐在很多领域(包括金融业)做出了很卓越的贡献不是吗?不准没关系,因为影响因素太多太多以至于目前很难全部考虑其中,而且很多人也在努力让结果越来越“准”,对吧。同时,分析的结果它只是个意向。既然是意向,就是来辅助决策的,辅助。说回本文的安全,能依靠数据分析出有恶意的访问者有什么问题吗?一种方式而已。“仅仅分析出一个意向就大动干戈”,我怎么觉得朋友你在这方面遇到过很大的问题会这么说呢?没人说要“大动干戈”啊,不是说分析到了一个访客的恶意行为(当然也可能是误报)马上就报警吧?我非常同意朋友你把“预测”这事儿说成是不安全的行为,同时我也觉得做这事儿的人也会有同样的想法并且会做出相对“安全”的思考的,是吧。
    2.我没看懂你那个联想到的数学问题和本文有啥关系。为什么你要用它来表达这些都是“不必要的代价”呢?研究混音的分离付出的代价都是不必要的吗?大数据也是不必要的吗?这个话题挺大的..
    3.“程序写的好 要饭要到老”这话吧,我看着就想“呵呵”。我还没尝到当个程序员的苦,我没资格说太多。我只是觉得,失败与成功并存,努力总是没错的:)
    )23( 亮了
  • pigdefeet 回复
    @anlfi  五楼的评论挺好,但你所设想的结果跟安全管理人员预计的结果有差异,你想得到一个具体的结果。
    对于安全管理人员来说,只需要一个趋势、预警即可,因为实在不敢奢求具体的结论。
    类似于辅助决策系统,至少对你发现安全威胁,是一个帮助。当然,绝不能只依赖于这个系统。
    安全本来做的就是不安全的事儿,做安全的人是最不安全的。
    )8( 亮了
发表评论

已有 21 条评论

取消
Loading...
css.php