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

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

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

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

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

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

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

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

【→所有资源关注我，私信回复“资料”获取←】

1、网络安全学习路线

2、电子书籍（白帽子）

3、安全大厂内部视频

4、100份src文档

5、常见安全面试题

6、ctf大赛经典题目解析

7、全套工具包

8、应急响应笔记

二、网络关联分析技术

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

根据公式计算，谁都会，上述公式1中各个参数之间有什么内在联系？

在我们收集到的事件中，重复事件占比多，其中主要是Risk=0的风险，例如以Cisco ASA的一个ICMP事件为例，其PRIO=1，REL=1，ASET=2，根据上面的风险模型计算公式计算出来约等于0。

分析上图发现在关联规则中Reliability（可信度)系统为它已经设定好了一个初始值，试想如果是个常量，那在动态的网络攻击中将会产生大量误报，那么在引入交叉关联机制之后，就将网络安全报警和具体网络应用服务、开放端口、开放端口的漏洞信息进行空间上的关联，以便确定攻击是否可达到，这样可信度值(reliability)就必定为变量，对于那些含有不可能存在端口安全事件直接丢弃（系统的KDB中有一张即时更行的列表）下图展示了reliability参数在OSSIM关联规则变化过程。

5.事件聚合

我们知道冗余报警会严重干扰管理员对故障的判断，此时需要这些信息进行聚合，通过从海量报警中，将一些相似的报警进行聚合处理，把冗余部分去掉，减少了报警条数，大大减轻了关联模块做关联分析的任务量。

合并冗余的报警信息主要是从3方面来考虑：

（1）合并基于主机的监控 Ossec 产生的冗余报警事件。

（2）合并基于网络的监控 Snort/Suricata 产生的冗余报警事件。

（3）合并主机监控 Ossec 和网络监控 Snort 对相同攻击产生的报警信息。

Snort报警信息的属性比较全面，特征明显，对Snort产生出来的报警事件合并的过程可以采用基于属性相似度的方法。而对于Ossec的报警事件的合并，OSSIM采用基于事件ID和报警类别信息相结合的方法。目前Ossec有900多条检测规则，均以XML格式存储。经过统计分析以后可以按报警的行为来分类共分为80个报警大类，常见的包括：Syslog、Firewall、IDS、Web、Squid、Windows等。以OSSEC报警的事件ID为入口，从而进行一级级的类与子类之间的匹配以达到匹配与合并的目的。

根据信息来源分析我们看到聚合的对象是基于网络的 Snort /Suricata和基于主机的Ossec安全产品产生的报警数据，由于 Snort 的报警数据（包括IP 地址，攻击内容和端口等之类的要素）中含有协议属性，可对其用基于规则的方式进行聚合，在聚类过程中可以保证报警信息得到正确的归类。

Snort支持多种协议，报警事件聚类后再合并能节省大量时间。而同样由于其属性明显的特征，所以对冗余信息的合并基于其属性的相似度的方式进行，这样合并误差小。而对于 Ossec 产生的报警信息，其报警事件的 ID 为入口，逐步的按报警类别进行聚合，合并出来的误差低，以 ID 为入口按根类别进行合并的方式，节省了遍历报警信息进行聚类与合并的时间。

OSSIM中使用了主机监控软件 Ossec 来实现对主机的审计记录，系统日志和应用程序的采集分析。它支持文件的完整性监控、注册表监控、端口的监控、Rootkit 检测和部分进程监控。同时使用Snort 对网络上的数据包进行采集，完成实时流量分析和对网络上的 IP 包进行测试等功能，也可进行协议分析，内容查找和匹配，能用来探测多种攻击和嗅探（如缓冲区溢出和 ShellCode攻击等）。

对于两条事件而言，如果它们的相似程度较高，那么就认为它们是同一个攻击而进行合并，否则就认为是互不相关的攻击行为。

我们可以从计算两条报警信息之间的相似度入手，首先要考虑的是这两条报警的共有属性。这些属性包括攻击源、目标(主机 IP 和端口)、攻击类型、MAC 地址、时间信息和事件 ID 等。据此我们可以对报警事件的属性进行抽象形式化建模，把它们的属性定义为一个事件属性集。我们对冗余的报警事件所采用的合并方法的出发点就是对相同的攻击行为的报警信息之间存在着很高的相似度，对不同的攻击行为的报警相似度较低。我们对各个产品的冗余报警信息合并的同时也要考虑到这两个安全产品产生出来的对同一个攻击的报警信息，尽可能的把所有重复报警信息得到有效的压缩。

如果Snort发现基于一个目标IP的攻击，则说明该目标IP主机有漏洞，则其可靠性系数为10（即100%攻击成功）。下图中REL的值为10，即代表当前时间可靠性系数为10，所以风险值为4。这个值也可以在数据源中修改。

从上可知，可靠性和优先级的数值决定了风险大小，手动修改数据源REL/PRIO的方法如下图所示。注意这样修改后对全局有效 ，并不是对单条事件。通过传感器将各个监控节点数据关联联系起来，形成一个数据链，再由关联分析引擎和规则一起协调工作就能对黑客攻击行为进行分析，追根溯源，并发出Alarm。下面分析一下它的产生原理。

Alarm Events由关联指令（Correlation Directives）配合Rules所产生，在Alarm中展示的警告信息是通过关联规则从大量的事件中匹配而得出，在OSSIM 5以后的系统采用了一种图形化展示OSSIM系统Alarm报警的模式，这便于管理员重大量安全事件中筛选重要的部分。Alarm事件产生过程如图所示。

具体Alarm生成步骤如下：

（1）日志收集到OSSIM；

（2）将日志统一进行归一化处理后生成事件；

（3）将这些事件导入关联引擎；

（4）根据关联规则匹配出新的事件。

通过上图显示的画面，即使是一个安全小白也能轻松检测到针对SSH服务的暴力破解行为。

在这张图中仅以System Compromise→Worm infection →Internal Host scanning 告警为例，在系统危害中出现了内部主机的扫描行为，这类行为疑似为网络蠕虫的扫描，我们知道扫描主机漏洞往往是蠕虫传播的前提，蠕虫常常会通过ICMP Ping包、TCP SYN、FIN、RST以及ACK包探测，而且具有着随机性，从图中看出，系统定义出这类事件的风险值，扫描的持续时间，源地址、目的地址，源端口、目标端口以及关联等级，对于这种异常行为很容易被OSSIM发现。

五、关联规则指令

关联分析的核心通过一个或一组关联指令来完成，下面用SSH暴力破解的例子加以说明，SSH暴力破解（Brute Force）大约自UNIX诞生之后，就衍生出来的一种攻击行为，据统计发现大约有50%以上的用户名是root。一个低可靠性（low reliability）的SSH 服务器，在经过100登录尝试之后成功登录，而高可靠性（high reliability）的SSH服务器，则经过10000次登录才成功，那么关联引擎可通过在一定时间内，登录的次数，以及这些时间的不同源地址和相同目标IP地址，以及这些IP地址来自于那些国家，它们信誉度如何等信息来综合判定攻击以及作出响应。

检测SSH暴力攻击的关联指令规则源码用XML描述如下：

<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平台下的网络日志关联分析技术希望能给大家在日常网络安全运维中提供一些帮助。