1 Zeek基本介绍

1.1 Overview

Zeek又名Bro，是一个被动的开源网络流量分析器。它主要是一种安全监视器，可深入检查链接上的所有流量以查找可疑活动的迹象。在安全领域以外，Zeek还能够进行性能测量，故障检测等工作。

1995年劳伦斯伯克利实验室的研究员Vern开始了Bro的开发，并于1996年在实验室进行内部部署，1998年在USENIX安全研讨会进行发表。2003年，美国国家科学基金会（NSF）开始在国际计算机科学研究所（ICSI）上支持Bro的研究和高级开发。2010年NSF通过向ICSI授予SDCI计划中专门用于Bro开发的赠款，美国国家超级计算应用中心（NCSA）作为该团队的核心合作伙伴加入了该计划。现如今Bro团队现在正在努力通过进一步提高系统功能来应对未来网络的挑战，以此取得成功。

1.2 Architecture

由上图可知Zeek的体系结构主要分为两个部分：

事件引擎：Event Engine 将传入的数据包流减少为一系列更高级别的events。这些事件以与策略无关的术语反映了网络活动，它描述已看到的内容，但不对现象进行解释或分析。例如它能将线路上的HTTP request都转化为一个相应的http_request事件，该事件包含了请求的IP，端口和URL以及http version等信息。但是Event Engine不会对此事件进一步解读，如该URL是否对应于已知的恶意站点。
策略脚本解释器：上例中的事件语义解析将由Zeek的第二个主要组件Policy Script Interpreter派生。该脚本解释器执行一组Zeek自定义脚本语言编写的事件处理程序来对事件进行语义分析。例如一个站点的安全策略将包括监测器检测到不同活动时应该做出的响应等。最重要的是，Zeek允许其脚本随着时间推移而保持工作状态，从而使它们能够跟踪并关联跨连接和主机边界观察到的内容的演变。Bro脚本可以生成实时警报，还可以按需执行任意外部程序，例如触发对攻击的主动响应。

1.3 Features

Zeek支持很多基于其脚本的分析，并且即便是不采用自定义脚本，它也能具备以下强大的功能特性：

Deployment
- 在标准Unix-Style的商用硬件上运行
- 能对来自网络分接头或者监测端口的流量进行完全被动的流量分析
- 用于捕获数据包的标准libpcap接口
- 实时和离线分析
- 对于大规模部署支持集群化，且无论是独立还是集群都采用统一的管理框架
- BSD许可下开源
Analysis
- 全面记录活动，以进行离线分析和取证
- 独立与应用层协议的端口分析
- 支持许多应用程序层协议（包括DNS，FTP，HTTP，IRC，SMTP，SSH，SSL）
- 分析通过应用层协议交换的文件内容，包括用于指纹识别的MD5 / SHA1计算
- 全面的IPv6支持
- 隧道检测和分析（包括Ayiya，Teredo，GTPv1）。Zeek将隧道解封装，然后继续分析其内容，就像没有隧道一样
- 在协议分析过程中进行全面的健全性检查
- 支持IDS样式的模式匹配
Scripting Language
- 图灵完备的语言，用于表达任意分析任务
- 基于事件的编程模型
- 特定于域的数据类型，例如IP地址（透明地处理IPv4和IPv6），端口号和计时器
- 支持基于时间的跟踪和管理网络状态
Interfacing
- 默认输出到格式良好的ACSII日志
- ElasticSearch和DataSeries的备用后端，并将后续支持其它数据接口
- 外部输入实时集成到分析中，并将后续支持实时数据库的输入
- 外部的C库用于与外部程序交换Zeek的事件，同样支持与Perl，Python和Ruby的绑定
- 能够从脚本语言内部触发任意外部进程

2 Zeek集群架构

为什么Zeek需要集群架构？因为Zeek是是单线程的，因此一旦达到单个处理器内核的限制，当前唯一的方法就是把工作负载分散到多个内核甚至是多个物理机上。

2.1 Cluster Architecture

上图是Zeek的集群架构示意图

Tap是一种机制用来拆分数据流并创建副本用于检测。例如交换机上的监测端口和光纤网络上的分光路器。
Frontend是一种离散的硬件设备或主机技术，可将流量分为许多流。Zeek的二进制文件并不执行此工作。
Manager是一个Zeek的进程，具有两个主要任务。第一个是从集群的其他采用Zeek通信协议的节点接收日志和通知（如果你用的是logger则会取代manager来接收所有的日志）它的输出结果是一个单独的日志而不是许多需要被后期处理组合的离散的日志。第二个任务是它能够作为通知的阻塞节点来进行重复数据删除操作和通知行为化操作（如将通知以邮件形式发送，分页或者阻止）。
Logger是一个可选的Zeek进程，它使用Zeek通信协议从群集的其余节点接收日志消息。让logger代替manager接收日志的目的是为了减轻manager的负担。
Proxy是一个用于同步状态的Zeek进程，变量能够自动地在连接的Zeek进程间同步。proxy避免了所有worker都相互直连。
Worker是嗅探网络流量并对重新组合的流量进行协议分析的Zeek进程。由于一个集群的所有协议解析和大多数分析都将在此处进行，因此建议采用尽可能高性能的内存和CPU。因为几乎所有日志记录都是在远程对manager完成的，并且通常很少写入磁盘，因此workers对磁盘没有特殊要求。

2.2 Frontend Options

2.2.1 分立的硬件流量平衡器

cPacket：如果要监视一个或多个10G物理接口，建议的解决方案是使用cPacket的cFlow或cVu设备，这些设备将通过重写目标以太网MAC地址以使与特定流关联的每个数据包具有相同的目标MAC，来执行第2层负载平衡。然后可以将数据包直接传递到监视主机，在监视主机上，每个worker都有一个BPF Filter以将其可见性限制为仅该流，或者继续传递到商用交换机，以将流量拆分为多个以适配worker的1G接口。从而大大降低成本。
OpenFlow Switches：基于OpenFlow的交换机直接在交换机上进行基于流的负载平衡，从而大大降低了许多用户的前端成本。官方正在探索中…

2.2.2 主机流量平衡机制

**PF_RING： **Linux的PF_RING软件具有“群集”功能，该功能将在嗅探同一接口的多个进程之间进行基于流的负载平衡。这使您可以轻松地在单个物理主机中利用多个内核，因为Bro的主事件循环是单线程的，因此无法本机利用所有内核。如果要使用PF_RING，请参阅有关如何使用PF_RING配置Zeek的文档。
Netmap： FreeBSD有一个正在进行的名为Netmap的项目，该项目还将启用基于流的负载平衡。官方正在探索中…
Software Router： 可以通过简单的配置用于基于流的负载平衡。由于Zeek的PF_RING支持，因此不建议在Linux上使用此解决方案，并且仅将其作为其他操作系统上的不得已的方法，因为该解决方案会因每个数据包在内核和用户域之间来回上下文切换数次而导致大量开销。