5G核心网网元服务异常检测*

辛冉 高深 阮博男

(1.中国信息通信研究院安全研究所，北京 100191；2. 绿盟科技集团股份有限公司，北京 100089)

0 引言

5G作为新一代的移动通信技术，目标是为移动设备之间的通信提供更高的速度与容量，并可以通过网络切片功能依据业务场景实现网络功能的定制化，例如针对车联网场景需要提供低延迟传输，针对流媒体业务需要提供高带宽等。为了实现以上的功能，5G核心网(5G Core, 5GC)采用服务化架构(Service Based Architecture, SBA)进行实现。SBA对网元进行了拆分，所有的网元又都通过接口接入到系统中，使得5GC的服务以比传统网元更精细的粒度运行，并且彼此松耦合，允许升级单个服务，而对其他服务的影响最小，进而使得5GC的配置、扩容与升级更加便利。相比于4G网络，5GC的暴露面更大，因此5GC面临着许多新的安全问题。其中，网元服务安全是5GC面临的新的安全威胁。

华为5G安全架构白皮书[1]中提到5G安全的两个目标，其中一项是：提供方法和机制来保护建立在5G平台上的服务。基于这个目标，本文提出网元服务安全需要解决3个基本问题：5G协议安全、网络架构安全与网元交互安全，阐释了5G协议、5GC网络架构、网元交互过程中可能面临的风险。针对网络架构安全与网元交互安全，本文提出了更加详细的检测方案，并在所提出方案的基础上进一步研究与试验，设计了网元服务异常检测原型，明确了原型中各个模块的技术路线。本文将6种异常场景在原型上进行测试，输出检测结果，结果中包含将异常场景映射到检测基线的全部特征。除此之外，为了规避检测原型所带来的误报问题，本文利用SOM神经网络对检测参数进行了筛选，成功过滤出有检测价值的参数。

1 5GC网元服务

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

图1 基于服务的5G核心网架构

图1中Namf、 Nausf、 Nsmf等表示各个网元所展示的基于服务的接口，每个网元根据自身功能特性为5GC的正常运行提供服务。其中AF的功能为应用功能、AMF的功能为接入和移动管理功能、AUSF的功能为认证服务功能、NEF的功能为网络开放功能、NRF的功能为网络存储库功能、NSSF的功能为网络切片选择功能、PCF的功能为控制策略功能、SMF的功能为会话管理功能、UDM的功能为统一数据管理功能、UPF的功能为用户平面功能、(R)AN的功能为接入网(基站)、UE的功能为终端。

2 5GC网元服务安全风险

2.1 5G协议安全风险

图1中N1、N2、N4接口分别使用5G-NAS协议、NGAP协议和PFCP协议进行通信。针对这3个接口进行异常检测，需要从各自所采用的协议可能存在的风险与协议自身的规范和特性入手建立基线。

下面以N4接口为例，考虑UPF与SMF通信过程中可能存在的风险。首先，UPF与运营商数据网络直接通信，其端口可能暴露在公网中。此外，基于5GC控制面与用户面分离式架构，UPF需要下沉到网络边缘，增大了暴露风险。N4的建立流程是由SMF下发给UPF的，如果UPF中没有配置完善的网元认证机制，攻击者则可以伪造SMF向UPF发起攻击。PFCP协议所支持的业务流程包括会话建立流程、会话修改流程、会话删除流程和会话报告流程。攻击者在利用伪造的SMF与UPF建立连接后，可利用会话修改流程引导用户面数据包的转发位置，进行数据窃取，也可利用会话删除流程导致某些用户被拒绝服务。

2.2 网络架构安全风险

在5GC中，攻击者可以利用网元的漏洞攻陷某个网元，并从该网元对其他网元的开放接口发起请求，导致网元访问的序列出现异常。例如在UE注册的鉴权流程中，AMF先向AUSF发起鉴权请求，再由AUSF向UDM请求生成鉴权向量。而如果AMF被攻击者攻陷，可直接调用UDM生成鉴权向量的接口，窃取用户的鉴权信息。

又例如NRF网元提供网络仓储功能，维护可用的NF实例及其支持的服务的NF配置文件。如果该网元存在漏洞，攻击者可以利用此漏洞注册恶意的网元，将地址和URI 都指向该恶意网元，那么攻击者可以利用该恶意网元与其他网元进行通信，导致网元调用逻辑出现异常。

2.3 网元交互安全风险

5GC控制面网元利用API进行通信，攻击者可利用API的脆弱性，向网元发送恶意请求，以达到窃取数据、恶意注册/注销网元、使部分用户被拒绝服务等目的，具体两个场景如下。

(1)NRF 网元提供接口，可以基于提供的实例 id 对于 NRF 存储的网元进行删除。当 NRF 里的网元被注销后，其他网元即无法通过 NRF 网元得到该网元的相关信息，从而导致服务不可用。

(2)终端的真实身份在 5G 里称为 SUPI，通过公钥加密后的内容则称为 SUCI。在通信的过程 中使用 SUCI可保证 SUPI 不被泄露。 而 AUSF 网元存在的接口是：/nausf-auth/v1/ue-authenticatons/{authCtxId}/5g-aka-confirmation，其中{authCtxId}就是 SUCI。当 SUCI 的值传递错误时，接口会返回 USER NOT FOUND 信息；而当 SUCI 的值传递正确时，即使别的参数传递错误(例如 resStar 的值错误)，接口 也会返回 SUPI 的值，并告知错误原因。 因此，如果攻击者进入 5G 核心网，并且嗅探到 SUCI 的值，就可以通过这个接口得 到 SUPI 的值。

3 5GC网元服务异常检测策略

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

3.1 全流量分析的挑战

3.1.1 协议多样性

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

3.1.2 业务请求高并发

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

3.1.3 参数结构复杂

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

图2 UE上下文参数结构

3.2 基线构建策略

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

接下来以核心网对用户设备的鉴权流程为例，介绍基线构建的基本思路。

首先，核心网对UE鉴权过程中产生的网元调用序列如图3所示。其次，核心网对UE鉴权过程中所使用的请求方式和接口如图4所示。此外，核心网对UE鉴权过程中所传递的参数如图5所示。最后，核心网对UE鉴权过程所返回的参数如图6所示。

图4 核心网对UE鉴权的API信息

图5 核心网对UE鉴权的请求参数

图6 核心网对UE鉴权的响应参数

图3 核心网对UE鉴权的网元序列

基于以上4个特征，在数据采集不缺失以及数据字段解析完整的前提下，可以相对准确地将核心网对UE鉴权过程中的网元服务调用行为刻画出来，并以此为基线进行异常检测。

4 5GC网元服务异常检测原型

5GC网元服务异常检测原型设计如图7所示。下面将分节介绍各个模块的技术路线和实现原理。

图7 检测原型设计图

4.1 数据解析

数据解析部分采用了Pyshark所提供的方法。tshark是wireshark下的解包工具，而Pyshark是针对tshark的Python封装器，利用Pyshark可以通过Python程序将数据包中各层的各个字段解析出来。解析后得到可用于异常检测的字段，包括时间戳、http2 streamid、tcp streamid、源ip、目的ip、源端口、目的端口、请求方式、URL、响应码、请求参数、响应参数等。其中，在对参数进行解析时，由于参数的格式为多层嵌套的json数据，而Pyshark只提供解包功能，也就是在识别到特定字段后输出相应的结果，这会导致解析出来的结果不光丢弃了原有的参数树形结构，而且数据的键和值也无法一一匹配。那么在处理参数时，不妨先保留所有的参数信息，将data帧中的原始数据(16进制数组)转换成ascii，输出带有结构信息的字符串(可以理解为将原始参数通过json.dumps进行了转字符处理)，便可得到完整的参数。此时输出的参数还无法直接用来做检测，后面可加入相应的算法，即可既保留参数的结构信息，又能够检索对比。

4.2 参数结构提取

在数据包中，HEADER帧与DATA帧有时是分开的，由此会引发数据包的截断问题，即header与body不在同一数据帧中。那么在提取参数结构之前，首先需要解决参数的归属问题。使用http2 stream id 与 tcp stream id可以将同一请求的信息关联起来。

那么在解析参数时，需要将参数字符值与http2 streamid、 tcp stream id进行关联存储，此后将包含API信息的数据表与包含参数信息的数据表以http2 stream id与tcp stream id为键值进行关联归并，即可找到参数所对应的API信息。

解决数据包截断问题之后，就可以进一步进行参数结构提取的工作了。前面已经提到过直接通过原始数据转换获得的参数是无法直接拿来做检测的，这里还是以UE上下文为例，给出参数结构的处理方案。

为使每个参数值都能匹配到对应的结构信息，可以利用深度优先搜索算法，算法描述见算法1。

算法1 参数结构提取算法

输入 嵌套参数字典p, 空链表l, 空字符s

输出 参数链路列表l(如图8)

图8 UE上下文链路信息

过程：函数DFS(p,l,s)

ifp为字典then//当前数据形式为字典

forp中每一个k,vdo//遍历字典中所有数据

DFS(v,l,s+’[间隔符]’+k)//以当前数据的value为根节点递归调用DFS函数，并将key信息加入存储字符s中

end for//字典数据遍历结束

elseifp为列表 then//当前数据形式为列表

forp中每一个v do//遍历列表中所有数据

DFS(v,l,s+’[间隔符]’+’[列表标记符]’))//以当前数据为根节点递归调用DFS函数，并将列表信息作标记加入存储字符s中

end for//列表数据遍历结束

else//当前数据形式不存在嵌套结构

l.append(s+’[间隔符]’+p)//将存储字符s中所有信息存入输出列表中

end if

4.3 用户信息提取

为解决高并发下的数据包归属问题，需要从解析后的数据集中提取用户信息。这里的用户信息主要是指用户设备在核心网中的身份标识，根据3GPP TS 23.502[3], 用户设备在核心网中的身份标识包括用户永久标识符(SUPI)、用户隐藏标识符(SUCI)、永久设备标识符(PEI)、5G全球唯一临时标识符(5G-GUTI)等。通过对已有数据集的分析处理，用户设备的身份标识主要包含在请求的URL中，请求参数与响应参数中。因此，在这几个字段下，采用关键字符匹配的手段，可提取出用户设备的身份标识，并将其作为一项特征存储进数据集中。

4.4 调用序列还原

判断两次通信是否属于同一序列的一项重要标准为：这两次通信间是否存在“响应等待”。以核心网对用户设备的鉴权流程为例，此流程的网元调用序列为AMF-AUSF-UDM-UDR，映射到数据包中体现为AMF向AUSF发起请求，AUSF向UDM发起请求，UDM向UDR发起请求，UDR向UDM返回响应，UDM向AUSF返回响应，AUSF向AMF返回响应。由此看来，序列存在的一项关键特征为，序列前置位的网元发送通信请求后，不会立刻收到响应回复，需要等待序列后置位的网元以序列逆序依次返回响应。

在进行调用序列还原之前，需要为数据表中的各行标记请求响应类型，标记标准为对存在请求方式不存在响应码的数据标记为请求，对存在响应码不存在请求方式的数据标记为响应。调用序列还原算法描述见算法2。

算法2 网元序列还原算法

输入 标记后的数据表df

输出 调用序列列表l

过程：函数TraceGenerate(df)

生成空栈stack, 序列信息存储字符t, 调用序列列表l，前一行数据记录previous

fordf中每一行current do//遍历数据表

if current与previous除时间戳外完全一致then

将previous标记为重复请求并跳过对previous数据的处理//过滤重复请求产生的无效数据

end if

if current被标记为请求 then

将current的网元调用信息与API信息加入stack//请求信息入栈

if previous被标记为响应then

将t加入l后将t清空//当前数据为请求且前一行数据为响应时，代表一个序列还原结束，需要将存储字符t加入输出结果l中

end if

else

if 栈stack非空 then

栈顶数据出栈并将栈顶数据信息加入t中//对于响应数据的处理方式为，在栈非空的情况下，此时栈顶数据为该响应所对应的请求，那么将此次通信作为序列的一部分加入存储字符t中

end if

end if

previous=current//对当前行数据处理结束，将当前行记为前一行，并准备开始下一行数据的处理

end for//数据表遍历结束

ift长度大于0 then

将t加入l//将最后的遗留序列信息加入输出列表中

end if

4.5 API信息整合

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

4.6 参数字典构建

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

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

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

为了保证检测的质量和效率，需要在构建字典时尽可能地筛选出不具备检测价值的参数。实现参数筛选基于以下两个基本特征。

同键值参数列表长度l，l值越大，代表此参数出现次数越多。这里笔者认为l值越小，检测价值越高。一种极端情况为，当l为0时，该参数是从未出现过的，可直接判定为异常参数。为了使该特征取值在0～1范围内，并满足单调递减特性，可以将第一个特征定义为

x1=e-l

(1)

参数值或参数正则式在同键值参数中出现的最大概率p。此概率越大，参数取值分布越集中，越不容易产生误报。因此，将第二个特征定义为

x1=e-lx2=p

(2)

基于以上两个统计特征，可利用机器学习算法对参数进行聚类。考虑当前要解决的聚类问题满足与神经网络中基本的感知机模型较为契合，因此选用SOM神经网络进行聚类。

在free5gc实验环境中，笔者对参数筛选模型进行了测试，图9中颜色深浅代表节点间距，颜色越浅的地方节点越集中。此模型将检测参数大致分为3类，根据异常场景“使用SUPI访问UDR将该用户的认证状态改为false”中success参数是存在异常的，那么选择success所在的类作为有检测价值的参数。

图9 SOM神经网络聚类结果

4.7 参数阈值计算

核心网网元通信传递的某些数值型参数是连续型的，对于这类连续型参数，构建参数字典进行检测所得到的结果是不准确的，需要通过限定取值范围的方式来进行检测。取值范围的计算方式有很多种，这里笔者选用了一种满足大部分参数分布的计算方法：利用正态分布的3σ定理，将阈值设定在距平均值3倍标准差之内。

4.8 试验验证

在free5gc实验环境中，从UPF网元向核心网中其他网元发起异常调用，检测场景包含以下6项。

(1)从NRF获取网元信息，发现更多网元。

(2)发送非法请求给AUSF试探。

(3)使用用户SUCI窃取SUPI。

(4)使用SUPI访问UDM获取UE信息。

(5)使用SUPI访问UDR将该用户的认证状态改为false。

(6)使用NRF获取到的NF instance id访问NRF，删除某个网元。

将异常场景生成的流量数据输入检测原型，根据检测结果得出结论如下。

(1)序列基线可检测所有异常序列，并可溯源攻击发起IP。

(2)参数基线可检测所有异常参数，例如“使用SUPI访问UDR将该用户的认证状态改为false”所产生的异常参数false等，但存在少量误报，误报率约为16%，误报来源于模型误差。

(3)API操作基线可检测攻击试探行为、恶意删除网元等场景。

5 结束语

本文将5GC网元服务安全分为5G协议安全、网络架构安全、网元交互安全3个方向，介绍了5GC网元服务所面临的安全风险，并针对网络架构安全和网元交互安全给出了成熟的解决方案。根据解决方案，本文设计了5GC网元服务安全异常检测原型，检测原型的核心技术在于参数结构提取算法、序列还原算法以及参数筛选模型。通过实验验证，检测原型可以有效地检测出5GC网元服务异常。

在协议安全方面，下一步还需要对N1、N2、N4接口协议可能存在的脆弱性进行分析和验证。此外，本文提出的检测方案对5G领域知识的融入还不够，尚需要将5GC的业务行为引入检测机制中，建立更细粒度的基线。

盼望5GC作为万物互联的基础设施之一，可以高效且安全地为大家提供便利。