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

如何用全流量检测5G核心网网元服务异常
2021-06-11 16:02:03 Author: www.aqniu.com(查看原文) 阅读量:168 收藏

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

星期五, 六月 11, 2021

摘要

本文设计了通过全流量进行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所示