每日一搏 | OSSIM 架构与组成综述

OSSIM架构与组成综述

OSSIM布道师 李晨光

一、背景

如果运维工程师手里没有高效的管理工具支持，就很难快速处理故障。市面上有很多运维监控工具，例如商业版的 Solarwinds、ManageEngine以及WhatsUp等，开源的MRTG、Nagios、Cacti、Zabbix、OpenNMS、Ganglia等。

由于它们彼此之间所生成的数据没有关联，无法共享，即便部署了这些工具，很多运维人员并没有从中真正解脱出来，成千上万条警告信息堆积在一起，很难识别问题的根源，结果被海量日志所淹没，无法解脱出来。

另外在传统运维环境中，当查看各种监控系统时需要多次登录，查看繁多的界面，更新管理绝大多数工作主要是手工操作，即使一个简单的系统变更，需要运维人员逐一登录系统，若遇到问题，管理员便会在各种平台间来回查询，或靠人肉方式搜索故障关键词，不断的重复着这种工作方式。企业需要一种集成安全的运维平台，满足专业化、标准化和流程化的需要来实现运维工作的自动化管理，通过关联分析及时发现故障隐患，这种优秀的开源平台叫做OSSIM即开源安全信息管理系统(Open source Security Information Management)，下面让我们认识一下OSSIM的基本结构和组成

从架构上来看，OSSIM系统是一个开放的框架，它的核心价值在于创新的集成各开源软件之所长，它里面的模块既有C/S架构，又有B/S架构，但作为最终用户主要掌握OSSIM WebUI主要采用B/S架构，Web服务器使用Apache。OSSIM系统结构示意图如图1所示。

图1 OSSIM系统结构

第1 层 ，属于数据采集层，使用各种采集技术采集流量信息、日志、各种资产信息，经过归一化处理后传入核心层。改层体现安全事件来源，入侵检测、防火墙、重要主机发出的日志都是安全事件来源，它们按发出机制分为两类：模式侦查器和异常监控（两者都采集警告信息，功能互补）由它们采集的安全事件，再被Agent转换为统一的格式发到OSSIM服务器，这一层就是Sensor要完成的内容。

第2 层 ，属于核心处理层，主要实现对各种数据的深入加工处理，包括运行监控、安全分析、策略管理、风险评估、关联分析、安全对象管理、脆弱性管理、事件管理、报表管理等。该层中OSSIM Server是主角，OSSIM服务器，主要功能是安全事件的集中并对集中后的事件进行关联分析、风险评估及严重性标注等。所谓的集中就是以一种统一格式组织所有系统产生的安全事件告警信息（Alarms）并将所有的网络安全事件告警存储到数据库，这样就完成了对网络中所产生事件的一个庞大视图。系统通过事件序列关联和启发式算法关联来更好的识别误报和侦查攻击的能力。

OSSIM本质上通过对各种探测器和监控产生的告警进行格式化处理，再进行关联分析，通过后期这些处理能提高检测性能，即减少告警数量，减小关联引擎的压力，从整体上提高告警质量。

第3 层 ，属于数据展现层，主要负责完成与用户之间的交互，达到安全预警和事件监控、安全运行监控、综合分析的统一展示，形式上以图形化方式展示给用户。Web框架(Framework)控制台界面即OSSIM的Web UI（Web User Interface，Web用户界面），其实就是OSSIM系统对外的门户站点，它主要由仪表盘、SIEM控制台、Alarm控制台、资产漏洞扫描管理、可靠性监控、报表及系统策略等部分组成。

二、 主要模块的关系

OSSIM系统主要使用了PHP、Python、Perl和C等四种编程语言，从软件层面上看OSSIM框架系统包括五大模块：Agent模块、Server模块、Database数据库模块、Frameworkd模块以及Framework模块，逻辑结构图见2所示。

图2 Ossim系统逻辑结构

五个模块之间的数据流向如图3所示：

图3 五大模块的数据流向

① Agent至Server：来自各个传感器的安全事件被对应Agent格式化后，以加密字符串传给Server。

② Server至Agent：发送有关请求命令（request command），以字符串方式向Agent传送，主要是要求Agent完成插件的启动停止及获取信息等。

③ Server至Frameworkd:发送请求命令，要求Frameworkd针对Alarm采取相应操作，例如执行外部程序或发出Email来通知管理员。

④ Framework至Server：发送请求命令至Server。要求Server通知Agent对插件（Plugins）进行启动、停止等操作。

⑤ Framework至Frameworkd:发送请求命令，要求Frameworkd启动OpenVas扫描进程。

⑥ Frameworkd至Framework:传送OpenVas扫描结果在前端页面中显示。

⑦ Database至Agent和Server：向Agent和Server提供数据。

⑧ Server至Database：Server需要将Events、Alarms等数据存入数据库并索引或更新操作。

⑨ Database至Frameworkd:在Frameworkd中的Openvas扫描和动作需要用调用数据库里的数据。

⑩ Frameworkd至Database：在Frameworkd执行过程中将Openvas扫描结果存入数据库。

⑾Database至Framework:PHP页面显示需要调用数据库的告警事件。

⑿Framework至Database：用户参数设置信息需要存入数据库。

三、安全插件（Plugins）

OSSIM系统中插件繁多，超乎你的想象，大致可将它们分为采集（Collection）插件和监视（Monitor）插件。每个插件都有又细分为ID和SID。采集插件主要通过SNMP、Syslog、WMI等协议进行采集，在Sensor中常见采集插件有ossec-single-line、ssh、syslog、wmi-system-logger等，其中SNMP与WMI协议需要Agent采集数据时主动进行所采集数据的抓取；Syslog协议则被动接收采集数据。具体如图4所示。

图4 查看插件

监控插件包括malwaredomainlist、nessus、nmap、ntop、ocs、ossim等，如图5所示。

图5 设置监控插件

当这些插件加载完毕之后，我们可以到Web UI中Configuration→Deployment→Components→Sensors栏目下的“ Sensor Status”查看所添加的监控插件的工作状态，如图6所示。

图6 查看Sensor监控插件工作状态

UNIX/Linux环境下，大部分系统都安装有SNMP与Syslog工具。如果采集数据的目标系统为Windows，那么考虑使用WMI协议，此时只需要在Windows上进行相关配置，以便能够远程访问，无需安装额外的工具软件。

四、 采集与监控插件的区别

在OSSIM系统的Sensor端包含了采集（Collection）和监控（Monitor）这两类插件统称为安全插件，它们都安装在Sensor上。虽然都称为插件可工作原理却不同，检测插件（Detector）是检测器信息产生后，由代理自动向服务器发送，包括Snort、Apache等。而检测器插件需要主动采集安全设备接口上的信息，这类插件可分为Snort、P0f、Prads、Arpwatch、Apache、SSH、Sudo等。

监控(Monitor)插件，必须由服务器主动发起查询请求。监控插件中定义了需要主动采集的安全设备接口，该模块接收控制中心发出的命令和查询，在OSSIM系统中典型Monitor插件有Ntop、Nmap、Nessus等。读者可在Alienvault控制台的Sensor配置中（Configure Monitor Plugins）查看。OSSIM主要安全插件如表1所示。

表1 OSSIM主要插件分布情况

对OSSIM插件位置的说明：在安装时系统将支持的插件，全部复制到目录/etc/ossim/agent/plugins/目录中，如Nagios插件的扩展名为“.cfg”的文本文件，可以用任何编辑器修改，在每个插件配置文件中最难理解的当属理解正则表达式(RegExp)。OSSIM下主要插件如图7所示。

图7 规则与插件路径

在今后安装过程中，选择多少插件系统就在开机时加载多少（插件加载越多越占用内存）。具体查看插件详情，访问/etc/ossim/agent/config.cfg配置文件，而且在系统/etc/ossim/ossim_setup.conf中的[sensor]项中也详细列出了监控插件（monitors）和检测插件(detector)分别包含了哪些内容。在插件这方面，OSSIM默认提供了上百个插件，涉及8个大类，在表1-2中仅列出了一小部分，从插件分布和数量来看，OSSIM系统几乎包含了常用的插件类型。例如运维设备Cisco、CheckPoint、F5、Fortigate、Netscreen、Sonicwall、Symantec等，如果遇到无法识别设备的插件，只能自己编写插件，后续内容会详细讲到，已加载插件如图8，图9所示。

图8 查看传感器启用的插件情况

从图中看出，此Sensor系统中启用了9个插件，如何在Web上展示出来呢？如图所示总共184个插件在Plugins enabled中启用了9个插件。

图9 查看加载插件详情

从图10看出这里显示9个插件，我们可打开/etc/ossim/ossim_setup.conf文件查看。

图10 从Ossim配置文件中查看插件

五、 检测器（Detector）

OSSIM下的检测器起到收集资源信息及监听当前网段数据包的作用，主要包括ntop、prads、suricata、ossec等，相关内容在后续章节里会详细介绍。

六、 代理（Agent）

代理进程（由于Agent采用Python语言编写，所以无需编译就能在Python Shell环境运行）将运行在多个主机上，负责从安全设备采集相关信息（比如报警日志等），并将采集到的各类信息统一格式，最后将这些数据传至Server。

从采集方式上看，Agent属于主动采集，可以形象理解为由OSSIM Server安插在各个监控网段的“耳目”，由它们收集数据，并主动推送到Collector中，然后Collector又连接着消息队列系统、缓存系统及存储系统。

OSSIM中的这些代理脚本位于/usr/share/alienvault/ossim-agent/目录下，脚本经过加密，以.pyo为扩展名。

列如OSSIM代理(ossim-agent)直接读取存储在/var/log/suricata/unified2.alert.1428975051日志。

suricata的报警输出文件是/var/log/suricata/unified2.alert,这是由/etc/suricata/suricata.yaml配置文件在111行 # alert output for use with Barnyard2定义，所以ossim-agent直接读取该文件就能显示在SIEM控制台中。

Agent的主要功能是接收或抓取Plugins发送过来或者生成的日志，经过归一化处理，然后有序地传送到OSSIM的Server，它的功能很复杂，因为它的设计要考虑到如果Agent和Server之间的网络中断、拥堵、丢包等情况。

在免费版的OSSIM系统中，其日志处理大部分情况下不能达到实时，但可以达到准实时（Firm Real-Time），通常会在Agent端缓存一段时间才会发送到Server端去。Agent会主动连接两个端口与外界通信，一个是连接Server的40001端口（在/etc/ossim/agent/config.cfg配置文件的选项[output-server]中端口设置能看出通讯端口为40001），而另一个是连接数据库的3306端口。如图11所示。

图11 日志归一化处理、收集与存储

原始日志被分成若干段填充到相应的域中，这些字段如下：

l date、sensor、interface、plugin_id、plugin_sid、priority、protocol、src_ip、src_port、dst_ip、dst_port

l username、password、filename、userdata1、userdata2、userdata3、userdata4、userdata5、userdata6、userdata7、userdata8、userdata9

其实Sensor的输出数据就是Ossim Server的输入“原料”，我们可在WebUI中查看Sensor的output情况。如图12所示。

图12 Sensor输出

七、报警格式的解码

报警信息的接收过程中，为了应对报警信息格式的变化，OSSIM采用基于正则表达式的方法对报警信息进行匹配，解析报警事件获取关键信息。正则表达式是一串记录文本规则的代码组合，它的作用是用来进行文本匹配。例如对空白字符、数字字符、中英文字符、IP和 E-mail地址等匹配，简单的说它就是一个普通的字符查找串。

例如，下面对一段Snort报警信息进行正则表达式的匹配。

5/26-01:02:17.670721 [**] [1:1419:9] SNMP trap udp [**] [Classification: Attempted

Information Leak] [Priority: 2] {UDP} 20.20.13.17:162 -> 20.20.20.78:162

<ids>

<name>snort</name>

<method>net_socket</method>

<regex>^(/d+//d+-/d+:/d+:/d+)./d+/s+[**] [/d:(/d+):/d+] /.+[Classification: (/.+)]

[Priority: (/d)] {(/.+)} (/d+./d+./d+./d+)/p*(/d*)->(/d+./d+./d+./d+)/p*(/d*)</regex>

<order>time,id,classtype,priority,protocol,srcip,srcport,dstip,dstport</order>

<mapping>snort_classtype,snort_id</mapping>

</ids>

这样通过正则表达式可以提取时间、id、分类、报警级别、协议、源IP、源端口、目的IP 和目标端口等信息。接着再将这些字段逐个存储为标准化的表中，最后通过Web界面展现。

八、OSSIM Agent

Agent运行在Sensor中，负责从各安全设备、安全工具的插件中采集相关信息(比如IIS服务日志、Snort报警日志等)，并将采集到的各类信息统一格式，再将这些数据传至Server，例如将Snort系统产生的报警信息收集并存储在OSSIM Server中。

OSSIM Agent中所有脚本采用Python编写，相关目录在/etc/ossim/agent/，代理插件目录在/etc/ossim/agent/plugins/，配置文件路径：/etc/ossim/agent/config.cfg，OSSIM系统的代理信息查看方法，通过Analysis→Detection下的HIDS标签中Agents查看。结构如图13所示。

图13 Agent结构

l 40002/tcp： 监听服务器的原始请求。

l Listener： 接收服务器连接请求。

l Active： 接收服务器输入并且根据请求扫描主机。

l Engine： 管理线程，处理监视器请求。

l Detector Plugin：读取日志和进行归一化处理。

l Monitor Plugin：请求监视器数据。

l DB-Connect： 连接到本地/远程OSSIM数据库。

l Watchdog： 监视进程启动/停止进程，检查各插件是否已经开始运行，如遇意外，它会发现并重启相关进程，它自动检查时间为180秒，重启进程时间为3600秒，其值可以在/etc/ossim/agent/config.cfg配置文件中修改。

OSSIM中定义的大部分插件其日志都默认存放在/var/log/syslog中，所以自定义插件式往往需要修改日志的存放位置，在本书后面的例子中将详细讲解。

表2 插件的日志路径

表2分析了目录/etc/ossim/agent/plugin/中主要插件的日志输出情况，通过该表我们能够很容易的了解正则表达式的匹配情况。我们进入/etc/ossim/agent/plugings/目录，其下有197个插件，如何能了解每个插件的日志的匹配情况呢？例如SSH插件对应的文件为ssh.cfg，记录的日志文件为/var/log/auth.log，匹配的详情我们通过以下命令实现(在OSSIM 4.4之后的版本中已去除了regexp.py调试脚本，大家可以到作者博客下载该脚本 ，以便完成后续试验)。

下面看个Apache访问日志的例子，首先在/var/log/apache2/access.log中的两条日志如下：

图14 Apache日志实例

插件检测格式：

./regexp.py log_filename regexp modifier

l y:显示不匹配的行

l v: 显示匹配的行

l q: 只显示摘要

如同在Linux定义别名一样，在regexp.py脚本中也定义了别名，区别是它采用aliases定义，详情如下：

图15 定义别名

为了方便插件内容的定义，插件中使用了经常用到的内容来定义别名，这样做的好处是当今后在定义某一插件内容时，便可使用已定义的别名代替那个元素，比如用IPV4代替/d{1,3{/./d{1,3}/./d{1,3}/d{1,3}的定义。由此可知，插件中定义的Apache访问日志的正则表达式为：

regexp=(/IPV4) (/S+) (/S+) /[(?P<date>(/d/d)//(/w/w/w)//(/d/d/d/d):(/d/d):(/d/d):(/d/d)).+"(?P<info>.+)" (?P<sid>/d+) (/S+)

通过插件匹配的详细结果如下：

图16 Apache匹配结果

由此可见，经过处理后的日志内容并没变，为了适应SIEM事件显示需要，实际日志中各项的排列顺序发生了改变，目的是方便阅读，方便更好的展示在SIEM控制台上。再接着看SSH和Snare的日志。

#/usr/share/ossim/scripts/regexp.py /etc/ossim/agent/plugins/ssh.cfg /var/log/auth.log q

图17 SSH匹配结果

又例如：

#/usr/share/ossim/scripts/regexp.py /var/log/snare2.log /etc/ossim/agent/plugins/landesk.cfg q

Multiple regexp mode used, parsing /etc/ossim/agent/plugins/landesk.cfg

-----------------------------------------------------------------------------

Rule: Landesk-sync-job-successed

Matched 273 times

Counted 274 lines.

Matched 273 lines.

了解OSSIM的其他插件

九、 代理与插件的区别

初学者常混淆代理和插件的概念，Sensor（传感器）指软件和硬件的传感器被安装在网络中收集和发送数据，而代理是运行在传感器上，用来收集和发送数据到服务器的一段脚本，一个插件需要了解特定系统的日志格式（例如防火墙、IDS），并通过插件来采集数据。

系统中如果启用插件越多，那么采集到网络中各种数据就越全面，在Sensor中加载过多的插件，将会占有OSSIM Server的数据库空间，下面的这条经验值需要读者了解，OSSIM系统中每条事件，约占用1KB存储空间，而1millions的事件量，大约占1.5GB空间。

十、 传感器（Sensor）

传感器（Sensor）俗称探针，用来收集监控网段内主机的信息，它工作在网卡的嗅探模式。OSSIM系统中，把Agent和插件构成的一个具有网络行为监控功能的组合称为一个传感器，Sensor的功能范围主要有：

l l 入侵检测(最新版已换成支持多线程的Suricata)

l l 漏洞扫描(OpenVas、Nmap)

l l 异常检测(P0f、Prads、ARPWatch等)

Arpwatch主要监视网络中新出现的MAC地址，它包含1个监视库，名为arp.dat，在OSSIM中位于/var/lib/arpwatch/arp.dat，所以它同样是AIDE监控的对象。

OSSIM具有强大的网络威胁监控，流量监测的功能，但无法将威胁阻断，所以不能将其串联在防火墙链路，最佳方法是作为旁路链接使用,这一点就像部署审计设备一样。

在OSSIM系统的传感器的状态可在Configuration→Deployment→Components→Sensors中查看详情，如图18所示。

图18 多传感器详情

在OSSIM分布式应用中有多个传感器，这时在图182中可以查看每个传感器的工作状态，包括IP地址、名称、优先级、工作状态等信息。

OSSIM系统发展到4.3版本之后，传感器查询方式发生了变化，路径为Configuration→Deployment→Alienvault Center→Sensor Configuration→Detection，而且启动程序也发生些的变化，由Suritata代替了Snort，如图1-23所示。OSSIM Server默认就启动ntop、ossec、prads、suricata这4项，Snort为停止状态。这5个检测器的状态无法通过Web界面直接进行修改。

图19 传感器详情

大家如果使用OSSIM4.1系统，查看系统检测插件时，Snort为启动状态，但OSSIM 4.2后的系统Snort是关闭状态，代替它的是性能更强大的Suricata系统，同一个系统中两者只能任选其一。而Prads（Passive RealTime Asset Detection System）是OSSIM 4.2之后又一款被动实时资产探测系统，它的主要功能就是被判断资产特征，如同一个指纹库，保存了各种系统特征，可以识别资产的操作系统类型、由ARP发现新增资产，根据开放端口判断打开的网络应用，因为各种设备和服务打开状态并不是一成不变，所以需要用Prads来监控变化后的状态，有关它的实际应用参考 http://chenguang.blog.51cto.com/350944/1703458

十一、关联引擎

关联引擎（Server）是OSSIM安全集成管理系统的核心部分，它支持分布式运行，负责将Agents传送来的归一化安全事件进行关联，并对网络资产进行风险评估。其工作流程见图1-24所示。

图20 关联引擎的工作流程

OSSIM服务器的核心组件功能包含：事件关联、风险评估和确定优先次序和身份管理、报警和调度、策略管理、IP信誉管理等，其配置文件在/etc/ossim/server目录中，文件分别为：

l alienvault-attacks.xml

l alienvault-bruteforce.xml

l alienvault-dos.xml

l alienvault-malware.xml

l alienvault-network.xml

l alienvault-scan.xml

l alienvault-policy.xml

以上这些文件由开源OSSIM免费提供，策略为84条，在USM中则具有2千多条，这一数量远高于国内的IDS硬件设备，在OSSIM中它们采用XML编写易于理解，维护简单。

图21 关联引擎的结构

关联引擎结构如图21所示，其工作过程由下面6个步骤组成：

40001/tcp:Server首先监听 40001/tcp 端口，接收Agent 连接和Framework请求。该端口大小由OSSIM系统在配置文件/etc/ossim/ossim_setup.conf中定义。

我们在OSSIM系统中通过以下命令可以清晰查看到其工作端口。

#lsof –Pnl +M –i4 |grep ossim-ser

Connect:当连接到端口为40002指定的Agent时，连接到端口为40001的其他Server 对采集事件进行分配和传递。该端口大小在/etc/ossim/agent/config.cfg文件的[output-idm]项配置，不建议更改。

Listener:接收各个Agent的连接数据，并细分为Forwarding Server连接、Framework连接。

DB Connect:主要是OSSIM DB连接、Snort DB连接和OSSEC DB连接

Agent Connect:启动Agent连接，Forwarding Server连接。

Engine:事件的授权、关联、分类。

在OSSIM系统关联引擎的状态可在Configuration→Deployment→Components→Servers中查看，如图22所示。

图22 关联引擎模块工作状态

关联引擎启动

OSSIM系统会启动关联引擎，有时系统调试也需要用到手工启动方式，命令如下：

#ossim-server -d -c /etc/ossim/server/config.xml

OSSIM-Message: Entering daemon mode...

关联引擎+关联规则能发挥多大作用，大家参考 http://chenguang.blog.51cto.com/350944/1728514

查看Ossim Server版本

#ossim-server -v

Alienvault OSSIM Server Version : 5.1.1.free.commit:(1:5.1.1-31)(c) 2007-2013 AlienVault

十二、 数据库

Ossim关联引擎（简称OSSIM Server）将事件关联结果写入数据库。系统用户可通过Framework(Web前端控制台)对Database进行访问。数据库中alienvault.event表是整个系统事件分析和策略调整的信息源。OSSIM从总体上将其划分为事件数据库(EDB)、知识数据库(KDB)、用户数据库(UDB)。OSSIM数据库用来记录与安全事件关联及配置等相关的信息，对应于设计阶段的KDB和EDB的关联事件部分；在Framework中使用ACID/BASE来作为Snort数据库的前端控制台，对应于设计阶段的EDB。此外ACL数据库相关表格可包含在OSSIM数据库中，用来记录用户行为，对应于设计阶段的UDB库。

Ossim数据库分关系型数据库和非关系型数据库。OSSIM系统默认使用的MySQL监听端口是3306，为增其其处理性能，在Alienvault USM中采用MongoDB作为非关系型数据库。2013年将OSSIM 4.2发行版中用Percona_server5.5替换了原来的MySQL 5.1，由于使用了XtraDB存储引擎，而且对MySQL进行了优化和改进，使其在功能和性能上明显提升。在2015年底的最新版本USM 5.2中将Percona_server升级为功能强大的5.6.25。

表3 OSSIM 主要版本数据库变迁

如果大家对OSSIM的架构和组成的了解还意犹未尽，敬请参阅由清华大学出版的《开源安全运维平台OSSIM最佳实践》一书。