本文主要对OSSIM实现日志关联技术进行深入分析。

一、网络安全管理中面临的挑战

目前很多组织都已经拥有了防火墙、入侵检测、防病毒系统、网管软件，但是网络管理者在安全追根溯源及安全管理面临如下挑战：

1 .安全设备和网络应用产生的安全事件数量巨大，误报严重。一台IDS系统一天产生的安全事件数量近成千上万。通常99%的安全事件都是误报。真正有威胁的安全事件淹没于海量信息中难于识别。

2. 安全事件之间存在的横向和纵向方面（如不同空间来源、时间序列等）的关系未能得到综合分析，因此漏报严重，不能实现实时预测。一个攻击活动之后常常接着另一个攻击活动，前一个攻击活动为后者提供基本条件；一个攻击活动在多个安全设备上产生了安全事件；多个不同来源的安全事件其实是一次协作攻击，这些都缺乏有效的综合分析。

3.安全管理者缺乏对整个网络安全态势的全局实时感知能力，安全设备各自为政，设备所产生庞大的日志冗余，独立而分散，真假难辩，显然无法直接作为安全事件响应的依据。

下面举例一个拥有500台电脑的中型企业，网络安全产品每天产生的事件数量，如表1所示。

表1 典型企业日志产量分析

我们通过现有的日志采集技术收集这些日志难度并不大，然而安全人员很难在短时间内识别出海量安全事件之间内部端倪，分析日志相关性更是无从下手。此时我们需要一种技术能够帮助我们实现从海量日志数据处理分析后能自动得到网络异常报警，这样才能提高安全团队发现网络威胁的效率。

二、网络关联分析技术

面对上述问题，可以关联分析平台来解决问题，这种平台可以为我们集中展示网络安全各方面的概况，同时还提供有实时监视和事件关联、风险分析、报告、通知功能，可在企业范围内全面管理、审计安全事务，大大提高了网络安全风险识别能力。关联分析平台依托关联分析核心技术集中在：日志收集、日志格式化（也叫做归一化）、日志关联分析3个方面。

1.日志收集：一个SIM产品是否有优势，就要看日志收集，能否支持更多的类型，能否容易扩展，自动识别支持未知设备日志。例如需要支持的协议有syslog、snmp trap、windows log、database、file、xml、soap等。

2.日志格式化：日志收集之后，需要格式化统一标准，这些统一格式会在原有日志基础上附加风险值、可靠性、优先级等标签，为后面的关联分析做准备，如果格式化不够标准，关联分析无法实现。以下是归一化格式：下面以SSH原始日志和标准化日志的前后对比：可以看出SSH暴力破解事件比原始日志多了许多元素，但这些增加项可以为今后日志关联分析做好了准备。

三、日志关联分析

在日志格式化基础之上通过一定算法（上下文关联、攻击场景关联等）从多个数据源获取事件进行关联分析，实现不同日志的风险值，并结合资产的漏洞信息以及进出流量综合计算出网络资产受威胁程度，最后发出报警，以便提醒管理员。这就大大降低了管理员分析海量日志的难度。为了达到安全事件关联分析的目的，就要有好的事件处理机制，比如前面讲的日志收集的归一化处理，还得有好的关联方法，而且不止一种关联方法，将多种实时关联方法结合到一起效果更佳。大量标准化处理的事件被送入关联引擎处理后，它们会经历事件分类处理、聚合、交叉关联、启发式关联等多种关联方法，系统会根据数据库中的安全事件进行统计分类。

下面我们再看个关联分析场景：

（1）比如在VPN服务器日志显示张三3:00点钟，从外网登录到内部网，3:05分登录FTP服务器，并在FTP服务器上下载了某一文件。在门禁系统的日志显示张三在不久前刚刚进入办公区域，这三个日志可以关联出一个安全事件。

（2）某公司核心数据库前端部署了防火墙系统，某日安全系统监测发现张三登录了MySQL数据库服务器，但是在防火墙日志中并没有发现张三的访问日志，则说明张三很有可能绕过防火墙直接去登录数据库服务器。

3).网络中OpenVas扫到某Linux主机存在Apache 2.2.x Scoreboard(本地安全限制绕过)漏洞，与此同时，NIDS检测到了一个对该主机漏洞的尝试攻击事件，如果此时该Linux服务器打上了相应补丁，则关联分析结果就是低风险值，不会报警，如果没有打补丁此时审计系统就会报警。

对于每套系统管理都有它的安全防护措施，只不过都是安全孤岛而已，但是万事万物之间必然有它的联系，将这些日志联系到一起分析，就是我们上面介绍的关联分析技术。

四.OSSIM关联引擎

1.关联引擎概述

OSSIM平台下实现关联分析技术核心是关联引擎，在OSSIM传感器将大量标准化处理的事件被送入关联引擎处理后，它们会经历事件分类处理、聚合、交叉关联、启发式关联等多种关联方法，系统会根据数据库中的安全事件进行统计分类，找出经常导致安全事件的发源地和经常被攻击的端口，在这些阶段都会产生事件告警，其安全事件关联过程模块如下图所示。

在管理引擎中的事件聚合模块可以为后续关联提供高质量的安全事件，提高关联引擎效率，而分类处理可将已知可信度高，受关注高的安全事件直接提升为报警。而且统计分类通过对报警数据库、日志数据库、知识库综合进行分析统计，产生受控网段内最常被攻击的主机和应用，统计相同数据源和相同目标端口的安全事件的数量，这样就可以客观反映网络异常情况。

在OSSIM系统中关联分析功能同样是由关联引擎来实现，关联引擎策略文件定义位于/etc/ossim/server/，分析的数据由探针来收集，Sensor（传感器）每天要从网络上收集到成千上万的事件，如果对这些海量的事件信息不加任何处理就直接生成事件，这种做法是没有意义的。而在报告之前通过关联分析可以将这些成千上万的事件进行浓缩（类聚），并确认成数十个甚至数个事件，显示在Web前端的SIEM中。简单理解就是OSSIM的网络安全事件关联分析能将不同功能的开源网络安全检测工具产生的报警信息进行去伪存真，从而挖掘出真正的网络攻击事件。

2.主要关键词

OSSIM系统中的风险评估主要围绕着攻击威胁（Threat）、漏洞（Vulnerability）、响应（Response,即安全措施）、资产（Asset）等来监控。风险评估模型嵌入在 OSSIM 关联引擎系统中，关联引擎结合知识库中的资产库、漏洞库、威胁库将风险的资产、漏洞、威胁三要素综合考虑。

3.资产风险计算

Risk=R(asset,vulnerability,threat)

将资产价值（Asset）、优先级（Priority）、可靠性（Reliability）三个参数组合在一起进行风险的计算是简洁有效的，在OSSIM系统中使用以下公式：

Risk=asset*priority*reliability/25     （风险模型计算公式1）

其中Asset（资产，      取值范围0~5）

Priority（优先级，     取值范围0~5）

Reliability（可信度，取值范围0~10）

由公式（1）计算每个Alert事件的Risk值，其中

Ø Asset 的取值范围为 0～5，asset默认值为2；在OSSIM系统中将资产的关注程度分为5级，取值由低到高分别为1、2、3、4、5。从表面上理解，数字的大小决定了风险计算公式中Risk值的大小，但也有它深层次的含义，比如普通工作站资产等级为1，当它遭受DOS攻击时，我们只需要简单端口网络连接，如果是数据库服务器，它的资产等级为5，数据库服务需要实时在线，所以同样遭受DOS攻击我们就不能象工作站那样处理，而应自动启用备用IP地址并将攻击引向网络蜜罐系统。

Ø 优先级Priority 的取值范围为 0～5，默认值为 1，该参数描述一次成功攻击所造成的危害程度，数值越大，则危害程度越高；

Ø 可信度或者叫可靠性Reliability 的取值范围为 0～10，默认值为 1，可靠性参数描述一次攻击可能成功的概率，最高值是10，代表100%可能，所以其值越高，代表越不可靠，大家也可以将此理解为被攻击的可能性。

大家在操作OSSIM时，打开Web UI中的SIEM控制台，观察每条Event时就能发现风险值由资产值优先级和可信度来控制。而网络中每个资产都是有价值的，这个价值的量化就通过资产值来实现，默认每个资产为2（范围1~5），在风险计算公式可以分析出，风险计算不将资产值作为影响风险结果的主要因素，例如某些数据库服务器资产值很高，则计算出的风险值也会很大，而那些资产值小的工作站，在遭受严重攻击的节点风险值小，这样很难被关注，从而失去原本的真实性，所以就让资产值的范围在1~5之间，影响风险值也就小。

场景举例：

一个主机在一个VLAN连接到5个不同IP地址的445端口，这有可能是正常网络通讯，如果连接了15台机器的445端口这就比较可疑，如果有150个这样的连接并且持续很长时间，那就很可能受到蠕虫攻击，需人工要进一步核实。

4.Risk directive id="50113" name="AV-FREE-FEED Bruteforce attack, SSH service authentication attack against DST_IP" priority="4">
rule type="detector" name="SSH service authentication attempt failed detected" reliability="1" occurrence="1" from="ANY" to="ANY" port_from="ANY" port_to="ANY" plugin_id="4003" plugin_sid="1">
rules>
rule type="detector" name="SSH service authentication attempt failed detected" reliability="2"occurrence="5"from="1:SRC_IP" to="1:DST_IP" port_from="ANY" time_out="30"port_to="ANY" plugin_id="4003" plugin_sid="1">
rules>
rule type="detector" name="SSH service authentication attempt failed detected"reliability="4"occurrence="10"from="1:SRC_IP" to="1:DST_IP" port_from="ANY" time_out="60"port_to="ANY" plugin_id="4003" plugin_sid="1">
rules>
rule type="detector" name="SSH service authentication attempt failed detected" reliability="6"occurrence="50"from="1:SRC_IP" to="1:DST_IP" port_from="ANY" time_out="300"port_to="ANY" plugin_id="4003" plugin_sid="1">
rules>
rule type="detector" name="SSH service authentication attempt failed detected" reliability="8"occurrence="500" from="1:SRC_IP" to="1:DST_IP" port_from="ANY" time_out="36000"port_to="ANY" plugin_id="4003" plugin_sid="1">
rules>
rule type="detector" name="SSH service authentication attempt failed detected" reliability="10"occurrence="1000" from="1:SRC_IP" to="1:DST_IP" port_from="ANY" time_out="86400"port_to="ANY" plugin_id="4003" plugin_sid="1"/>
rule type="detector" name="SSH service authentication sucessful" reliability="10" occurrence="1" from="1:SRC_IP" to="1:DST_IP" port_from="ANY" time_out="10" port_to="ANY" plugin_id="4003" plugin_sid="7"/>
/rules>

参数解释：

这些指令常用XML来描述，如果不理解其含义，如果自己写脚本或修改脚本时就无从下手。整个关联规则系统有个完整的规则属性，含义如下：

• Id，该属性允许定义相关联指令的唯一标识。这种编号必须遵循由OSSIM发布的指令。以便在框架中（关联菜单的子指令菜单）实现的分类显示得到准确实现。编号指令在此子菜单中可用。
• Name，此属性允许定义指令的名称。（当指令匹配时显示）
• SRC , 源IP地址
• DST，目标IP地址
• Port_from 源端口
• Port_to 目标端口
• Priority，此属性允许定义关联指令的优先级。
• Type，该属性定义规则类型。仅有两种类型的规则。
• Detector，使用检测部件信息的规则，其包含于服务器数据库。
• Reliability（可靠性，也叫可信度），此参数越大（接近10），表明报警越真实。此参数在关联过程中至关重要。实际上，随着规则的陆续匹配，本组报警误报的概率会降低。所以有可能在每个标记规则中修改高级报警的可靠性。其后的规则会以相对（例如：+3，意味着相对于前面的规则，全局可靠性提高了3个等级）或者绝对（例如：7，表明现在的可靠性等级是7）的方式估计其等级。
• Occrrence ，出现频率
• Plugin_id，此属性定义由规则预计的报警的来源。实际上，每个插件有一个相关标识，此标识允许在相关性规则中引用该插件。
• Plugin_sid，此参数定义了和插件相关联的事件。实际上，所有被OSSIM恢复的事件都被索引（依照其插件）并且配置。通过在配置菜单的插件子菜单中点击所需plugin_id便可以配置plugin_sid。例如，由plugin_id 1501和plugin_sid400提供的报警等同于：“apache：错误请求”有了这两种属性（plugin_id和plugin_sid），就可以精确定义规则所预计的事件。
• Time_out，超时设定，此属性允许表明符合某个规则的事件的等待时间。如果此事件没有在给定的时间（通过属性以秒计算）内发生，相关性指令会结束并返回到前面规则计算的结果。此属性可以确定由规则所预计的警报（事件）必须显示的临时窗口。
• Protocol（协议），此属性允许配置由规则预计的网络事件类型。可以定义三种类型的协议：TCP、UDP、ICMP，此属性允许绝对引用。此意味着有可能重新使用和前规则匹配的协议类型。所以，只需做如下表明：protocol=“1:PROTOCOL”，以此来明确表达此规则的协议和由一级规则相匹配的协议相同。如果要恢复二级规则匹配的协议，只需明确表达：protocol=“2:PROTOCOL” 。
• From，此属性允许明确表明预报警的IP源地址。可以使用6种不同的方法来表示：

①ANY，表明任意地址源和此属性匹配。

②x.x.x.x IP地址。

③通过引用，和引用协议属性原则一致。（例如：1：SCR_IP= 和一级相关指令匹配的报警的源地址，2：DST_IP= 和二级相关性指令的报警的目标地址）。

六、关联规则实战

将规则导入OSSIM关联分析引擎后显示，如下图所示。

准备工作就绪之后开始测试：

在攻击机(Kali 2021，192.168.183.158)启动medusa对，靶机开放的ssh端口进行测试（命令从略）。随后在登录靶机（192.168.183.139）查看SSH日志：

传统方式分析这些日志费时费力而且往往不能及时判定故障，下面我没看以下OSSIM的归一化事件，如下图所示。

关联分析结果

从上图看出风险值为3，很显然可以定性为针对SSH服务的暴力攻击。这一过程是自动化完成，规则写对了，无需人工干预，自动实现报警。

七、总结

对于新手而言从一张白纸开始写规则有些难了，但是对照系统给出的默认规则，照葫芦画瓢还是可以实现的，不管这个模型是否完善，先用起来，然后逐步修改。在合适的时间，对系统进行渗透测试，然后监控SIEM的反应，观察它是否产生正确的警报，而警报是否提供足够的信息来协助相应这弄清楚发生了什么威胁，如果没有那就需要修改规则，然后你需要不断的优化阈值。本文简要为大家介绍了OSSIM平台下的网络日志关联分析技术希望能给大家在日常网络安全运维中提供一些帮助。