引言
华为5G安全白皮书[1]中提到5G安全的两个目标，其中一项是：提供方法和机制来保护建立在5G平台上的服务。基于这个目标，新架构，新挑战：5G核心网业务安全问题与异常检测一文中提出了网元服务所面临的三个基本问题：调用序列，调用参数异常与调用频率异常，阐释了针对这三种异常的检测思路，并提出了针对序列异常的解决方案。本文在这篇文章的基础上进行进一步研究与实验，设计了网元服务异常检测原型，明确了原型中各个模块的技术路线。将已有网元威胁分析输出的场景在原型进行测试，输出检测结果。结果中包含将异常场景映射到检测基线的全部特征。
一、5G核心网网元服务
在介绍检测机制之前，首先明确下我们要检测的目标：5G核心网网元服务。
3GPP TS 23.501[2]将网元之间的交互集定义为服务。该规范将5G架构的定义分为两种表示方式：基于服务的表示方式和基于网元间交互的表示方式。其中基于服务的5G架构如图1所示。
图1 基于服务的5G架构
图中Namf,Nausf, Nsmf等表示各个网元所展示的基于服务的接口。每个网元所提供服务的具体功能可参见附录。
二、全流量分析
检测原型所采用的基本检测技术是全流量分析，通过分析核心网运行过程中产生的流量数据进行异常行为的检测。攻击者在尚未摸清网元服务的工作方式之前，往往要进行攻击试探，试探过程中产生的流量与网元正常工作时产生的流量有较大差异，是检测出攻击行为的最好时机。此外，攻击者在对网元服务开展攻击行为的过程中，也会产生异常流量。鉴于攻击试探与攻击行为发生过程中产生的流量与正常业务工作过程中产生流量的差异性，对5G全流量数据进行分析处理，通过检测异常流量的方式来检测异常行为，可实现5G核心网中的网元服务异常检测。
三、全流量分析的挑战
3.1协议多样性
图2，图3分别展示了5G核心网控制面协议栈与用户面协议栈。将5G全流量以协议划分，主要包括控制面网元间通信时产生的HTTP2协议数据，基站与AMF通信时产生的NGAP协议数据，控制面与用户面通信时产生的PFCP协议数据，用户面通信时产生的GTP-U协议数据，用户设备与AMF通信时产生的NAS协议数据，用户设备与基站通信时产生的SDAP协议数据与RRC协议数据以及基站间通信时产生的XnAP协议数据。鉴于针对不同协议的攻击方式是不同的，那么面向不同协议进行数据分析的维度以及异常检测的手段也需要相应调整。因此，协议的多样性成为5G全流量分析的挑战之一。
图2 控制面协议栈
图3 用户面协议栈
3.2高并发
如图4所示，核心网需要处理大量用户的不同业务请求，每种请求发送到核心网中会都产生一部分数据包，因此会引发业务高并发运行下的数据包归属问题，即某个数据包是哪个用户在何种业务场景下产生的，只有解决了高并发环境下的数据包归属问题，才能更好地对业务行为进行还原，进而建立基线。
图4 高并发业务示例
3.3参数结构复杂
参数结构中存在大量列表与字典嵌套的结构，那么参数除了k-v值之外，结构信息也成为参数特征之一，那么在做检测时，也需要考虑参数结构信息。如何将这种复杂结构进行有效解析，并结构信息引入检测方法中，也是全流量分析的挑战之一。以UE上下文为例，其结构如图5。
图5 UE上下文参数结构
四、HTTP2流量分析
鉴于已有的威胁分析工作是基于HTTP2协议的，本节将针对HTTP2协议，进行异常流量分析。异常流量的检测可采用基于基线的检测方式：首先利用历史数据对正常网元业务进行还原，将还原后的信息加入基线中，基线建好后，通过对偏离基线的流量进行筛选，可实现异常流量的识别。
4.1针对网元服务的攻击手段
目前已经完成的威胁分析工作表明，攻击者针对网元服务的攻击方式主要是恶意调用网元服务API，以达到窃取数据，恶意修改用户信息和通信状态，影响网元正常服务等目的。
4.2基线构建策略
由于针对网元服务的攻击方式主要为恶意调用网元服务API。那么，以网元服务API的调用行为作为标准建立基线，可对网元服务进行有效的异常检测。
接下来以核心网对用户设备的鉴权流程为例，介绍基线构建的基本思路。
首先，核心网对UE鉴权过程中产生的网元调用序列为
图6 核心网对UE鉴权的网元序列
其次，核心网对UE鉴权过程中所使用的请求方式和接口为
图7 核心网对UE鉴权的API信息
此外，核心网对UE鉴权过程中所传递的参数为
图8核心网对UE鉴权的请求参数
最后，核心网对UE鉴权过程所返回的参数为
图9核心网对UE鉴权的响应参数
基于以上四个特征，在数据采集不缺失以及数据字段解析完整的前提下，可以相对准确地将核心网对UE鉴权过程中的网元API行为刻画出来，并以此为基线进行异常检测。
4.3检测原型
检测原型设计如下图
下面简要介绍各个模块的技术路线和实现原理。
4.3.1数据解析
数据解析部分采用了Pyshark所提供的方法。大家应该熟悉wireshark下的解包工具tshark，而Pyshark是针对tshark的Python封装器，利用Pyshark可以通过Python程序将数据包中各层的各个字段解析出来。解析后得到可用于异常检测的字段包括时间戳，http2streamid，tcp streamid，源ip，目的ip，源端口，目的端口，请求方式，URL，响应码，请求参数，响应参数等。其中，在对参数进行解析时，由于参数的格式为多层嵌套的json数据，而Pyshark只提供解包功能，也就是在识别到特定字段后输出相应的结果，这会导致解析出来的结果不光丢弃了原有的参数树形结构，而且数据的键和值也无法一一匹配。那么在处理参数时，我们不妨先保留所有的参数信息，将data帧中的原始数据（16进制数组）转换成ascii，输出带有结构信息的字符串（可以理解为将原始参数通过json.dumps进行了转字符处理），便可得到完整的参数。当然，此时的输出的参数是无法直接用来作检测的，不过没关系，后面会加入相应的算法，可以既保留参数的结构信息，又能够检索对比。
4.3.2参数结构提取
在数据包中，HEADER帧与DATA帧有时是分开的，由此会引发数据包的截断问题，即header与body不在同一数据帧中。那么在提取参数结构之前，首先需要解决参数的归属问题。使用http2stream id 与 tcp stream id可以将同一请求的信息关联起来，如图11所示。
图11 同一http2 stream id与tcpstreamid下的关联数据包
那么在解析参数时，需要将参数字符值与http2streamid, tcp stream id进行关联存储，此后将包含API信息的数据表与包含参数信息的数据表以http2stream id与tcp stream id为键值进行关联归并，即可找到参数所对应的API信息。
解决数据包截断问题之后，就可以进一步进行参数结构提取的工作了。前面已经提到过直接通过原始数据转换获得的参数是无法直接拿来做检测的，这里还是以UE上下文为例，给出参数结构的处理方案。
根据图5所示的参数树形结构，参数的具体取值在树的叶子节点中，为使每个参数值都能匹配到对应的结构信息，可以利用深度优先搜索算法：
—————————————————————————————
输入：嵌套参数字典p,空链表l,空字符s
过程：函数DFS(p,l,s)
1: if p为字典then
2: for p中每一个k,vdo
3: DFS(v,l,s+"[间隔符]"+k)
4: end for
5: else if p为列表then
6: for p中每一个vdo
7: DFS(v,l,s+"[间隔符]"+‘[列表标记符]’)
8: end for
9: else
10: l.append(s+"[间隔符]"+p);return
11:end if
输出：参数链路列表l (如图12)
—————————————————————————————
图12 UE上下文链路信息图
4.3.3用户信息提取
为解决高并发下的数据包归属问题，需要从解析后的数据集中提取用户信息。这里的用户信息主要是指用户设备在核心网中的身份标识，根据3GPPTS 23.502[3], 用户设备在核心网中的身份标识包括用户永久标识符(SUPI)，用户隐藏标识符(SUCI)，永久设备标识符(PEI)，5G全球唯一临时标识符(5G-GUTI)等。通过对已有数据集的分析处理，用户设备的身份标识主要包含在请求的URL，请求参数与响应参数中。因此，在这几个字段下，采用关键字符匹配的手段，可提取出用户设备的身份标识，并作为一项特征存储进数据集中。
4.3.4调用序列还原
判断两次通信是否属于同一序列的一项重要标准为：这两次通信间是否存在“响应等待”。以核心网对用户设备的鉴权流程为例，此流程的网元调用序列为AMF-AUSF-UDM-UDR，映射到数据包中体现为AMF向AUSF发起请求，AUSF向UDM发起请求，UDM向UDR发起请求，UDR向UDM返回响应，UDM向AUSF返回响应，AUSF向AMF返回响应。由此看来，序列存在的一项关键特征为，序列前置位的网元发送通信请求后，不会立刻收到响应回复，需要等待序列后置位的网元以序列逆序依次返回响应。
在进行调用序列还原之前，需要为数据表中的各行标记请求响应类型，标记标准为对存在请求方式不存在响应码的数据标记为请求，对存在响应码不存在请求方式的数据标记为响应。将标记后的数据集进行链路还原，生成的网元序列基线如图13所示
图13 调用序列基线示例
4.3.5API信息整合
攻击者在尚未摸清网元服务API的工作方式时，需要对API进行试探性调用，再根据返回结果进行进一步攻击。试探性调用中所使用的请求方式和URL往往与网元服务正常工作时所使用的请求方式和URL是不同的，那么通过对历史数据中的API信息进行整合，可在攻击者进行攻击试探时及时发现。当然，这只是进行一项统计后去重的工作，没什么技术瓶颈，这里唯一需要讨论的问题是这项工作的必要性。其实在前面网元序列还原的工作中，已经加入了API信息，为什么还需要为API信息单独建立基线呢？根据基线构建思路中所描述的，预期得到的基线是将网元序列，API信息，参数信息整合后的结果。但在实际测试过程中，利用整合后的基线进行检测所得到的检测结果并不理想。原因是我们对高并发问题的处理方式是以用户标识为基准进行归并，没有进行用户标识传递的通信就会被忽略掉，从而导致序列的不完整。而在整合的基线下，序列的不完整会直接导致API信息和参数的不完整。若某次攻击试探行为没有发生用户标识的传递（这种调用是极有可能发生的），那么此次试探便会直接被原型漏掉。因此，我们不再利用多维度整合的基线进行检测，而是将网元序列，API信息，参数三个维度进行拆分，将拆分后的三个维度分别建立基线。经过检测测试，我们发现拆分后的基线比整合基线的表现更好。
生成的API信息基线如图14所示
图14 API信息基线示例
4.3.6参数字典构建
为进行网元服务API的传入参数异常检测，可利用历史数据生成参数字典，并以字典外的参数为异常参数。构建时需要注意的一点是，通信时传递的某些参数是不具备检测价值的，比如ueLocationTimestamp，这类参数通常具有以下特性：
1. 无规律性：每次通信时所传递的参数值几乎都是不同的。
2. 无参考性：给出该参数的一个特定值，无法判断该值是由正常业务还是异常调用引发的。
为了保证检测的质量和效率，需要在构建字典时尽可能地筛选出不具备检测价值的参数。其中一种相对简单的筛选方案为，针对某一特定API筛选出每次调用时取值都不同的参数。
生成的参数字典如图15所示
图15 参数字典示例
4.3.7参数阈值计算
核心网网元通信传递的某些数值型参数是连续型的，对于这类连续型参数，构建参数字典进行检测所得到的结果是不准确的，需要通过限定取值范围的方式来进行检测。取值范围的计算方式有很多种，这里我们选用了一种满足大部分参数分布的计算方法：利用正态分布的3σ定理。
图16中深蓝色区域是距平均值小于一个标准差之内的数值范围。在正态分布中，此范围所占比率为全部数值之68%，根据正态分布，两个标准差之内的比率合起来为95%；三个标准差之内的比率合起来为99%。
目前采用的阈值设定方案为将阈值设定在距平均值3倍标准差之内。生成的基线如图17
图17 参数阈值示例
4.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服务
| 服务名称 | 描述 |
| 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。 |
声明：本文来自绿盟科技研究通讯，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
