当前位置：首页 > news >正文

5G核心网与网络切片渗透测试：从协议解析到云原生安全的实战指南

news 2026/7/27 9:01:00

1. 项目概述：为什么5G核心网与切片安全测试是当下必修课

最近几年，我身边越来越多的安全研究员和渗透测试工程师开始把目光从传统的Web应用、内网渗透，转向了5G核心网和网络切片这个领域。这绝不是跟风，而是因为5G网络正在从“通信管道”演变为“数字社会的基石”，其安全边界直接关系到工业互联网、车联网、远程医疗等关键业务的命脉。一个针对5G核心网或特定网络切片的成功渗透，其破坏力远超攻破一个普通网站。然而，这个领域的技术门槛高、资料零散，很多朋友想入门却不知从何下手。

“5G核心网与网络切片渗透测试”这个项目，就是旨在系统性地拆解这个复杂目标。它不是一个简单的工具使用教程，而是一套从零构建测试环境、理解核心协议、定位攻击面、再到实施实战演练的完整方法论。简单来说，它要解决三个核心问题：第一，面对一个完全云化、服务化的5G核心网，攻击面在哪里？第二，网络切片作为5G的“杀手锏”特性，如何对其进行隔离性测试和越权访问？第三，如何将传统的渗透测试思维，适配到3GPP协议栈和电信级架构中？无论你是想拓宽技术视野的安全从业者，还是负责运营商或垂直行业安全的工程师，掌握这套技术都将让你在未来的竞争中占据先机。

2. 核心需求与攻击面全景解析

2.1 5G核心网渗透测试的独特挑战

与传统IT网络渗透测试相比，5G核心网测试面临的根本性挑战在于其架构和协议的复杂性。5G核心网基于SBA（服务化架构），各个网络功能（NF）如AMF、SMF、UPF、UDM等，通过基于HTTP/2的SBI（服务化接口）进行通信，并使用NRF（网络存储库功能）进行服务发现。这带来几个全新的攻击面：

协议栈的转变：从传统的TCP/IP套接字，转向了基于TLS的HTTP/2和JSON格式的OpenAPI。这意味着你熟悉的Nmap端口扫描、Burp Suite抓包分析，都需要新的配置和理解。你需要能解析3GPP TS 29.500系列规范中定义的API消息。
身份的复杂性：5G中有SUPI（用户永久标识符）、SUCI（SUPI的加密版本）、GPSI（通用公共订阅标识符）、PEI（永久设备标识符）等多种标识符。攻击者可能通过身份混淆、标识符泄露或伪造来实施攻击。
云原生环境：5G核心网通常部署在Kubernetes等云原生平台上。攻击面从虚拟机蔓延到了容器、容器镜像、编排系统API、服务网格（如Istio）。一次成功的渗透，可能始于一个配置不当的Kubelet API，最终拿到核心网NF的权限。
内部接口暴露：在测试环境中，许多用于NF间通信的SBI接口（Nnrf, Nausf, Namf等）可能对外暴露。这些接口本应在安全的服务网格内通信，但配置失误可能导致其暴露在公网或测试网络可达的范围内，成为绝佳的入口点。

2.2 网络切片安全测试的核心诉求

网络切片是5G为不同业务提供差异化服务的关键。一个切片可以看作一个逻辑上独立的端到端网络，包含特定的核心网控制面、用户面功能和资源。对切片进行渗透测试，核心目标是验证其“隔离性”是否被真正实现。主要测试方向包括：

切片选择策略绕过：用户设备（UE）在注册网络时，会通过NSSAI（网络切片选择辅助信息）请求接入特定切片。测试需要验证，一个低权限切片（如公共物联网切片）的用户，能否通过篡改NSSAI、利用AMF或NSSF（网络切片选择功能）的逻辑漏洞，非法接入高安全等级切片（如电力切片、警务切片）。
切片内横向移动：假设攻击者已通过某种方式（如利用UE漏洞）接入了一个切片。需要测试在该切片内部，能否从一个NF（如某个UPF）突破隔离，访问到同一切片内其他NF，甚至控制面的敏感数据。这涉及到容器网络策略、服务网格安全策略的测试。
切片管理面攻击：网络切片的生命周期管理（创建、修改、删除）通常通过CSMF（通信服务管理功能）、NSMF（网络切片管理功能）等完成。这些管理接口如果存在未授权访问、命令注入等漏洞，攻击者可以直接创建恶意切片或篡改现有切片配置，造成更大范围的破坏。
共享资源冲突：某些底层资源（如物理服务器、交换机带宽）可能被多个切片共享。测试需要关注是否存在通过耗尽共享资源（资源枯竭攻击）来影响其他切片服务质量的攻击方式。

3. 测试环境搭建与核心工具链

3.1 实验室环境构建方案

实战是学习的唯一途径。搭建一个可供安全测试的5G核心网环境是第一步。对于个人研究者或小型团队，我推荐以下两种高性价比方案：

方案一：基于Open5GS和UERANSIM的开源套件这是目前最流行、资源要求相对较低的方案。Open5GS实现了5G核心网的各个NF，UERANSIM则模拟了gNB（基站）和UE（用户设备）。你可以在单台性能尚可的Linux服务器（建议16GB内存以上）上，通过Docker Compose一键部署。

# 克隆仓库 git clone https://github.com/open5gs/open5gs git clone https://github.com/aligungr/UERANSIM # 使用docker-compose部署Open5GS核心网 cd open5gs/docker docker-compose up -d # 编译并配置UERANSIM cd UERANSIM make # 配置gNB和UE的配置文件，指向Open5GS的核心网IP

这个环境能完整跑通5G注册、PDU会话建立等流程，所有NF间的SBI接口流量清晰可见，是学习协议交互和进行基础接口测试的绝佳沙箱。

方案二：商用核心网的测试/开发镜像一些电信设备供应商会提供轻量化的核心网软件版本或虚拟机镜像，用于演示和开发。虽然可能功能受限或有许可限制，但其协议实现更接近现网，能接触到更多厂商特定的实现细节和潜在配置点。获取这类资源通常需要与厂商的合作伙伴计划接触。

注意：无论采用哪种方案，务必在完全隔离的物理或虚拟网络中运行（如独立的VLAN、不连接互联网的虚拟机组）。测试过程中会产生大量的信令和可能具有攻击性的流量，必须确保不会影响到任何生产网络。

3.2 渗透测试专用工具链选型与配置

工欲善其事，必先利其器。针对5G和切片测试，需要对传统工具进行改造，并引入一些新工具。

流量捕获与分析工具：Wireshark是基石，但必须导入最新的3GPP 5G协议解析插件（如ngap、nas-5gs），才能正确解析NGAP、N1 NAS等空口和N2接口消息。对于SBI接口（HTTP/2），tcpdump抓包后导入Wireshark分析是可行的，但更高效的是使用mitmproxy。将其配置为上游代理，拦截并解码NF间的HTTP/2 TLS流量，可以实时查看、修改JSON格式的API请求/响应，效率远超在Wireshark中手动重组流。
API模糊测试与漏洞扫描工具：核心网SBI接口本质是一套RESTful API（基于OpenAPI 3.0规范）。因此，传统的API安全测试工具大有用武之地。
- Burp Suite Professional：配置其上游代理为mitmproxy，或直接让被测NF的流量经过Burp。使用Burp的Scanner对API端点进行主动扫描，同时利用Repeater和Intruder模块对关键参数（如SUCI、切片IDS-NSSAI）进行篡改和模糊测试。
- OWASP ZAP：开源替代方案，同样支持自动化API扫描和手动测试，适合预算有限的团队。
- 专门针对3GPP API的模糊测试框架：可以基于Schemathesis等工具，结合从3GPP规范网站下载的OpenAPI描述文件（如果被测系统提供），自动生成并发送大量符合语法但语义异常的测试用例，寻找协议解析漏洞。
云原生/容器环境测试工具：如果核心网部署在K8s上，以下工具必不可少。
- kube-hunter：由Aqua Security开发，用于攻击Kubernetes集群本身，寻找错误的配置（如开放的Dashboard、允许匿名访问的kubelet等）。
- Trivy：扫描容器镜像中的已知漏洞。
- Calico等CNI的安全策略审计工具：检查网络策略是否真正实施了切片间或切片内的隔离，是否存在过于宽松的allow-all规则。
定制化脚本与工具：很多测试需要定制开发。例如，用Python的scapy库定制化构造和发送NGAP/NAS消息；用Go或Python编写脚本，模拟恶意UE，批量尝试非法的NSSAI组合进行切片选择绕过测试。

4. 渗透测试实战路径拆解

4.1 第一阶段：信息收集与侦察

5G核心网的侦察与传统网络不同，目标不是IP和端口，更是网络功能实例和服务。

服务发现（NRF侦察）：NRF是5G SBA的“服务注册中心”。首先尝试发现NRF的地址（可能通过DNSnrf.5gc.mnc<MNC>.mcc<MCC>.3gppnetwork.org或已知IP）。找到后，调用其nnrf-disc服务（如GET /nnrf-disc/v1/nf-instances），可以枚举出当前网络中注册的所有NF实例及其提供的服务类型（如AMF,SMF）、状态和接入地址。这相当于拿到了一张完整的核心网“地图”。
API端点枚举：对于发现的每个NF，尝试访问其API根路径（如https://amf.example.com/namf-comm/v1），并尝试获取其OpenAPI文档（通常位于/openapi.json或/v3/api-docs）。这份文档详细列出了所有可用的操作和参数，是后续测试的蓝图。
切片信息泄露：通过NRF查询或直接访问NSSF，尝试获取网络中被允许的切片列表（S-NSSAI）。某些配置不当的接口可能会返回过多信息，包括为特定企业客户配置的私有切片标识符。

4.2 第二阶段：协议与接口漏洞测试

这是测试的核心，针对的是3GPP标准实现中的缺陷。

NAS消息安全测试：N1接口上的NAS（非接入层）信令是UE与AMF之间的直接对话。测试点包括：
- 注册请求篡改：拦截UE的Registration Request消息，篡改其中的SUCI（使用无效或恶意的公钥标识Home Network Public Key Identifier）、5G-GUTI或Requested NSSAI。观察AMF是否进行了充分校验，是否会引发异常状态或错误地允许注册。
- 重放攻击：捕获一次完整的认证流程消息（包括Authentication Request/Response），在稍后时间点进行重放，测试网络是否能检测到。
- 降级攻击：尝试强制NAS信令安全算法降级到较弱的加密或完整性保护算法（如NEA0/NIA0，即空算法）。
SBI接口安全测试：这是HTTP API测试的主战场。
- 认证与授权绕过：许多SBI接口使用OAuth 2.0或基于TLS的双向认证。测试是否存在无需令牌即可访问的端点；测试令牌的校验逻辑，尝试使用为其他NF签发的令牌访问本NF接口（横向越权）；测试令牌的权限范围，尝试用低权限令牌执行高权限操作（垂直越权）。
- 输入验证与注入：对API的所有输入参数进行测试。例如，向UDM的/nudm-sdm/v1/{supi}/am-data接口的supi参数注入特殊字符或路径遍历符(../)；向SMF创建会话的请求体中的DNN（数据网络名称）或S-NSSAI字段注入超长字符串、JSON畸形数据。
- 业务逻辑漏洞：这是最可能发现严重漏洞的地方。例如：
  - 切片订阅检查绕过：模拟一个未订阅“切片A”的UE，但在PDU会话建立请求中明确请求“切片A”。检查SMF和PCF（策略控制功能）是否会严格执行订阅检查，还是仅依赖UE提供的NSSAI。
  - 会话劫持：通过某种方式（如从日志、其他漏洞）获取到一个有效PDU会话的上下文信息（如PDU Session ID,UE IP）。尝试向SMF发送修改会话的请求，将该会话的UPF指向一个恶意UPF，实现流量劫持。

4.3 第三阶段：网络切片隔离性专项测试

此阶段聚焦于切片的核心安全承诺——隔离。

控制面隔离测试：
- 假设已通过漏洞获得“切片A”中某个NF（如一个AMF实例）的有限权限。尝试从该AMF发起请求，访问NRF，查询并尝试与“切片B”的SMF实例通信。这测试的是服务网格（如Istio）的AuthorizationPolicy或NF自身的切片感知能力是否生效。
- 尝试修改“切片A”的NF配置，将其服务注册到NRF时使用的nfType或sNssais属性篡改为包含“切片B”的标识，观察“切片B”的NF是否会错误地接受来自这个“间谍”NF的请求。
用户面隔离测试：
- UPF是数据转发的实体。测试不同切片的UPF之间在数据链路层/网络层是否真正隔离。例如，为“切片A”分配的UE IP地址段是10.0.1.0/24，为“切片B”分配的是10.0.2.0/24。在获得“切片A”内一台主机的访问权后，尝试直接ping或连接10.0.2.1地址。如果通信成功，则说明底层网络（VxLAN、VLAN或防火墙规则）隔离失败。
- 测试UPF的流量导向策略。创建一个PDU会话，请求访问互联网（DNN为internet）。然后，在UE侧尝试访问一个本应通过另一个专用切片（如enterpriseDNN）才能访问的内部服务器地址。观察流量是否被正确隔离，还是错误地路由了出去。
管理面隔离测试：
- 寻找并测试CSMF/NSMF的API。尝试使用一个低权限账户（如切片租户用户）调用创建或修改切片的接口，目标是创建能与其他切片通信的“桥接”切片，或修改现有切片的隔离策略。

5. 高级攻击场景与后渗透思路

在基本漏洞利用之后，真正的威胁来自于攻击者立足核心网内部的持续活动。

持久化驻留：在容器化环境中，攻击者可能通过以下方式持久化：
- 部署恶意容器：如果获得了K8s集群的部署权限，可以部署一个伪装成合法NF（如一个无状态的NRF副本）的恶意容器，该容器持续窃听服务发现请求或篡改响应。
- 篡改NF镜像：如果攻破了镜像仓库，可以在基础镜像或特定NF镜像中植入后门，导致每次滚动更新都会引入恶意代码。
- 利用服务网格Sidecar：在Istio架构中，每个Pod都有一个Envoy sidecar代理。攻击者如果控制了某个NF，可能会尝试篡改其sidecar的配置，将流量镜像到攻击者控制的收集器。
横向移动与权限提升：
- 利用NF间信任关系：5G NF之间通常基于TLS证书进行双向认证。如果攻击者窃取了一个NF的私钥和证书，就可以冒充该NF与网络中其他NF通信。例如，窃取一个SMF的证书，就可以冒充SMF向UPF下发流量规则（PFCP协议），实施流量劫持。
- 攻击共享数据库：UDM/UDR（统一数据管理/存储）存储了所有用户的关键数据。一旦突破UDM/UDR，不仅可以盗取海量用户数据，还可以篡改用户的订阅信息、服务质量策略，甚至将用户“克隆”到另一个切片。
拒绝服务（DoS）攻击：
- 信令风暴：模拟海量恶意UE，向AMF发起高频的注册请求，消耗AMF的CPU和内存资源，导致合法用户无法接入。
- 资源耗尽：针对特定切片，建立大量PDU会话但不释放，耗尽该切片分配的UPF资源（如IP地址池、会话表项）。
- 服务网格过载：向Istio Pilot等控制平面组件发送大量非法配置，导致其瘫痪，进而影响整个服务网格的数据平面。

6. 防御视角与安全加固建议

从攻击中学习防御，才是渗透测试的最终目的。基于上述测试经验，给运营5G核心网的团队几点关键加固建议：

最小化暴露面：严格遵循零信任原则。所有NF间的SBI接口绝不应直接暴露在互联网或非信任域。必须通过API网关、服务网格的入口网关进行严格管控，并实施基于身份的细粒度访问控制。
强化API安全：
- 对所有API实施严格的认证和授权：使用双向TLS（mTLS）进行NF间认证，并结合OAuth 2.0进行细粒度授权。JWT令牌必须包含明确的NF类型、实例ID和所属切片信息。
- 实施全面的输入验证和输出编码：对所有OpenAPI定义的参数进行严格校验，拒绝任何不符合规范的请求。对返回给用户或NF的数据进行编码，防止注入。
- 启用API限流和配额管理：防止针对API的DoS攻击和资源滥用。
确保切片隔离的纵深防御：
- 网络层：使用不同的VLAN/VxLAN网络标识符或不同的虚拟路由转发（VRF）实例来隔离不同切片的用户面数据。
- K8s层：使用NetworkPolicy严格限制Pod间的通信，确保同一切片内的NF可以通信，而不同切片的NF默认拒绝所有流量。
- 服务网格层：利用Istio的AuthorizationPolicy，定义基于NF身份和切片标签的访问规则（例如：仅允许来自标签为slice=embb的namespace的amf服务访问标签为slice=embb的smf服务）。
- NF应用层：在NF代码逻辑中，显式检查请求上下文中携带的切片标识（S-NSSAI），拒绝跨切片的非法请求。
持续监控与威胁检测：
- 在NRF、API网关等关键节点部署专门的安全信息与事件管理（SIEM）或扩展检测与响应（XDR）探针，收集所有服务发现和API调用日志。
- 建立针对5G核心网的异常行为基线模型。例如，一个SMF实例突然开始向非关联的UPF发送PFCP会话建立请求，或一个UE在极短时间内尝试切换多个不同的切片，都应触发高级别告警。
- 定期进行渗透测试和红蓝对抗演练，将上述测试方法常态化，主动发现和修复潜在脆弱点。

7. 常见问题与实战排错记录

在实际测试中，你会遇到各种预料之外的问题。这里记录几个我踩过的坑和解决方法，希望能帮你节省时间。

问题：使用UERANSIM注册UE时，一直提示“Authentication Failure”（认证失败）。
- 排查思路：5G认证流程涉及UE、gNB、AMF、AUSF/UDM多个网元。首先在Open5GS的AMF日志中查看详细错误码。
- 常见原因与解决：
  - SQN同步失败：这是最常见的原因。5G使用基于序列号（SQN）的AKA认证。UDM中存储的SQN与UE USIM卡中的SQN不同步。解决方法：在Open5GS的UDM数据库（MongoDB）中，找到对应用户（supi）的记录，将其中的sqn字段改为一个较小的值（如0），然后重启UE尝试。在生产环境中，这需要运营商网元与USIM卡进行同步管理。
  - UE配置错误：检查UERANSIM中UE配置文件（ue.yaml）的supi、key、op/opc等参数是否与Open5GS UDM中配置的完全一致。op/opc的算法（MILENAGE）和密钥必须匹配。
  - 核心网配置错误：检查Open5GS的AUSF和UDM配置，确保认证算法（milenage）已启用且配置正确。
问题：Burp Suite或mitmproxy无法拦截到NF间的HTTP/2流量。
- 排查思路：NF通常使用TLS加密通信，且可能使用HTTP/2 over TLS (h2)。
- 解决方法：
  - 导入CA证书：将Burp或mitmproxy的CA证书安装到运行NF的服务器或容器的系统信任根证书库中。对于容器，可能需要构建一个包含该CA证书的自定义基础镜像。
  - 配置NF使用代理：修改NF的部署配置或环境变量，使其HTTP客户端将代理设置为Burp/mitmproxy的地址和端口。例如，在Docker或K8s的部署文件中设置HTTP_PROXY和HTTPS_PROXY环境变量。
  - 使用透明代理模式（高级）：如果无法配置NF，可以在网络层面进行流量劫持。例如，使用iptables将目标端口为特定SBI端口（如29518 for NRF）的流量重定向到Burp的透明代理端口。这需要更复杂的网络配置。
问题：在测试切片隔离时，不同切片的UE之间似乎仍然能ping通。
- 排查思路：隔离可能在不同层面失效。
- 排查步骤：
  1. 检查UPF配置：确认每个切片是否使用了不同的UPF实例或同一UPF的不同分组（如不同的gtp-u隧道端点）。查看UPF的配置，确认其路由表或策略规则是否基于切片ID进行了区分。
  2. 检查容器网络：如果UPF是容器，使用kubectl exec进入UPF容器，执行ip route或iptables -L -n -v，查看其网络命名空间内的路由和防火墙规则，确认是否有规则错误地将不同网段的流量桥接。
  3. 检查底层网络：如果UPF是虚拟机或物理机，检查其连接的交换机端口VLAN配置，以及主机上的网桥或VRF配置，确保不同切片的流量在二层/三层被隔离。
  4. 测试路径：进行逐跳测试。从“切片A”的UE traceroute到“切片B”的UE IP，观察路径在哪里发生了交汇，那里就是隔离失效的点。
问题：对NRF的服务发现接口进行模糊测试时，导致NRF服务崩溃。
- 经验心得：这是压力测试和稳定性测试的一部分，但也说明了测试环境的重要性。
- 建议：
  - 在测试环境进行：确保你的测试环境与生产环境完全隔离，并且可以随时重置。
  - 监控资源：在测试时，使用kubectl top pod或docker stats监控NRF容器的CPU和内存使用情况。如果发现资源急剧上升，及时停止测试。
  - 分析崩溃原因：收集NRF的崩溃日志、核心转储文件。分析是内存耗尽、空指针解引用，还是JSON解析库的漏洞。这本身就是一个有价值的安全发现，可以反馈给开发团队修复。
  - 实施优雅降级：在测试计划中，应包含对NF健壮性的测试，但也要避免使用明显会导致服务不可用的攻击（如发送超大内存消耗的单个请求），除非这就是测试目标。更有效的方法是模拟缓慢的HTTP攻击或并发连接耗尽。

掌握5G核心网与网络切片的渗透测试，是一个需要持续学习、动手实践和深度思考的过程。它要求你不仅懂安全，还要懂电信网络、懂云原生、懂协议细节。这条路不容易，但每当你成功复现一个协议漏洞，或发现一个切片隔离的缺陷时，那种攻克复杂系统的成就感是无与伦比的。我个人的体会是，从搭建第一个Open5GS环境跑通流程开始，到能够自主设计针对某个NF的模糊测试用例，这个过程本身就是对系统性工程思维最好的锻炼。建议你找一个具体的、细分的点（比如先把UE注册认证流程中的安全机制彻底搞透），深挖下去，建立起自己的知识图谱和方法论，然后再逐步扩展到更广阔的领域。

查看全文

http://www.jsqmd.com/news/1273016/