5GC控制面异常检测策略
2021-08-10 10:12:51 Author: blog.nsfocus.net(查看原文) 阅读量:75 收藏

阅读: 12

一、引言

在正式开始本文的内容之前,先简要回顾下5G安全专题文章中关于5G核心网(以下简称5GC)网元服务异常检测已有的工作。新架构,新挑战:5G核心网业务安全问题与异常检测一文中将5GC网元服务安全问题分为序列异常,参数异常和频率异常三类并针对这三类安全问题给出了解决方案。如何用全流量检测5G核心网网元服务异常一文通过实际分析5GC流量数据,从调用序列,API操作,请求和响应参数三个维度建立检测基线,得出检测结果。本文将从5GC整体架构入手,更加宏观且全面地阐释5GC所面临的安全隐患与相应的检测策略,并结合5GC领域知识,深入业务流程,给出更细粒度的基线建立方案。除此之外,本文针对此前工作遗留的误报问题,利用机器学习的方法对检测参数进行了筛选。目前,大部分误报已被解决,同时所有真正攻击行为所产生的异常信息都被完整保留下来。

二、检测策略

2.1 检测思路

若是将5GC比做一座城,那么安全策略的部署便是一个守城任务。异常检测作为其中的一环,需要在合适的位置设置岗哨,以便在攻击行为发生时,防守方可以快速且准确地做出响应。对于岗哨的设置,预期是能够全面地监测城中所发生的各个事件,且每个岗哨都足够警醒,在某个事件出现异常或攻击行为发生时,能够及时准确地上报给防守方。

基于这个目标,结合5GC自身特征,提出检测方案如下:

  1. N1,N2,N4作为5GC控制面的三个对外接口,便是整座城的入口,需要重点防护。
  2. 5GC采用SBA服务化架构,城中各个网元依托于既定的架构进行部署,那么岗哨的其中一项任务便是监控城中所发生的各个事件是否有违反既定架构的。
  3. 5GC的正常运行主要依托网元之间的通信,任意两个网元之间通信的内容是否存在异常也是岗哨需要验证的内容之一。
  4. 此外,盼望岗哨可以更敏锐一些,可以熟悉城中发生过的各个事件,能够针对5GC中所发生的各个业务流程及时地做出反馈。
图1 基于服务的5GC架构图

2.2 5G协议安全

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

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

图2 利用会话修改流程进行数据窃取

针对5G协议所带来的安全风险,完善的检测机制需要建立在协议自身脆弱性分析与对各个协议所负责业务流程的准确还原的基础上,使用规则与基线配合的方式进行异常检测。

2.3 网络架构安全

5GC网络架构在流量数据上所体现的特征为网元调用序列。网元调用序列的还原,基线的建立与异常检测工作在新架构,新挑战:5G核心网业务安全问题与异常检测,如何用全流量检测5G核心网网元服务异常两篇文章中已经进行了完整介绍,这里就不赘述了。大家若是想了解这方面的工作,可以参照以上两篇文章。

2.4 网元交互安全

5GC控制面网元间采用API进行通信,那么针对网元交互的异常检测需要以API请求方式,请求路径和请求参数三个特征建立基线。如何用全流量检测5G核心网网元服务异常一文中已经给出了特征提取和基线建立的方法,但也留下了一个问题——参数筛选机制的不完善导致检测结果中存在大量误报。

先以5GC网元交互过程中传递的一个参数RES*为例,先看下误报产生的原因。根据3GPP TS 33.501[1],RES*为5G AKA认证方式的鉴权标志之一。RES*的数据格式是固定的,都为32位的16进制数,但其数值几乎无重复。如果将RES*以数值标准放进检测基线中,那么每次在5GC进行5G AKA认证流程时,几乎都会产生告警。虽然在已有的一个攻击场景中,攻击者在不清楚RES*具体值的前提下,传递进了一个异常值,但在正常业务运行也会产生相同告警的前提下,此次异常行为是无法被排查出来的,那么针对RES*的单值检测便是没有价值的。此时,可以用RES*的正则式“[A-Fa-f0-9]{32}”作为检测标准。

图3 攻击未知RES*进行SUPI窃取

为了有效规避上述误报,提升检测效率,我们根据参数的统计特征,利用SOM神经网络,进行了参数筛选工作。实现参数筛选基于以下两个基本特征:

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

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

基于以上两个统计特征,可利用机器学习算法对参数进行聚类。考虑当前要解决的聚类问题满足 

与神经网络中基本的感知机模型较为契合,因此,选用SOM神经网络进行聚类。

图4 SOM神经网络聚类结果
图5 参数筛选模型聚类结果

在free5gc实验环境中,我们对参数筛选模型进行了测试,图4中颜色深浅代表节点间距,颜色越浅的地方节点越集中。结合已有的攻击场景与检测原型的输出结果,从图5输出的参数中选择包含真正异常参数的某些节点及其邻近节点,并重新定义检测原型的检测指标。经过测试,之前所产生的大部分误报被成功规避掉。

2.5 业务流程安全

在检测原型中引入更多的5GC领域知识,建立更细粒度的基线,可以更加有效地实现异常检测工作。5GC已将网络功能虚拟化,软件化,各个网元以容器或进程的形式运行在5GC中,和电商平台,社交平台等业务平台一样,5GC中所发生的每一个事件都可以理解为一次业务流程的进行。

上一节对RES*的探讨停留在以正则式为标准进行检测上,在这里再考虑一种更加艰难的情况:当攻击者十分精明且对5GC业务足够了解的时候,即使无法获得RES*的准确值,也可向相应的接口传递同正则的RES*。在这种情况下,只对RES*进行检测是无法判断异常的,此时便需要防守方在对业务流程的掌控上再高于攻击者一些,将5G AKA认证流程融入原型中,在RES*的不正确时,其返回值为AUTHENTICATION_FAILURE,从返回值的异常进行回推,可实现对RES*的异常检测。

图6 攻击者设置同正则RES*进行SUPI窃取

在进一步探讨5GC的业务流程安全之前,先为大家介绍下用户实体行为分析(以下简称UEBA)在电商平台业务安全中的一个应用场景[2]。

针对电商平台的刷单行为,检测模型构建业务特征和策略主要基于以下三个维度:1)交易主体,包括用户和商家;2)交易环节,包括买家注册/登录,搜索或图墙(各个类目下商品的自然排序),浏览商品,销售/沟通,加入购物车/收藏,支付/下单,收货/发货,评价与追评等8大环节;3)交易依赖,包括支付和物流。建立刷单模型时要从业务的角度出发,利用必要的数学背景知识,从上述三个维度描述交易作弊的概率。

平台业务安全中已有的UEBA策略确实可以为5GC业务流程安全带来一些启发。5GC服务的主体是用户,每个用户都有彼此区分的身份标识(SUPI/SUCI/GUTI等)。5GC的服务提供者是网元,每个网元都有唯一的身份标识(nfInstanceId)。用户上网的基本环节为UE注册,订阅认证,切片选择,策略选择,存储更新,会话建立,网络资源访问。单从业务行为看,已有的UEBA策略似乎可以移植到5GC场景中,根据业务的时序关系和各个环节的关键指标可以建立基线。但电商平台的刷单行为是已有的,被黑产广泛利用的场景,而5GC中目前还没有这种场景出现,那么各个环节的关键特征和各项特征的权重都是难以提取的。虽然盼望是5GC中不会有类似刷单这种可以被黑产利用的问题出现,但5GC中是否会存在这种问题目前还不得而知。还需要对各个业务流程可能的存在问题进行分析,未雨绸缪,在真正的攻击行为发生前为5GC提供有效的保障。

三、结束语

本文站在防守方的视角,将5GC控制面安全分为5G协议安全,网络架构安全,网元交互安全和业务流程安全四类。结合之前的工作,在网络架构安全和网元交互安全方面,当前已经有了较为成熟的解决方案。在协议安全方面,下一步还需要对N1,N2,N4接口协议可能存在的脆弱性进行分析和验证。在业务流程安全方面,可以从一些常用的业务环节入手,对业务流程可能存在的风险进行评估。盼望5GC作为万物互联的基础设施之一,可以高效且安全地为大家提供便利。

参考文献

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

[2]https://yun.weicheng.men/Book/%E6%9C%BA%E5%99%A8%E5%AD%A6%E4%B9%A0%E4%BA%92%E8%81%94%E7%BD%91%E4%B8%9A%E5%8A%A1%E5%AE%89%E5%85%A8%E5%AE%9E%E8%B7%B5.pdf

版权声明

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


文章来源: http://blog.nsfocus.net/5g-c/
如有侵权请联系:admin#unsafe.sh