OSSIM架构与组成综述

一、背景

如果运维工程师手中没有高效的运维监控工具，就很难快速处理网络故障。市面上有很多运维监控工具，例如商业版的Solarwinds，OpManager、开放源码的 MRTG、Nagios、 Cacti、 Zabbix、 OpenNMS、 Ganglia等。但它们之间产生的数据不相关联，不能共享，所以即使部署了这些工具，许多操作人员也没有真正地从中解脱，成千上万条警告信息聚集在一起，很难找出问题的根源。
此外，在传统的运维环境中，在查看各种监控系统时需要多次登录，查看界面繁多，更新管理的大部分工作大多是手工操作，即使是简单的系统更改，也需要运维人员逐个登录系统，如果遇到问题，管理员就会在各种平台之间来回查询，或者用人工查找故障关键词，不断重复这种工作方式。
一个被称为 OSSIM，即开放源代码信息管理系统（Open Source Security Information Management）的优秀开放源代码平台，企业需要一个能够满足专业化、标准化和流程化需求的综合安全的运维平台，以便在关联分析的基础上及时发现故障隐患。
OSSIM系统从架构上来说是一个开放的框架，其核心价值在于能够创新地集成各种开源软件，其中的模块包括 C/S架构和 B/S架构，但是作为终端用户，主要掌握 OSSIM WebUI采用的是 B/S架构，而 Web服务器则使用 Apache。图1显示了 OSSIM系统的结构示意图。

图1 OSSIM系统结构

架构说明

第1层，属于数据采集层

采用不同的采集技术来收集流量信息、日志信息、各种资产信息，经过归一化处理后将其传递到核心层。
该层包含了安全事件源，入侵检测、防火墙、重要主机发送的日志等都是安全事件源，按照发送机制可分为两类：模式侦查器和异常监视（两者都收集警告信息，具有互补功能）安全事件由其收集，然后再由代理转换成统一格式发送给 OSSIM服务器， Sensor将在该层中完成工作。

第2层，属于核心处理层

主要实现了对各种数据的深加工处理，包括操作监控，安全分析，策略管理，风险评估，关联分析，安全目标管理，漏洞管理，事件管理，报表管理等。OSSIM服务器是这一层的主角， OSSIM服务器的主要功能是安全事件的集中和集中后的事件的关联分析、风险评估和严重程度的标注等。
“集中”就是把所有系统生成的安全事件告警信息（Alarms）以一种统一的格式组织起来，并将所有网络安全事件的告警信息存储到数据库中，这样就完成了对网络中生成事件的一个大视图。利用事件序列关联和启发式算法关联，系统能够更好地识别误报和发现攻击。
从本质上讲， OSSIM是通过对不同类型检测器和监视器产生的报警进行格式化处理，然后进行关联分析，通过后期这些处理可以改善探测性能，既减少了报警次数，又降低了关联引擎的压力，从整体上提高了报警质量。

第3层，属于数据显示层

主要负责完成与用户的交互，达到安全预警和事件监控，安全运行监控，综合分析的统一显示，形式上以图形的方式呈现给用户。
控制台界面即 OSSIM （Web User Interface， Web用户界面），实际上是 OSSIM系统外部的门户网站，它主要由仪表盘、 SIEM控制台、 Alarm控制台、资产漏洞扫描管理、可靠性监控、报告和系统策略等几部分组成。OSSIM传感器的部署和IDS传感器类似，在网络中的部署如下图所示：

二、主要模块关系

OSSIM系统主要使用 PHP、 Python、 Perl和 C四种编程语言， OSSIM框架系统在软件层面由五大模块组成：代理模块、服务器模块、数据库模块、 Frameworkd模块和 Framework模块，组成结构图见2：

图2 Ossim系统组成
OSSIM主要功能模块与通信端口：

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

图3. 5大模块的数据流向

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所示：

当这些插件加载完毕之后，我们可以到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：

图8 查看传感器启用的插件情况
从图中看出，此Sensor系统中启用了6个插件，如何在Web上展示出来呢？如图所示总共531个插件在Plugins enabled中启用了6个插件：

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

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

五、检测器（Detector）

在 OSSIM下的检测器可以收集资源信息和监听当前网段中的包，其中主要包括 ntop， prads， suricata， ossec等，后续章节将详细介绍有关内容。

六、代理（Agent）

Agent （因为 Agent是用 Python语言编写的，因此可以在 Python Shell环境中运行而不需要编译）将运行在多个主机上，负责从安全设备收集相关信息（如报警日志等），并将所收集的各种类型的信息进行统一的格式处理，最终将数据传送给服务器。
就收集方式而言， Agent属于主动收集，可以将图像理解为 OSSIM Server插入各个监控网段的“耳边”，由它们收集数据，并主动推送到 Collector， Collector再与消息队列系统、缓存系统和存储系统相连。
在 OSSIM中，这些代理脚本位于/usr/share/alienvault/ossim-agent/目录下，并且在. pyo中对其进行了加密：

举例来说， OSSIM代理（ossim-agent）直接读取存储在/var/log/suricata/unified2.al ert.1428975051日号文件中的数据。
Suricata的警报输出文件是/var/log/suricata/unified2.alert，它由/etc/suricata/suricata. yaml配置文件在第111行# alert output for use withBarnyard2中定义，因此可以在 SIEM控制台上显示ossim-agent直接读取该文件。
Agent的主要功能是接收或抓取由 Plugins发送或生成的日志，这些日志经过归一化处理，然后有序地传输到 OSSIM的服务器上，由于 Agent设计时考虑到了 Agent和服务器之间的网络中断、阻塞、丢包等情况，所以其功能非常复杂。
OSSIM系统的免费版本在大多数情况下不能实现实时日志处理，但是可以实现准实时（FirmReal-Time），并且通常需要在 Agent端进行缓存，才能将数据发送到服务器端。代理将主动连接两个端口与外部通信，其中一个端口连接服务器的40001端口（在/etc/ossim/agent/config.cf g配置文件的选项[output-server]中可以看到通讯端口为40001），另一个端口连接数据库的3306端口。在图11中可以看到：

图11 日志归一化处理、收集与存储
原始日志被分成若干段填充到相应的域中，这些字段如下：

date、sensor、interface、plugin_id、plugin_sid、priority、protocol、src_ip、src_port、dst_ip、dst_port、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结构

• 40002/tcp： 监听服务器的原始请求。
• Listener： 接收服务器连接请求。
• Active： 接收服务器输入并且根据请求扫描主机。
• Engine： 管理线程，处理监视器请求。
• Detector Plugin：读取日志和进行归一化处理。
• Monitor Plugin：请求监视器数据。
• DB-Connect： 连接到本地/远程OSSIM数据库。
• Watchdog： 监视进程启动/停止进程，检查各插件是否已经开始运行。

如遇意外，它会发现并重启相关进程，它自动检查时间为180秒，重启进程时间为3600秒，其值可以在/etc/ossim/agent/config.cfg配置文件中修改。
注意：OSSIM系统中出了引入HIDS（通过OSSEC实现），还引入了NIDS（通过suricata实现），因为基于主机的入侵检测系统还无法完全满足网络安全需要，NIDS可以捕捉和分析网络数据包也分析协议。NIDS可以部署在各个网段，只对监控网段进行监听，不会影响网络的运行。但做为Sensor也有缺点，如果网络流量一旦超过阈值，就会导致丢包。
提示：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

• y:显示不匹配的行 v: 显示匹配的行
• 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系统中每个事件占用大约1 KB的存储空间，而1 millions占用大约1.5 GB的存储空间。

十、传感器（Sensor）

传感器（Sensor）俗称探针，用来收集监控网段内主机的信息，它工作在网卡的嗅探模式。
传感器工作在一台Debian Linux主机上，通过ISO镜像安装，对于新手来讲非常容易操作，他的目的是收集信息，发送给OSSIM Server。在一个分布式OSSIM系统平台上，可以有十多个传感器协同工作。
传感器可以收集来自多个数据源的数据包，包括来自主机的，也包括来自网络的数据包，另外传感器除了收集数据（比如SPAN，Agent）以提供分析之外，还具有过滤功能可以通过Agent里面的plugin实现过滤冗余和无效数据的功能，已达到减少OSSIM Server端数据量，提高数据速度的效果。举个例子在对于来自同一个IP地址的数据，传感器可以通过模式匹配的方法来判断冗余数据，最终聚合成很少量的数据传送给OSSIM Server。
此外，传感器还可以与本地代理（如 Ossecagent， Snare），事件收发器通信，但传感器之间没有直接通信。
OSSIM系统中，把Agent和插件构成的一个具有网络行为监控功能的组合称为一个传感器，Sensor的功能范围主要有：

• 入侵检测（最新版已换成支持多线程的Suricata）
• 漏洞扫描（OpenVas、Nmap）
• 异常检测（P0f、Prads、ARPWatch等）

Arpwatch主要监视网络中新出现的MAC地址，它包含1个监视库，名为arp.dat，在OSSIM中位于/var/lib/arpwatch/arp.dat，所以它同样是AIDE监控的对象。
提示：
OSSIM具有强大的网络威胁监控，流量监测的功能，但无法将威胁阻断，所以不能将其串联在防火墙链路，最佳方法是作为旁路链接使用，这一点就像部署审计设备一样。
在OSSIM系统的传感器的状态可在Configuration→Deployment→Components→Sensors中查看详情，如图18所示：

图18 多传感器
查询Server/Sensor使用操作系统版本号：

#cat /etc/debian_version

在OSSIM分布式应用中有多个传感器，这时在图182中可以查看每个传感器的工作状态，包括IP地址、名称、优先级、工作状态等信息。
OSSIM系统发展到4.3版本之后，传感器查询方式发生了变化，路径为Configuration→Deployment→Alienvault Center→Sensor Configuration→Detection，而且启动程序也发生些的变化，由Suritata代替了Snort。OSSIM Server默认就启动Alienvautl HIDS Alienvault NIDS prads。这3个检测器的状态无法通过Web界面直接进行修改：

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

十一、关联引擎

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

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

• alienvault-attacks.xml
• alienvault-bruteforce.xml
• alienvault-dos.xml
• alienvault-malware.xml
• alienvault-network.xml
• alienvault-scan.xml
• alienvault-policy.xml

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

关联引擎结构如图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中查看。

关联引擎启动

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

#ossim-server -d -c /etc/ossim/server/config.xml
OSSIM-Message: Entering daemon mode...

十二、数据库

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进行了优化和改进，使其在功能和性能上明显提升。在2019年底的最新版本USM 5.7中将Percona_server升级为功能强大的5.7。如果大家对OSSIM的架构和组成的了解还意犹未尽，敬请参阅《开源安全运维平台OSSIM疑难解析》。