如何用全流量检测5G核心网网元服务异常
作者:星期五, 六月 11, 20210

摘要

本文设计了通过全流量进行5G核心网网元服务异常检测的原型系统,并简要阐述了原型中各个模块的技术路线。

一. 引言

华为5G安全白皮书[1]中提到5G安全的两个目标,其中一项是:提供方法和机制来保护建立在5G平台上的服务。基于这个目标,新架构,新挑战:5G核心网业务安全问题与异常检测一文中提出了网元服务所面临的三个基本问题:调用序列,调用参数异常与调用频率异常,阐释了针对这三种异常的检测思路,并提出了针对序列异常的解决方案。本文在这篇文章的基础上进行进一步研究与实验,设计了网元服务异常检测原型,明确了原型中各个模块的技术路线。将已有网元威胁分析输出的场景在原型进行测试,输出检测结果。结果中包含将异常场景映射到检测基线的全部特征。

二. 5G核心网网元服务

在介绍检测机制之前,首先明确下我们要检测的目标:5G核心网网元服务。
3GPP TS 23.501[2]将网元之间的交互集定义为服务。该规范将5G架构的定义分为两种表示方式:基于服务的表示方式和基于网元间交互的表示方式。其中基于服务的5G架构如图1所示。

图1 基于服务的5G架构

图中Namf, Nausf, Nsmf等表示各个网元所展示的基于服务的接口。每个网元所提供服务的具体功能可参见附录。

三. 全流量分析

检测原型所采用的基本检测技术是全流量分析,通过分析核心网运行过程中产生的流量数据进行异常行为的检测。攻击者在尚未摸清网元服务的工作方式之前,往往要进行攻击试探,试探过程中产生的流量与网元正常工作时产生的流量有较大差异,是检测出攻击行为的最好时机。此外,攻击者在对网元服务开展攻击行为的过程中,也会产生异常流量。鉴于攻击试探与攻击行为发生过程中产生的流量与正常业务工作过程中产生流量的差异性,对5G全流量数据进行分析处理,通过检测异常流量的方式来检测异常行为,可实现5G核心网中的网元服务异常检测。

四. 全流量分析的挑战

4.1 协议多样性

图2,图3分别展示了5G核心网控制面协议栈与用户面协议栈。将5G全流量以协议划分,主要包括控制面网元间通信时产生的HTTP2协议数据,基站与AMF通信时产生的NGAP协议数据,控制面与用户面通信时产生的PFCP协议数据,用户面通信时产生的GTP-U协议数据,用户设备与AMF通信时产生的NAS协议数据,用户设备与基站通信时产生的SDAP协议数据与RRC协议数据以及基站间通信时产生的XnAP协议数据。鉴于针对不同协议的攻击方式是不同的,那么面向不同协议进行数据分析的维度以及异常检测的手段也需要相应调整。因此,协议的多样性成为5G全流量分析的挑战之一。

图2 控制面协议栈

图3 用户面协议栈

4.2 高并发

如图4所示,核心网需要处理大量用户的不同业务请求,每种请求发送到核心网中会都产生一部分数据包,因此会引发业务高并发运行下的数据包归属问题,即某个数据包是哪个用户在何种业务场景下产生的,只有解决了高并发环境下的数据包归属问题,才能更好地对业务行为进行还原,进而建立基线。

图4 高并发业务示例

4.3 参数结构复杂

参数结构中存在大量列表与字典嵌套的结构,那么参数除了k-v值之外,结构信息也成为参数特征之一,那么在做检测时,也需要考虑参数结构信息。如何将这种复杂结构进行有效解析,并结构信息引入检测方法中,也是全流量分析的挑战之一。

五. HTTP2流量分析

鉴于已有的威胁分析工作是基于HTTP2协议的,本节将针对HTTP2协议,进行异常流量分析。异常流量的检测可采用基于基线的检测方式:首先利用历史数据对正常网元业务进行还原,将还原后的信息加入基线中,基线建好后,通过对偏离基线的流量进行筛选,可实现异常流量的识别。

5.1 针对网元服务的攻击手段

目前已经完成的威胁分析工作表明,攻击者针对网元服务的攻击方式主要是恶意调用网元服务API,以达到窃取数据,恶意修改用户信息和通信状态,影响网元正常服务等目的。

5.2 基线构建策略

由于针对网元服务的攻击方式主要为恶意调用网元服务API。那么,以网元服务API的调用行为作为标准建立基线,可对网元服务进行有效的异常检测。

在数据采集不缺失以及数据字段解析完整的前提下,将API调用相关的网元信息、请求方式、URL、请求参数等整合处理,并以此为基线进行异常检测。

5.3 检测原型

检测原型设计如下图

图5 检测原型设计图

下面简要介绍各个模块的技术路线和实现原理。

5.3.1 数据解析

数据解析部分采用了Pyshark所提供的方法。大家应该熟悉wireshark下的解包工具tshark,而Pyshark是针对tshark的Python封装器,利用Pyshark可以通过Python程序将数据包中各层的各个字段解析出来。在对参数进行解析时,由于参数的格式为多层嵌套的json数据,而Pyshark只提供解包功能,也就是在识别到特定字段后输出相应的结果,这会导致解析出来的结果不光丢弃了原有的参数树形结构,而且数据的键和值也无法一一匹配。那么在处理参数时,我们不妨先保留所有的参数信息,此时的输出的参数是无法直接用来作检测的,不过没关系,后面会加入相应的算法,可以既保留参数的结构信息,又能够检索对比。

5.3.2 参数结构提取

前面提到直接通过原始数据转换获得的参数是无法直接拿来做检测的,这里还是以UE上下文为例,给出参数结构的处理方案。

根据图5所示的参数树形结构,参数的具体取值在树的叶子节点中,为使每个参数值都能匹配到对应的结构信息,利用深度优先搜索算法,将树形结构拆分成链路结构,每个链路中既包含参数结构信息又包含参数值。

5.3.3 用户信息提取

为解决高并发下的数据包归属问题,需要从解析后的数据集中提取用户信息。这里的用户信息主要是指用户设备在核心网中的身份标识,根据3GPP TS 23.502[3], 用户设备在核心网中的身份标识包括用户永久标识符(SUPI),用户隐藏标识符(SUCI),永久设备标识符(PEI),5G全球唯一临时标识符(5G-GUTI)等。采用关键字符匹配的手段,可提取出用户设备的身份标识,并作为一项特征存储进数据集中。

5.3.4 调用序列还原

判断两次通信是否属于同一序列的一项重要标准为:这两次通信间是否存在“响应等待”。序列存在的一项关键特征为,序列前置位的网元发送通信请求后,不会立刻收到响应回复,需要等待序列后置位的网元以序列逆序依次返回响应。先将数据集进行请求响应类型标记,再将标记后的数据集进行链路还原,生成的网元序列基线如图13所示

图6 调用序列基线示例

5.3.5 API信息整合

攻击者在尚未摸清网元服务API的工作方式时,需要对API进行试探性调用,再根据返回结果进行进一步攻击。试探性调用中所使用的请求方式和URL往往与网元服务正常工作时所使用的请求方式和URL是不同的,那么通过对历史数据中的API信息进行整合,可在攻击者进行攻击试探时及时发现。当然,这只是进行一项统计后去重的工作,没什么技术瓶颈,这里唯一需要讨论的问题是这项工作的必要性。其实在前面网元序列还原的工作中,已经加入了API信息,为什么还需要为API信息单独建立基线呢?根据基线构建思路中所描述的,预期得到的基线是将网元序列,API信息,参数信息整合后的结果。但在实际测试过程中,利用整合后的基线进行检测所得到的检测结果并不理想。原因是我们对高并发问题的处理方式是以用户标识为基准进行归并,没有进行用户标识传递的通信就会被忽略掉,从而导致序列的不完整。而在整合的基线下,序列的不完整会直接导致API信息和参数的不完整。若某次攻击试探行为没有发生用户标识的传递(这种调用是极有可能发生的),那么此次试探便会直接被原型漏掉。因此,我们不再利用多维度整合的基线进行检测,而是将网元序列,API信息,参数三个维度进行拆分,将拆分后的三个维度分别建立基线。经过检测测试,我们发现拆分后的基线比整合基线的表现更好。

生成的API信息基线如图14所示

图7 API信息基线示例

5.3.6 参数字典构建

为进行网元服务API的传入参数异常检测,可利用历史数据生成参数字典,并以字典外的参数为异常参数。构建时需要注意的一点是,通信时传递的某些参数是不具备检测价值的,比如ueLocationTimestamp,这类参数通常具有以下特性:

  1. 无规律性:每次通信时所传递的参数值几乎都是不同的。
  2. 无参考性:给出该参数的一个特定值,无法判断该值是由正常业务还是异常调用引发的。
    为了保证检测的质量和效率,需要在构建字典时尽可能地筛选出不具备检测价值的参数。经过对参数的筛选,生成的参数字典如图15所示

图8 参数字典示例

5.3.7 参数阈值计算

核心网网元通信传递的某些数值型参数是连续型的,对于这类连续型参数,构建参数字典进行检测所得到的结果是不准确的,需要通过限定取值范围的方式来进行检测。取值范围的计算方式有很多种,这里我们选用将阈值设定在距平均值3倍标准差之内。生成的基线如图17

图9 参数阈值示例

5.4 测试检测结果

在实验环境中从UPF网元发起API异常调用,对包括攻击试探,数据窃取,更改用户通信状态等攻击手段的六种异常场景进行测试,输出检测结果。

当前检测结果显示:

1.异常网元服务访问所产生的异常调用序列,异常参数,异常API操作信息被全部输出。

2.异常信息中包含误报,主要原因为目前所采用的检测策略为低频信息筛选,除用户标识识别外未引入其他5G领域知识,导致原型对5G场景的适配性不足,将部分正常业务识别为异常。

六. 总结与展望

本文的总体目标是通过全流量分析的手段,为5G网元服务提供准确高效的异常检测机制。目前已经完成了对HTTP2流量的初步分析和检测工作,在实验环境中进行检测的结果显示当前的原型可以覆盖目前已有异常场景的检测。主要的问题是原型过于通用化,没有引入5G领域知识,导致误报过多。

接下来的工作方向将从以下四个方向切入:

1.进一步完善参数字典的筛选工作,目前检测原型所产生误报大部分来源于uuid,resStar,sequenceNumber等无参考性参数。在正常业务工作时,这类参数的取值也未必在历史基线中,会被原型识别为异常。因此,需要对这类参数进行识别筛选。

2.在原型中加入5G领域知识以提升检测的准确性。

3.将时序特征作为新的检测维度加入原型中。

4.实现针对NGAP,PFCP协议的异常检测。

最后,为大家提供一个在kubernetes集群上基于开源项目free5gc的核心网部署方案。有需要的朋友可参照链接进行部署。

https://www.github.com/Silverbullet9/5gc-kubernetes

参考链接

[1] https://www-file.huawei.com/-/media/corporate/pdf/white%20paper/5g_security_architecture_white_paper_cn_v2.pdf?la=zh

[2]https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3144

[3]https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3145

附录 – 5G核心网网元服务

AMF服务

SMF服务

PCF服务

UDM服务

NRF服务

AUSF服务

NSSF服务

AF服务

UDR服务


相关文章