当前位置:首页最新动态官方新闻

网络全量数据包抓取,是时候有第二种选择发布时间:2021-06-18 18:03

 

 

1 传说中的全流量分析

大家都叫全流量分析产品,但其实只是输入的是全流量。我们按照数据包的分析要素和存储模式,可以把市面上全量数据分析探针分为三个层次:

1.1 部分协议检测,存储产生结果

以DPI、IDP、WAF等检测引擎为主的用法,对网络流量中的HTTP、DNS、SMTP/POP3/IMAP、FTP、SSH/Telnet、Netbios等重点协议和一些网络统计异常行为(如:各种类型扫描和DDoS)进行检测,并存储发现的异常告警和识别结果,对不触发告警和非关注协议的数据则不进行任何分析和存储。其中,DPI引擎略有区别,会关注所有会话开始部分的通信,但同样也只是存储部分协议元数据和识别结果。

1.2 部分协议检测,存储对应数据

深度内容审计产品、沙箱、APT类产品,均属于此类,对他们关注的协议(比如:HTTP、DNS、SMTP/POP3/IMAP、FTP、VOIP等)会基于数据包还原出原始内容并全部存储起来,供各种内容审计、语义分析、统计分析、人工智能识别和沙箱等运行分析,存储还原的内容和分析结果。有部分IDP类产品,也进行了自我进化,对检测出告警的会话,进行全量数据包存储,这类产品也可以归为此层次。

1.3 存储全部数据,部分检测结果

一个不漏地存储所有输入的数据包,为它们按照会话、应用、元数据等因素,编列各种不同维度的索引,以便进行后期的查询、分析、导出和流量重放工作。这类系统首先是一个巨大的数据包存储系统,衡量它的指标主要是网络采集性能、存储读写性能、数据包查询重组性能和稳定性等。同时这类系统也会内置部分文件还原、威胁情报匹配、攻击检测等,并存储检测结果,目前一般认为是附着在存储之上的附属品,非系统主要功能。

 

2 全流量抓取的技术争议

不论是网络安全还是网络性能研究领域,对上文提到的第三层次,即存储全部数据,部分检测结果的全流量分析,一直存在巨大的技术争议,由此衍生出两个不同的观点:

1)一方认为,有对应的各种检测引擎,对结果可存储与处置,即可满足用户的实际需求,当用户需要的时候增加引擎即可,并不存在进行7×24小时持续存储所有数据包的需求;

2)另一方则认为,引擎的限制是可预期的,持续性的数据包存储在网络回溯和未知威胁问题发现领域,是不可替代的。

其实,双方的说的都有道理,但是都不够全面。之所以会有这样的争议,是因为双方都预设了应用场景。前者是成熟应用的普通用户领域,强调高速简洁,比如互联网公司、中小企业、医疗、酒店、网吧、中小运营商等;而后者则是对未知威胁和网络性能问题更敏感的关键基础设施领域,比如国家政府、工业控制网络、金融、电力、电信基础设施等。

我们首先要承认,持续性的全流量存储,在溯源场景下的贡献是毋庸置疑的。这种持续性的全流量存储,基于从外界导入的查询需求,可以从存储数据中查询到相关时间点的IP地址、协议类型、通信规程和所有的原始数据包信息。这对于还原安全攻击或性能异常场景,定位根本问题起到定海神针的作用,是不可替代的。

除去这些积极因素之外,持续性的全流量存储分析目前也遇到了不少的技术挑战,通常有以下五个原因:

2.1 无分析价值数据多,部署成本高

全量数据包存储,注定是一场不对等的战斗。通常一台服务器要面对数千甚至上万倍于自己计算能力的终端产生的流量。终端产生的流量五花八门,即便是天马行空的分析模型,实际需要处理的应用类型也没那么多,而全流量存储系统则是不加区别的写入数据,保存大量无分析价值数据,例如安全分析场景保留大量P2P、音视频、图片等数据。在存储规模是固定值的情况下,有效回溯时间就会大大缩短,而这些无价值数据规模大,对分析的性能也造成极大影响。有很多已经部署的全量数据存储,积累了大量无用数据,成为深入分析的障碍。

2.2 网络未知威胁主动发现能力差

以人类对事物的认知边界来看,可以把网络流量分为已知和未知两种。基于全量数据包抓取后的定时间和定对象(比如:源地址、目的地址等)的溯源,并没有涉及到数据包认知本身,只是对其他知识体系(比如:威胁情报、APT检测等)的一种投射。快速积累的大量网络原始数据包,不加标识地躺在海量存储中,看似无所不能,实际产生不出任何主动的分析价值。在这些海量数据中,主动发现网络未知威胁从来都是这些全量数据包抓取系统建设的重要初衷,但往往建设到最后就只剩下溯源,忘了当初为什么而出发。不把已知协议和未知协议的处置规则梳理清楚,所谓网络未知威胁发现就是大海捞针,沙中作画。

从人对事物的认知习惯来梳理这个问题,并不难找到解决的思路,可以总结为两种方法:

已知中寻找异常

所谓大隐隐于市,异常的通信内容隐蔽伪装在常用协议中,是很多恶意应用的常用手段。如果能对已经识别的协议,根据协议、目标去向、域名、URL、DNS请求、用户身份、地理位置、UA等元数据,建立数据仓库,然后再根据它们的波动、差分、排序等统计规律寻找异常变化,最后对锁定的异常变化会话数据进行深度的原始数据分析,就可以找到很多问题的答案。

未知中排除正常

通常情况下,被识别引擎确定为未知的协议数据有三种:小众协议、已知协议数据的漏识别以及广泛使用的非正常协议。可以利用同目标其他识别结果的交叉校验,排除大量第二种情况,然后再结合交叉地理位置、使用频度等情况,剩余的1和3就会快速的浮出水面。1和3也分别是APT类未知威胁发现和黑产类未知威胁发现的重点分析目标。

以上的两类统计分析方法不止可以快速高效地寻找网络未知威胁的线索,也是对协议识别自身的校正反馈,相互促进。有很多技术研究者总是把精力过分地投入识别本身,把诸如人工智能等复杂数学算法引入到协议识别过程中,而忽略了更宏观的反馈,这也是他们工作经常只能POC(验证性测试)而不可实用的原因所在。协议识别这个基础都不扎实,网络未知威胁发现就是海市蜃楼。离开这些思维方法和协议识别工具的协助,单凭大量原始数据包,主动发现未知网络威胁将是一件不可能完成的任务。

2.3 离散全能力部署,难以统一数据分析

通常,要做好全流量分析的前提,是采集数据的点要足够多,尽可能地覆盖数据产生的每一个节点,比如一个大型局域网的核心、汇聚、接入节点,或是一个大型多分支网络的总部和分支节点,再或是一个云端的POP节点等。理想情况下这些节点都需要单独部署具备采集和存储能力一体的全流量采集的探针进行持续性的流量采集。

这种离散点部署的方式,在现网环境中也遇到了一些挑战,可将其总结如下两点:

探针成本问题

用户为了全流量采集而部署的探针设备必须具有存储的能力,换句话说就是探针在选配时,硬盘存储是必选项。当然,这类全流量探针如果部署的数量不够,对于用户来说也毫无意义。也正是这种原因,用户如果要实现全网全流量的持续采集,将面临高昂投入,出于成本的考虑,绝大部分用户只能放弃对远端节点的部署。因此也就出现了用户总部对数据的检测和分析能力过剩,而分支节点则不具备分析能力。

专线成本问题

当然,在全流量网络采集的建设过程中,用户不仅要面对探针成本问题,有时还会出现更加尴尬的局面,那就是投入了大量成本实现了所有离散的分支节点探针的部署,但是这些分支节点的数据向总部回传时,专线带宽又面临了巨大的挑战,迫不得已,专线带宽也要随之升级。

正是由于这双重的成本压力,成为了大部分用户对于网络全流量检测和分析“只可远观而不可亵玩”的重要原因之一,也就更不用谈所谓的全网数据集中检测分析了。

2.4 设备使用门槛高

之前使用的全流量采集分析设备,基本上只提供原始数据包留存和标准协议解码,接下来要做的一切统计分析都丢给用户去做。POC的时候场景固定,所以效果优异,等到用户自己去分析,面对海量数据,毫无线索,则是两眼一抹黑。所谓全流量采集与全流量存储考验的不仅仅是设备性能,它对实际的数据分析人员也提出了极高的要求。目前经常出现的问题:

1)流量确实全部存储了,但是分析系统过于复杂,无人会熟练使用;

2)很多情况下,无差别的全流量存储只会造成资源的浪费,流量存储需要做到按需存储;

3)没有有效线索的逐包分析,导致运维人员对故障分析的效率极低。

古人说得好:好马配好鞍,这么牛的全流量存储工具,必须得配有“专职司机”。这对于本身网络技术薄弱或是信息化投入较少的用户来说,无疑是不现实的。即便是有了高精尖的专业人才,用户同样还会有烦恼,最大的烦恼就是这名专业人才,最好不要生病,也不要休息,更不要离职。

2.5 缺乏反制干预能力

就像诞生在美国空军的“态势感知”,到国内实践时候,只保留了字面意思,少了关键的响应部分,全量数据分析也是一样。防病毒网关、IPS、WAF等全量分析部分存储结果的系统,全部都有对网络的干预能力,例如阻断、干扰。全量数据包抓取的系统,到目前为止则都是纯粹的旁路系统,毫无干预能力。而现有的串接设备,也无法完美完成对流量的干预,主要原因如下:

1)设备筛选条件有限,经常只有五元组;

2)设备性能不足,控制策略不能同时开启,无法在骨干节点串接;

3)做控制的设备在精准度上达不到分析设备的水准,不能做到能力投射。

 

3 分布式全流量数据包采集

行文至此,我们指出了当前全流量数据抓取分析存在的种种问题,但并不影响全流量抓包存在的意义,甚至可以说全流量抓包是很多用户所向往的重要目标。虽然在某些场景中,分布式全流量抓包会造成成本的增加和使用难度的提高,但是在这些特定场景中,分布式的全流量采集的能力仍然是刚需。

3.1 分布式全流量抓包的刚需场景

数据包从来不会说谎,这正是很多场景需要分布式全流量抓包的真实原因。数据包不是一种解析,也不是一种总结描述——它就是最底层的真相。分布式全流量抓包的价值是能够抓取并细节地展示真实发生的事情。究竟在哪些情况下,是急需分布式全流量采集的呢?主要有以下四种场景:

1) 大型、超大型城域网、局域网内部,核心、汇聚、接入均需要部署;

2) 大型多分支互联网络,总部出口、数据中心、分支点出口均需要部署;

3) 大型云端用户网络,总部出口、云端出口均需要部署;

4) 监管类组织和单位,总部出口、专线POP点、被监管单位出口均需要部署。

如果没有分布式全流量部署,那么以上四类场景就会出现以下三个严重问题:


3.2 智能化遥测加持

除去在每个监测点部署采集存储一体的昂贵探针,还有另一个技术——遥测,来降低部署成本,提高效率。顾名思义,遥测就是对远端节点的流量进行采集、回传、测量,当然重点是流量的回传。

国际上遥测相关技术类别主要有以下三种:

基于gRPC的遥测

基于gRPC的遥测技术可以采集设备的接口流量统计、CPU、告警等数据,对采集到的数据进行编码后,实时上报给采集器进行接收和存储。

基于INT的遥测

INT由Barefoot、Arista、Dell、Intel 和 Vmware提出,是一种从设备上采集数据的网络监控技术。设备主动向采集器上送采集数据,提供实时、高速的数据采集功能,达到对网络设备的性能及网络运行情况进行监控的目的。INT主要用来采集报文经过的路径和报文传输时延等数据平面信息。INT监控粒度为单个数据包,可以实现完整的网络状态实时监控。

基于ERSPAN的遥测

ERSPAN是一种端口报文镜像技术,它能够将端口上的报文镜像后,封装为协议号为 0x88BE的GRE报文,并将其发送到远端监控设备。用户可以根据实际需求定义待镜像的报文,例如镜像TCP三次握手报文以便监控 TCP连接建立情况、镜像RDMA信令报文以便监控RDMA会话状态。


但是这些遥测技术在实际现网中很少被使用,其主要的原因如下:

  1. 遥测监测数据单一尤其是INT方式的遥测,只能针对特定路径上的设备进行采集;
  2. 遥测回传开销过大采集器采集到数据后,会在原数据包头部增加新的协议包头,由于现有的隧道协议包头过长,造成很大的开销负担;
  3. 分支流量无法区分有很多分支点内部地址规划一致,回传至总部将无法进行区分;
  4. 设备性能严重不足:产品手册虽然有该功能,但是现网设备不敢轻易开启;

正是因为如此,现有的分布式全流量部署中,远端的探针必带存储,因为原有的遥测技术在全流量的回传的有效性、稳定性、灵活度上确实有待提升。

但是,如果全流量探针具备应用级遥测的能力,将会改变这一现状。所谓应用级遥测能力,就是探针可以实现脱离硬盘、按需采集,并且用来流量回传的VPN也能高质量的保证流量传递的高效和稳定,那应用级遥测技术将会成为用户实现分布式全流量部署的关键。

3.3 海量数据回传

当远端的探针具备了应用级遥测的能力后,用户将实现随时随地的数据采集,同时也将面临海量的数据回传问题。前面我们已经提到过,总部和分支之间的专线成本也不容忽视,因此面对这种大量的数据回传时,应用级遥测要做到十分灵活。


 

在实际现网中有很多复杂的情况,不过对于这种远端流量的回传,我们可以大体列出四种场景:

场景一

用户预算充足,分支点原有主、备双专线,分支点的流量回传使用备用专线上行进行回传;(既不影响现有的业务,还让备用线路充分利用)

场景二

用户预算有限,分支点只有一条专线,此时建议用户购买多条廉价的ADSL线路,分支点的探针需要将多条ADSL进行捆绑,使用其上行进行流量回传;(此方法大大减轻了用户的线路成本)

场景三

用户预算极其有限,分支点只有一条专线,又无法扩容,此时,需要分支点探针基于应用、IP、端口等条件进行业务回传,且回传流量+原有上行流量不能超过专线上行带宽的70%;(此方法可以保证用户在预算不足时,依旧可以实现关键业务回传)

场景四

用户预算有限,且分支点无光纤接入条件,此时远端探针需要支持5G网卡,使其通过5G进行流量回传。当然,此时要和场景三一样,探针要实现基于基于应用、IP、端口等条件进行业务回传。(此方法适用于很多偏远地区的分支点)

通过遥测技术将分支点的数据海量回传,有效的解决了原有数据分析分散的问题,实现了全网流量的统一监控和分析。

3.4 也说弹性

即使有应用级遥测技术的加持,但对于有些用户来说,实现全网全流量检测依旧是压力山大,即使远端的探针再便宜,毕竟分支数量太多,所以成本压力、管理压力、人力压力依旧存在。

其中,成本压力主要来自于全流量采集探针的存储。以100Mbit/s的网络带宽为例,如果要实现全流量数据采集,那么每天将会产生1T左右的原始数据;如果国家要求实现180天的数据存储的话,用户最少也要配置180T以上的硬盘存储空间,这还仅仅只是一个单点的成本。当然,更让人唏嘘的是,存下来的数据大部分成为了电子垃圾,很少有人去看,或者是看了也未必能看懂。

因此,具备按需采集数据的能力全流量探针,成为用户降低的成本的关键。从盲目地进行无差别存储,转变为可以根据IP、端口、域名、应用、VLAN等条件,先对数据进行筛选,然后再进行采集。

比如:可以直接存储某IP地址在6月10日上午9:00-9:30使用的OA系统,所产生的所有原始数据包。这样有针对性的采集方式,让用户能够更加灵活和便捷地了解网络,做事有明确的目标,将有限的精力投入到关键点上。

当然,如果用户现网中在用的网关设备,自身能具备应用级遥测能力,将会是最好选择。这样一来,避免了用户的重复投资。当用户需要进行分支点数据采集时,仅仅需要在分支点的网关上进行软件升级或是安装APP,即可让该网关具备应用级遥测的能力,这样一来无论是数据筛选、设备管理、设备扩容都会变得相对方便。

3.5 数据与三方安全设备共享

通过应用级遥测的能力,用户将顺利地采集到更多分散节点的数据流量。不过在以前的遥测技术中,总部并不能对回传的流量进行区分。有时还会面临多个分支点IP地址规划相同的情况,这种情况在应用级遥测的技术中也得到了相应的解决。应用级遥测技术在采集数据时,即可对流量的上下行进行打标签(VLAN标签)。

传统的探针之所以在用户网络中难以全部推广的最大原因,在于所有的探针都对应单独的一套分析平台,难以实现数据的共享。即使用户预算再怎么充足,也不会在一个分支点部像串糖葫芦一样,部署一堆探针。

应用级遥测技术的出现,实现了采集数据与所有三方分析平台的共享。当流量回传至总部时,总部的接收设备,会将流量按需分给不同厂商的安全设备,比如将HTTP/HTTPS等流量分给WAF,将某源IP段地址下的所有流量分给IDS,或者是将未知流量分给态势感知平台。这样一来,用户不用在远端单独部署不同的探针设备,所有收集上来的流量,均可以通过镜像或是路由到总部不同的安全设备。

4 全流量数据包存储与分析

4.1 数据包网络采集能力

要实现全网的全流量分析,对探针的数据包采集能力和应用识别能力都提出了挑战。一般来讲,用来接收数据包的探针都是x86架构的服务器居多,这就让很多人开始担心网卡的处理性能。不过好在有DPDK的加成,DPDK不同于Linux系统以通用性设计为目的,而是专注于网络应用中数据包的高性能处理。具体体现在DPDK应用程序是运行在用户空间上利用自身提供的数据平面库来收发数据包,绕过了Linux内核协议栈对数据包处理过程。它不是一个用户可以直接建立应用程序的完整产品,不包含需要与控制层(包括内核和协议堆栈)进行交互的工具。

相比原生Linux(Native Linux),采用Intel DPDK技术后能够大幅提升数据包的转发性能,可以让用户在迁移包处理应用时(从基于NPU的硬件迁移到基于Intel x86的平台上),获得更好的成本和性能优势。同时可以采用统一的平台部署不同的服务,如应用处理,控制处理和包处理服务。实际上正是由于DPDK的出现,让现在很多厂商在数据抓包方面都有不错的表现。

4.2 数据包组织与存储

除了采集,实时的数据存储,也是全流量探针的基本操作之一。数据绝不是静静的存在硬盘中就结束了,它随时有可能会被用户读取,如果存储的时候,采用随机存储的方式,那么对于用户读取数据来说,会变得相当困难。

比如:一辆无人驾驶的汽车,每天会产生将近8T的数据。如果只是存储下来不查询也还好(虽然已经是不小的成本),但如果需要快速查询“今天下午两点在后厂村路,速度超过60km/h的无人车有哪些”这样的多纬度分组聚合查询,那么时序数据库会是一个很好的选择。面对如此海量的数据存储,要解决一些客观的问题,如下:

时序存储减少硬盘存储碎片

对采集的数据进行时序存储,并采用固定块大小,固定文件个数,轮询覆盖最老文件,减少硬盘存储碎片。

使用内存进行数据压缩

通过内存进行原始数据压缩,减少硬盘存储文件的数量,达到存储性能提升的目的,并且使用内存进行数据压缩,并不会消耗太多性能,毕竟压缩文件是内存的强项。

元数据、原始数据包分级存储

将元数据与原始数据包的分级存储,元数据存在SSD上面,原始数据包存在机械硬盘上面。以此保证索引信息的快速查询,又不会因为原始数据包过多,造成用户硬盘存储成本的增加。

以上主要解决了数据能否存下来或是被快速读取,但是就像探针在远端采集数据一样,同样面临大量电子垃圾的问题。这种无差别的数据存储不仅无法给用户带来直接的价值,时间一长反而会成为一种负担。任凭谁面对着每天不停产生的几十T原始数据包都会疯掉,因此数据的存储有些时候要尊重实际使用场景,数据存储应该像采集时一样,也可以实现基于IP、端口、域名、应用等条件进行有针对性的存储,至少要让数据分析的工程师有选择的余地。

4.3 原始数据的超级摘要

分布式全流量抓包虽然会采集所有信息,但是它并不是被设计用于提供实时或者任何形式的分析,分析是由一些插件或者其他安全工具解决。全流量的原始数据就像是厨房尚未被处理的蔬菜和肉,直接食用不仅难吃,有时还难以下咽。所以,只有经过加工的原始数据才可以称之为有价值的数据,我们将加工后的原始数据称作超级摘要超级摘要的出现,将赋予平凡的原始数据以灵魂,大大提高数据分析的工作效率。

关于原始数据、数据仓库与超级摘要三者之间的关系,如下图所示:

 

举例说明:

比如,在超级摘要中体现网络流量时延趋势,记录每一个应用的时延分布情况,以及请求失败率。

 

并记录某一协议的内网网络传输部分响应时延,以及时延质量分布比例。

 

同时还可记录某一协议的外网网络传输部分响应时延,以及时延质量分布比例。

 

如果想要在TB级的原始流量中分析出以上结果,基本上是不可能实现的事情。

4.4 数据对接开放平台

全流量的采集存储后,除去使用WEB浏览查询数据等基本操作之外,探针还需要陆续提供文件还原(类似Xplico的文件还原)、攻击检测(类似Snort的攻击检测)以及威胁情报检测(集成Maltrail等威胁情报检测)等功能。

除此之外,一方面全流量采集需要提供开放的三方对接接口,如采集的数据会话日志、URL日志、NPM等索引信息要实现开放,为很多不具备精细化流量采集的安全设备提供有价值的信息,另一方面全流量采集也需要提供原始数据直接路由给三方安全设备的能力。如此目标,是建立一个开放的流量采集、流量回传系统,这样可以避免安全厂家重复造轮子,将能力集中在安全数据分析上,不需要在数据采集、数据存储以及协议识别上再次浪费时间。

 

5 第二种选择

所谓全量数据包抓取的第一种选择是多点部署、全流量采集、全流量存储、无摘要、封闭系统、只能旁路。

 

全量数据包抓取的第二种选择是多点部署、分布式全流量、有目标存储、超级摘要、开放系统、支持串接。

第二种选择和第一种选择最大的区别在于,当用户确实发现网络中出现了攻击的异常数据流量,或是某些关键业务的传输质量受到了影响,用户可以选择将探针串接进网络中进行流量干预,分析数据不是目的,分析后能有效的解决问题,才是根本。

 

 

第二种选择的主打部署场景:

 

终于到了最后,我们怀着无比激动的心情告诉您,以上的梦想,Panabit NTM就是您的第二种选择,扫描下方的二维码,联系我们吧。

基于我们强大的抓包、存储和应用筛选能力,不再需要甲方和专业安全公司重复造轮子,我们会开启合作伙伴计划,用简单的操作接口将整理好的PCAP数据高速无缝的对接给各种检测引擎。

 

 

 

和爱奇艺一起打造不一样的敦煌月牙泉

基于网络流量的网络安全分析与威胁狩猎漫谈