2. 武汉华工安鼎信息技术公司, 武汉 432100
传统Web漏扫及防护技术不足以实时评估Web服务器本身所面临的威胁态势, 为此, 针对大型复杂环境下Web服务器的安全威胁态势, 提出了一种基于Web日志的安全威胁分析方法和系统.该系统从海量日志中提取和分析安全威胁事件, 基于威胁行为特征模型, 分析出Web网站曾受到的各类威胁, 并生成站点综合风险指数, 有利于网站针对性加固和加强综合防御能力.
2. Wuhan Huagonganding Information Technology Company, Wuhan 432100, China
With the vigorous development of Chinese Internet industry, Web services are more and more applied to various domains like government, education, finance and telecom to realize services such as e-government affairs, business promotion, online trading. The security threats based on Web services are more than any time before. It is insufficient of the traditional vulnerability scan and defense technology to evaluate the threat trend faced by Web server. Aiming at the analyses on the thread trend of Web server under large-scale complex environment, this paper proposes a method and system based on Web log for security threat analyses. It extracts security threat events from a mass of logs and then makes analyses. With the use of characteristic model of threat behavior, it is able to exactly find all kinds of threats to the Websites. Synthetical comprehensive risk index for this Website is given which could contribute to the Website's aiming at strengthening its integrated defense capability.
随着计算机技术和网络技术的迅猛发展和用户需求的持续增长，运行在Web服务器上的应用系统也日益复杂[1]，同时，Web服务器也面临着严峻的信息安全威胁.为提高Web服务器的安全防护水平，笔者提出了一种基于Web日志的安全分析系统，分析Web网站曾受到的各类威胁.
钱秀槟等[2]提出了基于攻击过程特征和结果表现特征的Web日志分析方式，然而，其未对站点整体作科学合理的态势评估[3].
1 安全风险评估1.1 安全风险分析Web日志分析对网络风险评估具有重要意义.对网络安全态势进行评估的模型众多，其中，基于日志审计与性能修正算法的网络安全态势评估模型，将安全态势的评估指标归纳为3类：日志信息L、性能信息P和服务信息S，建模如下.
1) 日志信息L包含日志信息标识符、日志产生时间、日志信息类型、日志内容、产生日志的节点标识符和日志对应安全事件的目标节点标识符.
2) 性能信息P包含性能信息标识符、性能信息产生时间、节点处理器使用率、节点内存使用率、连接数、流量、丢包率和该性能信息所属节点标识符.
3) 服务信息S包括服务标识符、服务名称、服务权重和服务信息所属节点标识符.
T表示网络安全态势值，由L、P和S组成，表示为T=(L, P, S).模拟显示，采用自回归滑动平均模型(ARMA，auto-regressive and moving average model)时，预测的网络态势误差较小，可靠性好.
由此可见，日志信息在安全态势评估中是前提条件，对日志的分析奠定了网络安全风险评估的基础.
1.2 访问行为分析除了上述风险评估中应用到日志分析，在实际网络环境中对访问行为的日志分析也至关重要.若能提前通过日志分析访问行为，就可以提前发现恶意行为，从而增强网站自身安全性和增强相关设备的防护措施.
大多数服务器会记录服务器处理的所有请求和出错信息. Apache服务器日志文件access. log的格式采用通用日志格式(CLF，common log format)[4].互联网信息服务IIS服务器支持“W3C扩充日志文件格式”[5]，“国家超级计算技术应用中心(美国)(NCSA，national center for supercomputer applications)通用文件格式”和“数据库日志格式(ODBC，open database connectivity)”.可见，由于采集到的日志文件格式存在差异，字符编码也各有不同.在日志数据进行处理之前，需要通过数据预处理模块对日志文件进行格式转换和预处理.
日志文件在经过预处理后，将从中提取用户行为进行分析.攻击行为分析的依据是开放Wweb应用安全项目(OWASP，open web application security project)制定的攻击类型标准.攻击行为分析的实现基于规则库的已知行为检测.通过这种方法，系统可以准确识别基于已知木马、病毒和漏洞的攻击行为.
1.3 风险指数评估对于一个Web站点，通过Web日志分析得到的受攻击结果是比较可信的，但是这些数据只是某时间段的孤立统计，不能代表站点整体的安全状况，也无法用于预测即将的风险.本系统采用站点综合风险指数(SCRI，synthetical comprehensive risk index)来评估站点安全态势.此算法的核心是对网站的风险建立数据模型，将风险加以量化. SCRI定义如下.
1) 攻击数量综合指数(ACCI，the number of attacks composite index)由站点收到的各类攻击次数与总攻击次数比率的算术平均值计算获得，用Ra表示.计算公式为
|
其中：Ai为第i种攻击类型发起的攻击次数，T为站点发送的攻击总次数，N为攻击类型的数量.
2) 攻击威胁综合指数(AVCI，attacks and threats composite index)是Rb∈[0, 1]的标量，代表攻击类型自身的威胁程度.这个评分值来源于OWASP网站的评分方法.考虑各种攻击自身的危害程度、攻击平台的脆弱性等多个因子得出的标量值，用Rb表示.
3) 攻击成功数量综合指数(ASCI，the number of successful attacks composite index)由站点受到的各类攻击成功次数与其攻击的次数的比率的算术平均值计算获得，用Rc表示.计算公式为
|
其中Vi代表第i种攻击类型发起攻击的成功次数.
4) 站点综合风险指数(SCRI，synthetical comprehensive risk index)Rt∈[0, 1]之间的标量，该值越大代表站点安全风险越高，用Rt表示.计算公式为
|
网站的风险主要由站点综合风险指数来表示，而SCRI又可以由ACCI、AVCI、ASCI 3个量化因子计算得出，因此是关键因子.选择这3个因子依据如下3个公理:
1) 攻击的次数越多，站点的危险性越高；
2) 攻击手段自身的危害性、破坏性越大，对站点的威胁越高；
3) 攻击成功的次数占此类攻击的总次数的比率越高，说明攻击的成效越显著，表现为站点的危险越高，表现出站点的防御能力越弱.
2 系统设计2.1 整体架构系统整体采用B/S架构，并采用模型-视图-控制器(MVC，model view controller)模式将存储处理与展示区分，系统架构如图 1所示.由于面对的是海量日志文本数据，数据库使用MongoDB.分析处理层内置规则库和处理引擎，将采集的日志、安全规则等以(JSON，JavaScript object notation)形式存储入MongoDB.由于该系统是日志审计的专门化应用，系统配备了一个轻量级Web服务器以接收从应用展现层传递的get/post请求，并从MongoDB获取数据，采取的数据交换格式也是JSON.
|
图 1 日志审计系统架构 |
选用文本数据交换格式既方便处理，又易于理解. XML/JSON均是常用的基于文本的数据交换格式.但本系统统一采用JSON作为数据交换格式，不采用XML，其原因分析如下：
1) JSON属于文本协议，内容易理解，修改方便；
2) 与XML类同，JSON属于文本标记语言，支持树形结构化内容记录，提供良好的对象数据序列化能力，较XML更轻量级，数据冗余度也低；
3) JSON与级联样式表(CSS，cascading style sheets)文档格式相同，具有传递动态CSS效果的能力，方便后台动态调整客户端显示效果；
4) JSON已经成为异步JavaScript和XML(AJAX，asynchronous JavaScript and XML)应用开发的主流数据格式，方便与外界数据交换.
2.2.2 数据库选择传统的数据分析系统在针对海量日志数据分析上存在以下的性能缺陷.
1) 对海量数据的存储效率低.
2) 数据库事务一致性需求占用大量资源.
反之，日志审计系统并不要求严格的数据库事务.日志审计的特点决定了从数据库获取的数据不能直接进行数据分析，需要将其数据重新组织成一个数据对象后再传递给分析引擎进行数理统计和分析.对于海量数据而言，这样的处理流程在传统结构化查询语言(SQL，structured query language)数据库会造成分析引擎分析性能降低.
基于以上考虑，Web日志审计系统采用MongoDB数据库进行日志数据的存储，基本流程如下：
1) 日志数据经过预处理后形成JSON数据对象存入MongoDB数据库后台；
2) 分析引擎从数据库中读取JSON对象传递给数据分析模块和数理统计模块进行特征匹配和建立基线模型.
这样做的好处在于：采用MongoDB存储与索引海量的文本日志信息，充分发挥了MongoDB对海量数据的高效访问能力.
2.2.3 轻量级Web服务器为增强数据吞吐效率和加强自身安全，系统使用基于libevent定制化的轻量级Web服务器.对于http请求，只处理pos、get 2个http请求命令，丢弃全部其他的http请求.这样的处理流程回避了扫描工具对Web服务器的指纹特征(fingerprint)攻击威胁，增加了Web服务器自身的安全性.
2.2.4 日志行为识别轻量级服务器将post和get请求数据封装成JSON对象返回客户端, 充分利用客户端硬件资源和AJAX、JavaScript来实现动态网页效果，降低服务器处理压力.
日志文件在经过预处理后，会将信息发送日志分析模块，该模块会实现基于规则库的已知行为检测.基于规则库的行为检测采取匹配正则表达式的方法.基于正则表达式，系统可以准确实现已知木马、病毒和漏洞的检测.例如，一个典型的描述操作系统(OS，operating system)命令注入攻击的正则表达式为
uri:/*[.]exe[?]. *(?:dir|mkdir|del|move|copy|net|net1|type|ipconfig|set|rmdir|rd|netstat|netsh)(?!(?:\w|/))*/; pcre
该正则表达式定义了若uri中含有dir等命令则为非法请求.如果一条日志与此正则表达式相匹配，则该日志反映了被检测服务器存在OS命令注入攻击风险，且返回值200表示攻击成功.
通过对常见攻击的分析，系统预定义了多种网络攻击行为.如请求中统一资源定位符(URL，uniform resource locator)参数与超文本传输协议(HTTP，hypertext transfer protocol)头部的注入，变形SQL注入攻击，请求中恶意的XML路径语言(Xpath，XML path language)，服务端语言注入等.基于日志行为分析，可以实现丰富的扩展功能.
3 系统评估3.1 安全事件识别率基于日志的安全审计系统最主要的评测指标为安全事件的误报率和漏报率.误报率为
|
指的是非安全事件Evt_Err在所有识别出的安全事件Evt_All中所占的比重.该比重过大，则表明产生安全事件噪音，放大了安全威胁，对安全态势评估带来干扰.漏报率为
|
指的是在所有发生的安全事件Evt_Total中，未识别出的安全事件Evt_Mis的比重.该比重过大，表明识别规则不充分，导致安全事件遗漏，造成安全威胁较低的假象.
除通过统计分析大量日志样本，保证足够的数据样本以外，系统对规则库也进行了优化.优化的目的有2个：一个是降低安全事件的误报率和漏报率；另一个是提升规则匹配的速度.为了降低安全事件误报率和漏报率，采取的优化方法有依日志重现服务器访问，与其他防护产品比对，如商用入侵检测IDS系统.为了减少规则匹配时间，系统尽量减少规则条数，以“或”的形式将多条正则表达式合并为1个，并在规则库中将规则进行排序，将较为简单的规则前置.如此，在规则匹配时，尽快确定日志里包含的安全事件.
在收集大量日志样本，定义并优化识别各攻击的正则表达式后，本研究比对了规则库优化前后的安全事件识别率和误报率.针对2个已知攻击类型和攻击数的5万条的Apache Web服务器日志样本，采用优化前和优化后的规则库分别进行分析，结果如图 2所示.每种攻击类型的检测结果由两根柱状图显示.左侧柱状图为优化前的检验结果，右侧为优化后的检验结果.实际安全事件的数量由灰色表示，检验出的正确的安全事件数量由白色表示，白色柱高低于灰色柱高.对误报的安全事件以黑色向下的柱状表示.检验结果表明，对于代表性的安全事件，在优化后，安全事件的识别率和误报率均有好转.其中，SQL注入、代码(coding)注入、可疑文件上传的误报率显著降低；目录遍历、管理后台访问的漏报率明显降低.实验结果表明，系统的识别率和误报率能较真实地反映服务器所受攻击情况.
|
图 2 安全事件识别率及误报率优化前后对比 |
在规则库优化后，将样本交由某商用入侵检测系统(IDS，intrusion detection systems)进行检测，并与我们的Web日志安全分析结果作比对，其结果如图 3所示，左侧柱状图为IDS检测结果，右侧为日志安全分析结果.结果表明，在各攻击类型的识别率和误报率上，均接近IDS检测设备，可达到商用条件.且在高流量的网络环境下，IDS的漏报率会增多，Web日志安全分析的优势会更加明显.
|
图 3 日志分析与IDS检测结果比对 |
由于大型网站，特别是门户网站日志文件通常非常庞大，所以高效迅速的日志分析是成熟应用的必要条件.除3.1节介绍的提升正则表达式匹配速度的方式外，系统实现中还最大限度采取多线程技术，对日志文件进行分片并行处理，并与中央处理器(CPU，central processing unit)核数绑定，加快日志分析速度.
表 1显示了分析性能优化前后的实验结果.实验对不同尺寸的日志进行分析，硬件及软件环境为：CPUi3, 内存4 G, 硬盘500 G, ubuntu 64 1004 server.结果表明，优化后的分析速度有明显改善.
|
表 1 日志分析性能优化前后对比 |
为确定日志中攻击事件对日志分析时间的影响，本研究采用了6份尺寸为110 MB左右，但攻击事件占比不同的人造日志样本，通过测试分析时间进行评判，测试结果如图 4所示.测试结果表明，随着攻击事件的占比增加，日志分析时间呈线性增加，此趋势符合日志分析的流程设计.
|
图 4 攻击事件占比对日志分析时间的影响 |
本研究选取了一个网站的日志样本对其分析，可以得出每日的站点综合风险指数SCRI，对连续15 d的SCRI进行观测，形成如图 5所示采样序列.
|
图 5 SCRI采样示例 |
通过态势评判，可以得出该网站在近3 d所受攻击有增加趋势，可提醒安全管理人员提升注意力.
4 系统实施Web日志审计系统总体采用B/S架构实现.针对小型网络，系统通过安装在服务器上的采集器获取日志数据进行集中分析.针对大型企业网络，系统采用分级管理方案部署，通过不同分支机构的采集点获取日志数据进行集中分析，图 6所示为系统在大型网络中部署的拓扑图.
|
图 6 大型网络中的系统部署拓扑图 |
实现了一种高效安全的Web服务器日志审计系统.由于日志为海量文本文件，采用JSON的数据交换格式、MongoDB数据库和轻量级的Web服务器来提高日志处理效率.同时，采用正则表达式识别网络行为，运用综合风险评估来预测网站安全态势.在今后的研究中，将采用数据拟合方法精确推算站点安全态势，并增强攻击行为的数据挖掘，找出攻击行为模式，提供更为准确的安全告警.
| [1] | Agosti, Maristella, Crivellari, et al. Web log analysis:a review of a decade of studies about information acquisition, inspection and interpretation of user interaction[J].Data Mining and Knowledge Discovery, 2010, 24(3): 663–696. |
| [2] |
钱秀槟, 李锦川, 方星. 信息安全事件定位中的Web日志分析方法[J]. 信息网络安全, 2010(6): 79–80.
Qian Xiubin, Li Jinchuan, Fang Xing. Information security event location in the web log analysis method[J].Information Network Security, 2010(6): 79–80. |
| [3] |
武斌, 郑康锋, 杨义先. Honeynet中的告警日志分析[J]. 北京邮电大学学报, 2008, 31(6): 63–66.
Wu Bin, Zheng Kangfeng, Yang Yixian. Analysis of alert correlation in honeynet[J].Journal of Beijing University of Posts and Telecommunications, 2008, 31(6): 63–66. |
| [4] | Suneetha K R, Krishnamoorthi R. Identifying user behavior by analyzing web server access log file[J].IJCSNS International Journal of Computer Science and Network Security, 2009, 9(4): 327–332. |
| [5] | Hallam-Baker P M, Behlendorf B. Extended log file format[EB/OL]. 1996. http://www.w3.org/TR/WD-logfile.html. |