如何用全流量检测5G核心网网元服务异常

阅读： 2,224

摘要

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

一、引言

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

二、5G核心网网元服务

在介绍检测机制之前，首先明确下我们要检测的目标：5G核心网网元服务。

3GPP TS 23.501[2]将网元之间的交互集定义为服务。该规范将5G架构的定义分为两种表示方式：基于服务的表示方式和基于网元间交互的表示方式。其中基于服务的5G架构如图1所示。

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

三、全流量分析

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

四、全流量分析的挑战

4.1 协议多样性

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

4.2 高并发

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

4.3 参数结构复杂

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

五、HTTP2流量分析

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

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

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

5.2 基线构建策略

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

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

5.3 检测原型

检测原型设计如下图：

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

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

5.3.5 API信息整合

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

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

5.3.6 参数字典构建

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

1. 无规律性：每次通信时所传递的参数值几乎都是不同的。

2. 无参考性：给出该参数的一个特定值，无法判断该值是由正常业务还是异常调用引发的。

为了保证检测的质量和效率，需要在构建字典时尽可能地筛选出不具备检测价值的参数。经过对参数的筛选，生成的参数字典如图15所示。

5.3.7 参数阈值计算

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

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

参考链接

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

AMF服务

服务名称	描述
Namf_Communication	使NF（网络功能）消费者能够通过AMF与UE或AN通信
Namf_EventExposure	允许其他NF消费者用户或获得与移动相关的事件和统计信息通知
Namf_MT	使NF消费者能够确保UE可以访问
Namf_Location	使NF消费者能够请求目标UE的位置信息

SMF服务

服务名称	描述
Nsmf_PDUSession	管理PDU会话并使用从PCF接收的策略和计费规则
Nsmf_EventExposure	将PDU会话上发生的事件展示给消费者NF

PCF服务

服务名称	描述
Npcf_AMPolicyControl	向NF消费者提供接入控制，网络选择和移动管理相关策略，UE路由选择策略
Npcf_SMPolicyControl	向NF消费者提供与会话相关的策略
Npcf_PolicyAuthorization	授权AF请求，并根据AF会话所绑定的PDU会话的授权AF的请求创建策略
Npcf_BDTPolicyControl	向NF消费者提供后台数据传输策略
Npcf_UEPolicyControl	向NF使用者提供UE策略关联的管理
Npcf_EventExposure	为事件公开提供支持

UDM服务

服务名称	描述
Nudm_UECM	1.向NF消费者提供与UE的交互信息相关的信息。 2.允许NF使用者在UDM中注册和注销其服务UE的信息。 3.允许NF使用者更新UDM中的某些UE上下文信息。
Nudm_SDM	1.允许NF使用者在必要时检索用户数据。 2.向用户的NF消费者提供更新的用户数据。
Nudm_UEAuthentication	1.向用户的NF消费者提供更新的认证相关用户数据。 2.对于基于AKA的身份验证，此操作可用于从安全上下文同步失败情况中恢复。 3.用于通过UE了解身份验证过程的结果。
Nudm_EventExposure	1. 允许NF消费者用户以接收活动。 2. 向用户的NF消费者提供事件的监控指示。
Nudm_ParameterProvision	提供可以在5GS中用于UE 的信息。
Nudm_NIDDAuthorisation	为接收到的外部组标识符或GPSI授权NIDD配置请求。

NRF服务

服务名称	描述
Nnrf_NFManagement	为NF和NF服务的注册，注销和更新服务提供支持。
Nnrf_NFDiscovery	允许一个NF服务使用者发现具有特定NF服务或目标NF类型的一组NF实例。
Nnrf_AccessToken	提供NF到NF授权的OAuth2 2.0接入令牌。

AUSF服务

服务名称	描述
Nausf UEauthentication	AUSF为请求者NF提供UE认证服务。

NSSF服务

服务名称	描述
Nnssf_NSSelection	向请求者提供请求的网络切片信息。
Nnssf_NSSAIAvailability	根据每个TA为NF消费者提供S-NSSAI的可用性。

AF服务

服务名称	描述
Naf_EventExposure	使用户NF可以获取事件或通知事件。

UDR服务

服务名称	描述
Nudr_DM	允许NF消费者根据适用于消费者的数据集检索，创建，更新，用户更改通知，取消用户更改通知以及删除存储在UDR中的数据。
Nudr_GroupIDmap	允许NF使用者检索与订户标识符相对应的NF组ID。

本站“技术博客”所有内容的版权持有者为绿盟科技集团股份有限公司（“绿盟科技”）。作为分享技术资讯的平台，绿盟科技期待与广大用户互动交流，并欢迎在标明出处（绿盟科技-技术博客）及网址的情形下，全文转发。
上述情形之外的任何使用形式，均需提前向绿盟科技（010-68438880-5462）申请版权授权。如擅自使用，绿盟科技保留追责权利。同时，如因擅自使用博客内容引发法律纠纷，由使用者自行承担全部法律责任，与绿盟科技无关。

如何用全流量检测5G核心网网元服务异常

Meet The Author

Leave Comment