英语原文共 15 页，剩余内容已隐藏，支付完成后下载完整资料

针对高速网络的面向流的网络流量捕获与分析

Antonis Papadogiannakis, Michalis Polychronakis, and Evangelos P. Markatos

摘要：入侵检测、流量分类以及其他网络监控应用需要通过分析在网络层以下被捕获的流量，允许面向连接的分析和实现针对基于TCP报文段的逃避企图的弹性。现有的网络流量捕获框架，为应用程序提供原始的数据包，为开发者留下比如流追踪、TCP流重组等复杂操作。在应用程序所需与系统所提供之间的距离，导致了应用程序的复杂性、更长的开发时间，最重要的是，由于在包捕获子系统与流处理模块之间过多的数据复制降低了性能。本文提出了流捕获库（Scap），一个构建于底层的网络监控框架，用于面向流的流量处理。基于直接处理流追踪与TCP流重组的内核模块，Scap通过最小化数据移动操作、在早期丢弃不感兴趣的数据包，将流量层的统计信息与重组的流交付给用户层应用程序，流捕获库原生支持多核架构上的并行处理，并且使用现代网卡的高级功能。我们的实验评估表明流捕获库能以比其他流重组库高2倍的流量速率捕获所有的流。最后，我们展示基于流捕获库的四个流行网络流量监控应用的实现与性能评估。

关键词：流量监控 流重组 包捕获 包过滤 过载控制 性能

引言

被动网络监控是增加安全性和理解现代网络性能不可或缺的机制。例如，网络层入侵检测系统（NIDS）通过检测网络流量来检测攻击[1][2]和确定被侵入的计算机[3][4]，类似的，流量分类工具通过检查网络流量来识别不同的通信模式和潜在的非法流量[5][6]。为作出有效的决定，这些监控应用需要分析传输层及以上的网络流量。比如，NIDS通过重组传输层流来检测跨越多个包的攻击向量并避免逃避攻击[7]-[10]。

不过，在监控应用与底层的流量捕获工具之间存在一定距离：应用程序日益需要确定更高层的实体和比如TCP流，HTTP头部，SQL参数，邮件消息等结构，但流量捕获框架依然在尽可能最底层进行操作：它们提供原始的——可能是重复、乱序或者重叠——某些情况甚至是不相关的包给监控接口[11]-[13]。一旦在用户空间收到捕获的包，监控应用通常使用已存在的库[14]或者自定义流重组引擎[1][2]进行TCP流重组。这导致了因提取TCP报文段有效载荷和将它们合并为成块的连续内存而造成额外的内存复制操作。另外，这减少了优化机会，比如早期在消耗系统资源将它们移动到用户层前丢弃不感兴趣的包，为传输层流设定不同的优先级使得能在更低的系统层次上处理它们。

为跨越这一距离并解决上述问题，我们提出了流捕获库（Scap）：一个统一的被动网络监控框架，围绕流的抽象而构建，流是用户应用处理的首要目标。最开始就设计为面向流的网络监控，Scap(i)提供网络监控应用需要的高级功能，(ii)在最合适的地方，比如用户层、内核层，甚至网络接口卡，实现这些功能。另一方面，由于设计原因，现有的TCP流重组的实现受限于用户层的操作，因此剥夺了丰富的高效实现选择。

为实现积极的优化，我们引入流捕获的概念：也就是说，我们将流提升为Scap捕获以及用户应用处理的首要目标。尽管以前的工作将TCP流重组视为一个必要的弊病，通常用于避免针对入侵检测等监控系统的逃避攻击，但我们将流而不是包视为导出到网络监控应用的基本抽象概念，并且将流作为监控系统的正确媒介，深入到操作系统内核和网卡实现积极优化。

为减少不必要的数据包的负载，Scap引入“subzero包复制”的概念。零复制方法避免了从一端的主存到另一端时数据包的复制，在该方法的启发下，Scap不仅避免了冗余的包复制，也一开始就避免了在主存中传入数据包，我们展示了几种只是简单地对某些数据包不感兴趣的应用，比如大流量的尾端[16]-[20]。“subzero包复制”识别这些数据包，并且根本不将它们传入主存：这些数据包在到达主存前就会被网卡（NIC）丢弃。

为解决重负载，Scap引入优先级包丢失（PPL）的概念。在重负载下，传统的监控系统通常随机地丢弃到达的数据包，严重影响任何接下来的流重组过程。但这些被丢弃的包和受影响的流可能对监控应用来说是重要的，因为它们可能包含一次攻击或者其他关键信息。即使经过仔细配置有能力处理满载线路速率流量的系统也能过载，例如，一个有经验的攻击者发送对抗流量，利用一个算法上复杂的漏洞故意使系统过载[21][22]。Scap允许应用(i)为不同的流定义不同的优先级(ii)配置阈值机制，给新的和小的流更高优先级，而不是长期运行数据传输的重尾。

Scap提供灵活的易于表达的应用编程接口（API），允许程序员全面配置流捕获过程，为每个流执行复杂处理，用少量几行代码收集每个流的统计信息。我们的设计引入两个新特性：(i)使早期丢弃不感兴趣的流量，比如属于大文件传输的长期连接的尾端，成为可能，，(ii)它通过流优先级和尽可能地重组为容忍高负载下的丢包提供了更多的控制。Scap也通过将TCP报文段放到流特定内存区域的最佳位置避免额外的内存复制的开销，通过接收方缩放[23]支持透明并行化的多核系统和网络适配器。

我们在10GbE网络中用真实的流量评估了Scap，结果表明它比现有的备选方案比如Libnids[14]和Snort的流重组[1]表现更佳。我们的结果表明，Scap可以以一个单核CPU较低的利用率在用户层捕获并交付所有的流，速率最高可达5.5Gb/s，而Libnids和Snort在2.5Gb/s开始丢包，原因是用户层流重组导致的高CPU利用率。Scap更详细的评估可以在我们先前的工作找到[24]。

我们在Scap之上实现了四个流行的的网络监控应用：(i)流导出，(ii)NIDS签名匹配，(iii)应用层流量分类，(iv)HTTP协议解析与分析。所有的这些应用都需要流追踪，大多数需要准确的流重组和协议规范化。因此，它们可以从Scap提供的特性与性能优化中显著受益。我们详解介绍这些使用了Scap的应用的实现与性能特性。

总之，本文的主要贡献是：

• 我们确定一个语义上的距离：现代网络监控应用需要工作在传输层及以上，然而现有的监控系统工作在网络层。为跨越这个距离并实现积极优化，我们引入了基于流的基本抽象的流捕获的概念。
• 我们引入“subzero包复制”这样一种技术，结合了商用网卡过滤能力的优点，不仅避免不感兴趣的包在不同内存区域的复制，而且避免了将它们全部带入主存。
• 我们引入了“优先级包丢失”技术，通过丢弃低优先级流的包以优雅地适应过载条件，优先考虑属于最近的更短的流的数据包。
• 我们描述Scap的设计与实现，Scap是一个在内核级、多核感知子系统中包含上述特性的框架，为构建面向流的网络监控应用提供了灵活的易于表达的API。
• 我们实验性地评估Scap并表明它以比之前方法高2倍的流量速率捕获并交付传输层流。
• 我们展示现实世界使用Scap的四个网络监控应用的实现与评估。

本文的剩余部分组织如下：第二节我们展现Scap的设计与基本特性，第三节我们概述主要的Scap API调用，第四节描述Scap的高层架构，第五节讨论实现细节，第六节我们实验性评估Scap的性能，重放在自然条件下捕获的真实网络流量，与现有的库进行比较。第七节我们展示四个现实世界使用Scap框架的网络流量分析应用的实现与性能。最后，第八节总结相关工作，第九节总结本文。

设计与特性

“Subzero复制数据包”传输

几种网络监控应用[16]-[20]只需要分析每个连接的起始字节，尤其是在高速流量负载下。通过这种方式，它们为每个流分析对它们更有用的部分，丢弃占总流量百分比显著的部分[17]。对于这种应用程序，Scap包含截断阈值的使用，它把流截断为用户指定小大，在操作系统内核甚至网卡中丢弃流（和相应数据包）的剩余部分，避免不需要的数据传输到用户空间。应用程序可以动态调整每个流的截断大小，获得更多的灵活性。

除一个流的截断大小外，监控应用可能需要高效地丢弃其他不太感兴趣的流量类型。许多应用程序经常使用BPF过滤器[12]定义它们想处理的流，并丢弃剩下的部分。为防止发生过载，应用程序可能想丢弃低优先级的流或者定义一个流过载截断[18][19]。另外，取决于应用程序，未建立的TCP连接的数据包或者重复的数据包也可能被丢弃。在所有这些情况下，Scap可以在早期从内核中丢弃合适的包，甚至许多情况下可以更早地在网卡中丢弃。

为达到这点，Scap利用直接在硬件中提供过滤设备的现代网络接口。例如，Intel的82599 10G接口支持最高8K的完美匹配和32K签名（基于hash）的流导向过滤器（FDIR）。这些过滤器可以在10毫秒内动态添加或删除，可以匹配一个包的源IP地址与目的IP地址、源端口与目的端口、协议、在数据包起始64字节中的任何2字节元组。FDIR过滤器匹配的数据包被定向至过滤器指定的硬件队列中。如果系统还没有使用这个硬件队列，数据包会被网卡层丢弃，永远不会被复制到系统主存中[26]。当可用时，Scap使用FDIR过滤器实现以上类型的早期包丢弃，除此以外数据包在操作系统内核中丢弃。

优先级包丢失

Scap引入“优先级包丢失（PPL）”使系统在过载时有效利用其资源。这是很有必要的，因为突发流量或过载条件会迫使包捕获子系统用完缓冲区并开始随意丢包。更坏的是，当攻击者正在进行攻击时，他可能会故意使监控系统过载以逃避攻击。先前的研究已经表明能以不同的方式处理不同的流[21][27][28]，或者每个流的不同部分[18][19]，使系统更有效地利用它的资源并显著提升检测准确度。PPL能使用户应用定义每个流的优先级，于是过载条件下，来自低优先级的数据包首先被处理。用户应用也可以定义过载条件下的最大流大小的阈值（overload_cutoff），超过该阈值的包会被丢弃。

只要内存使用率低于用户定义的阈值（base_threshold），PPL不丢弃数据包。然而，当使用内存超过base_threshold，PPL开始运行：首先使用n 1个等间距水印（如watermark₀, watermark₁, hellip;, watermark_n），将高于base_threshold的内存划分为n（等于使用的优先级大小）个区域，其中watermark₀=base_threshold且watermark_n=memory_size。当一个优先级为i_th的流的数据包到达时，PPL检查此时Scap使用的内存百分比。如果超过watermark_i，包被丢弃。否则，如果内存使用率在watermark_i与watermark_i-1之间，PPL使用overload_cutoff（如果已被定义），然后，如果包位于流的overload_cutoff字节之后，丢弃数据包。这样，会以更高概率容纳高优先级、新创建的、短的流。

灵活流重组

为支持传输层监控，Scap提供不同的TCP流重组模式。Scap流重组中的两个主要目标是：(i)在连续内存区域中提供传输层的重组块 (ii)执行协议规范化[8][29]。当前Scap支持两种TCP流重组模式：SACP_TCP_STRICT和SCAP_TCP_FAST。在严格模式中，根据现有准则重组流[7][29]，提供防止基于IP/TCP分片的逃避企图。在快速模式中，尽可能地重组流，弹性针对过载情况下的包丢失。在这个模式中，Scap通过处理TCP重传、乱序分组、重叠报文段等方式尽可能遵循严格模式的语义。为容纳丢失报文段，无需等待下一个正确的序列号到达就写入流数据，在这种情况下，Scap设置一个标志以报告在重组中发生了错误。

此外，Scap支持不同的重组策略，例如，根据不同的操作系统，Scap应用可以为每个流设定不同的重组策略。这是出于之前的工作，这些工作表明由于不同TCP实现的差异，比如处理重叠报文段的不同，NIDS中重构的数据流可能不同于目的地实际观察到的数据流。攻击者可能利用这种差异躲避检测[9]。

Scap也支持UDP：一个UDP流（stream）是给定UPD流（flow）的包的有效载荷的串联。对于其他不使用序列传送的协议，Scap不进行任何重组直接返回每个包。

并行处理与局部性

Scap原生支持多核系统，为程序员隐藏了创建和管理多进程或多线程的复杂性。通过透明地为用户层流处理（通常情况）创建数目与可用内核相等的工作线程来达到这一点。Scap也为处理包接收和流重组，在每个内核上提供一个核心线程。每个流分配一对核心线程和工作线程，这对线程运行在同一内核中以减少上下文切换、缓存未命中[30][31]和线程间同步操作。每个内核的核心线程与工作线程通过共享内存和事件通信：核心线程为流创建新事件，工作线程使用用户为流处理定义的回调函数处理该事件。

为平衡多个网卡队列和内核中的网络流量负载，Scap使用例如接收方缩放（RSS）[23]的基于hash的静态方法，和例如流导向过滤器（FDIR）[25]的动态负载平衡方法这两种方法。这提供了对降低应用性能的短期负载不平衡的弹性对抗。

性能优化

在同一主机上运行多个应用监控相同流量的情况下，Scap为每个应用提供了每个流的一个共享副本。因此，流重组只在内核中执行一次，而不是多次在每个用户层应用中重组。如果应用有不同的配置，如：流大小截断或者BPF过滤器，Scap尽可能地满足所有的需求。

依据缓存的局部性，在内核中执行流重组提供了显著的优点。现有的用户层TCP流重组的实现接收高度交错的不同流的包，造成较差的缓存局部性[32]。相反，Scap为用户层应用提供已重组的流，而不是随机交错的数据包，从而提高内存局部性

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[141470]，资料为PDF文档或Word文档，PDF文档可免费转换为Word