在5G网络仿真这个圈子里大家平时聊得最多的往往是峰值速率、频谱效率、时延预算、小区边缘吞吐量这些指标。很少有人会在研讨时追问一句你跑的那套仿真环境空口数据是不是裸奔的密钥协商在仿真里怎么建模网络突然收到几千个伪造的注册请求核心网会不会被打挂我这么说不是在抬杠——我见过不止一个团队把系统级仿真的链路跑得漂漂亮亮可一旦被问到这几个跟安全性相关的问题整个会场会安静三秒钟。今天我想把这件事摊开聊在5G网络仿真里安全性考虑到底覆盖哪些范围用什么工具能把真实威胁复现出来以及我在实操中踩过的坑和验证过有效的做法。这篇文章适合三类人负责5G系统仿真的工程师、刚接触5G但长期做安全测试的朋友以及高校里正在规划5G实训室方案、需要把安全实验纳入课程体系的老师。1. 先说清楚仿真里的5G安全到底指什么1.1 一个三维度的安全模型5G的安全模型比4G复杂得多它并不仅仅停留在手机和基站之间加个密这种单一层面。根据3GPP TS 33.501的定义5G安全至少可以拆成三个层次每一个层次在仿真里建模的方式都不同如果不先把这个结构理清楚后面很容易出现用系统级仿真的结论去解释协议级安全问题的错位。第一层是空口安全也就是UE和gNB之间的安全。主要包括PDCP层的加密与完整性保护、RRC信令的完整性保护以及SUCI机制。很多人会忽略4G到5G在这块的一个关键差异5G用户身份从明文IMSI改成了加密后的SUCI这是对非法监听设备直接回应。仿真里要复现这个机制意味着你的仿真工具必须完整支持NAS层的身份隐藏流程而不只是简单地把一个IMEI或者IMSI填进注册消息里。第二层是接口安全。gNB到核心网之间的N2/N3接口核心网内部各网络功能之间的服务化接口都要求传输层安全保护。在仿真里这块最容易被人跳过原因也很现实大量开源仿真工具默认不建模SCTP/TLS层导致很多人压根儿没意识到自己搭建的仿真环境里基站和核心网之间的信令通道是裸的。第三层是切片级别的隔离安全。5G引入网络切片之后eMBB、uRLLC、mMTC不同业务跑在不同逻辑网络上如果隔离策略没做好切片之间越权访问就是一个真实的攻击面。仿真里建模切片隔离除了要在核心网配置不同的SST/SD还要考虑无线侧调度器是否真正做到了资源隔离。我的建议是在动手之前先想清楚你这次仿真关注的是哪个层次的安全关注空口隐私就去选协议栈级的仿真工具关注核心网抗压就去搭一套完整核心网环境关注物理层抗干扰就用链路级仿真工具。没有一个工具能同时把三个层次的细节全部做好。1.2 为什么做容量仿真的团队最后都要补上安全这门课有个反直觉的现象真实5G网络里的安全配置并不总是越强越好。运营商为了兼容老终端、控制处理开销可能会在特定场景下选择相对弱的加密策略而仿真环境反而更理想化——协议栈代码里实现了哪些安全机制你就能在这套环境里观察到哪些行为。但在实际项目中安全考量往往会从可选功能变成一票否决项。我去年接触过一个室外5G远程驾驶无人车的仿真项目用户在验收时明确问了两个问题控制信令在空口是否加密如果核心网收到大量虚假注册请求业务面会不会中断这两个问题如果等仿真做完再去补返工成本非常高。所以我现在做任何一个5G系统仿真之前都会先花小半天确认一遍仿真环境里的安全上下文流程能不能跑通加密算法配置是不是默认空算法核心网网元遇到异常消息时的行为是什么。先回答这三个问题再谈容量和覆盖优化。2. 值得在仿真里建模的五类安全威胁2.1 空口窃听加密到底在哪里生效空口是无线网络中最容易被物理接近的部分也是最难防御的部分。在没有加密的情况下一台USRP软件无线电设备、一根天线、一台笔记本电脑配上一个开源协议分析工具就可以在空中抓到RRC消息、NAS消息甚至还原用户面应用层数据。在仿真里验证这个问题很简单。我通常用OAI搭建一个gNB让一个模拟UE正常完成注册并建立PDU会话同时在另一台机器上抓空口报文。如果PDCP和NAS加密都开了抓包结果只能看到密文载荷应用层内容不可读如果加密算法配置成NEA0抓包结果就是明文的。这组对照实验不是为了演示工具怎么用而是为了确认一个关键认知5G的加密不是全程加密它发生在PDCP层和NAS层而调度信息、部分RRC信令仍然可能暴露一些用户活动特征。仿真里做这个实验能直观看到哪些字段是加密的哪些字段依然可见。2.2 恶意小区与降级攻击SUCI挡不住所有招数5G通过SUCI机制让传统身份窃听设备直接抓取IMSI变得困难但攻击者还有其他路径。最常见的就是降级攻击部署一个信号更强或者优先级配置更优的恶意小区迫使UE发起重选或切换到4G网络然后在4G侧动手。这个威胁在仿真里很适合建模因为它的本质是小区选择与重选机制被操控。在系统级仿真里可以通过调整信道模型中的干扰参数、修改邻区优先级配置或者直接在仿真拓扑里加一个恶意gNB观察UE是否被诱导切换。更接近协议级的做法是在全栈仿真环境中修改系统信息块里的小区重选参数让UE认为某个不该驻留的小区是最高优先级然后观察它会不会真的发起注册流程。仿真里做这项工作最大的价值是能提前暴露重选参数配置中的安全漏洞——很多团队用默认配置跑仿真根本不知道自己的邻区关系表其实可以被外部消息影响。2.3 信令风暴与注册洪泛网元抗压能力的试金石核心网网元遭受异常海量信令冲击在真实网络里是大事故级别的场景。5G核心网采用服务化架构后网元之间的交互更加灵活但同时也扩大了被攻击面。仿真里复现信令风暴成本很低效果却非常直观。我常做的实验是在Open5GS或free5GC构成的5G核心网仿真环境里先跑出一组正常的100终端注册基线然后通过脚本批量发起Registration Request观测AMF的CPU、内存、注册成功率、注册时延四项指标的变化。更精细的做法是把流量分成混合流量一部分终端正常完成注册后进行周期性更新另一部分终端持续重复发送注册请求模拟僵尸网络式的并发连接。这种混合压力比单纯全速洪泛更接近真实攻击场景也更能体现核心网的调度能力。2.4 网元间接口攻击被长期忽略的横向面很多安全测试团队关注空口却忽略了核心网内部的横向移动。5G网元间接口包括N2、N3、Xn以及服务化接口一旦其中一个网元被攻破整个网络的信令面都可能被渗透。仿真里建模这类攻击既可以在系统层面操作也可以在协议层面操作。比如在仿真拓扑中引入一个伪造的Xn接口消息观察gNB之间会不会因为这个伪造的切换请求而错乱会话状态或者向N3接口注入恶意GTP-U数据包观察UE的下行业务面是否被干扰。更贴近实际的做法是在容器化核心网环境里用tc netem制造人为的网络延迟和丢包模拟一个被干扰甚至被劫持的传输链路看看核心网有没有超时重传或者异常断链的应对机制。这类实验在纯系统级仿真里不好做需要一套能真实跑协议栈的环境。2.5 网络切片边界的踩线问题切片隔离是5G安全架构里一个很独特的问题。两个切片共享同一套物理基础设施如果隔离策略没做到位一个切片的高负载业务可能挤压另一个切片的调度资源更严重的情况下一个切片的终端可能访问到另一个切片的网元。在仿真里我会配置两个不同SST的切片然后把其中一个切片的数据流量持续加大观察另一个切片的时延和吞吐量是否受影响。如果无线侧调度器没有做资源块级别的隔离这个实验很快就能暴露出问题。更深入的测试是验证切片的访问控制一个签约了切片A的终端尝试向切片B的网元发起服务请求如果核心网的NSSF和AMF配置正确这个请求应该被拒绝。很多开源核心网默认配置并不同时启用严格的切片访问控制如果你要做的项目对切片隔离有要求这个实验一定要提前跑。3. 仿真工具怎么选不同层次的安全仿真能力差异3.1 全协议栈开源方案OAI 5G与srsRAN当你需要复现协议级别的安全机制时OAI 5G和srsRAN是绕不开的两个名字。OAI支持完整的5G NR协议栈能够以纯软件方式运行UE和gNB再配合Open5GS或free5GC作为核心网基本就是一个能跑完整注册、鉴权、PDU会话流程的微型5G端到端环境。它的优势在于代码开源、协议栈完整加密算法列表可以在配置里明确指定。我在实验里会在OAI的配置文件中把PDCP加密算法从NEA0切换到128-NEA2然后用抓包工具对比密文和明文的特征差异这是链路级仿真工具做不到的。srsRAN则更侧重于UE侧和gNB侧的轻量化实现部署起来比OAI简单一些适合快速验证空口侧安全行为。这类全协议栈方案最大的门槛是部署。OAI涉及的依赖项多版本匹配要求严格纯软件运行时对CPU和内存也有要求。但如果你的核心目标是安全机制本身这一步投入是值得的。3.2 系统级仿真平台NS-3 5G-LENA与Vienna 5G仿真器系统级仿真器关注的是小区整体性能而不是单个信令流程。NS-3的5G-LENA模块提供了完整的NR用户面协议栈支持波束管理、调度、干扰建模安全方面的建模更多需要自己叠加——你可以在小区拓扑里增加一个干扰源或者在流量模型里模拟异常业务分布。Vienna 5G仿真器在设计上更偏向无线资源管理评估能输出非常详细的系统吞吐量、时延分布统计。对于安全性研究来说它适合用来评估当小区受到特定干扰或过载时整体服务的可靠性退化到什么程度但不适合用来研究具体某一条NAS信令是否加密。在选型时可以把这三类工具看作金字塔结构系统级工具负责评估安全事件对整体性能的影响全栈工具负责复现安全事件本身的协议过程。3.3 链路级与波形级仿真MATLAB 5G Toolbox如果你关注的安全本质上是物理层鲁棒性比如抗截获能力、抗干扰波形、跳频策略那MATLAB 5G Toolbox这类链路级工具是更合适的选择。你可以搭建NR下行链路在发射端设置加扰和调制参数在接收端引入干扰信号观察误码率和吞吐量随干扰功率的变化曲线。物理层安全研究里有一个常用思路把有用信号的功率控制得足够低让合法接收端的信噪比勉强达到解码门限而窃听端的信噪比低于可解调门限从而在物理层实现保密传输。这类实验必须在波形级别做系统级仿真器无法提供所需的物理层细节。如果你在做一个5G实训室方案想让学员同时看到协议安全和物理层安全两个层次比较务实的搭配是MATLAB做物理层演示OAI加核心网做协议层实验。3.4 选型对照与建议工具层级代表工具安全建模侧重点适用场景全协议栈OAI、srsRAN空口加密、鉴权流程、核心网信令协议安全验证、攻击注入实验系统级NS-3 5G-LENA、Vienna小区性能退化、干扰影响评估大规模网络场景安全性评估链路/波形级MATLAB 5G Toolbox物理层抗截获、抗干扰波形设计、物理层安全教学选型时先问自己一个问题这次要验证的安全性是某条消息的加密状态还是整个网络在攻击下的性能表现前者必须用全协议栈后者用系统级就够了。用系统级工具去做协议安全验证只会得到一堆抽象参数解释不了任何协议行为用全协议栈工具去跑大规模小区仿真则会被性能开销拖垮跑不出有统计意义的数据。4. 实操复现一次完整的注册洪泛实验是怎么跑的4.1 实验环境搭建与部署要点用一套全协议栈仿真环境来复现注册洪泛攻击我推荐的搭配是free5GC加OAI模拟UE或者直接用UERANSIM来模拟终端。UERANSIM实现的UE和gNB功能很轻量可以用脚本方便地批量启动非常适合做压力测试。硬件方面16GB以上内存的服务器可以跑通基础实验如果要做高并发洪泛建议用到32GB。主机操作系统我建议用Ubuntu 22.04编译OAI和free5GC时依赖问题会少一些。部署完成后先做一次单终端注册的冒烟测试确认完整流程能跑通UE发起注册AMF完成鉴权和密钥协商SMF建立PDU会话UE拿到IP地址并能ping通数据面。这里有个容易被忽略的细节OAI和free5GC之间对接时gNB使用的AMF地址配置、TAC、PLMN必须完全一致否则注册请求会在N2接口被直接丢弃。排查这类对接问题时最有效的工具是抓N2接口的NGAP消息看AMF回的是NGSetupFailure还是上下文建立失败以此判断是配置问题还是协议栈问题。4.2 从正常基线到攻击注入正常基线可以这样定义用脚本控制100个UERANSIM实例每个实例每隔3秒发起一次注册记录从发起注册到收到注册完成消息的时延。跑完一轮之后统计平均时延、P99时延和注册成功率这就是系统的正常体温。攻击阶段的思路不是简单地把注册请求数量翻倍。我自己更推荐这样做保持10个正常终端持续做周期性注册更新同时用另一组脚本快速创建200个临时终端每个终端发出1次注册请求后不等待响应立即断开连接并重建。这种短连接式的洪泛比长连接的持续压力更难防护因为它制造的是大量半开连接恰好能压到服务端的并发资源管理短板。如果需要更细粒度的攻击注入也可以不用UERANSIM直接向AMF的N1/N2接口构造NAS消息。类似做法是编写脚本直接发送大量合法的Registration Request消息但跳过后续的鉴权响应形成不完整会话。这类攻击在仿真里可以精确控制消息构造过程适合用来测试AMF对异常流程的处理逻辑。4.3 数据采集与结果解读实验过程中建议采集五个指标AMF进程的CPU使用率、内存占用、注册成功率、注册时延分布、AMF日志中等待处理的消息队列长度。采集工具不需要太复杂pidstat看CPUFree看内存UE侧打时间戳计算时延日志统计可以用简单的grep加awk完成。指标采集方式攻击前基线攻击后表现AMF CPUpidstat40%-60%接近100%注册时延UE侧时间戳平均约120ms平均3s以上注册成功率AMF日志统计100%60%消息队列长度AMF日志0-5持续200结果解读的关键在于区分瓶颈类型。如果攻击后CPU打满而注册成功率大幅下降说明AMF的处理能力是瓶颈解决办法是扩容或者限流如果CPU占用并不高但注册时延显著增加很可能问题出在并发调度或者锁竞争上如果注册成功率下降但系统资源都正常那就要去查AMF状态机的异常处理逻辑很可能是有大量未完成的半开会话卡在某个状态。我做过一次实验后发现攻击停止之后AMF并没有立刻恢复而是花了将近1分钟才把积压的队列消化完。这类恢复时间指标在实际安全评估中非常重要意味着攻击者只需要造成1分钟的过载就可能让正常用户在后续几分钟内持续感知到服务劣化。4.4 从注册洪泛扩展到其他接口压测同一个环境可以很容易地扩展到其他攻击面。比如用脚本对N3接口的UPF数据面发送大量无效GTP-U报文观察UE侧吞吐量是否被稀释或者往服务化接口的NEF模块发送大量HTTP请求观察网络能力开放功能有没有独立的防护机制。这也是我建议把仿真环境工程化的原因一旦你搭出了一套可重复执行的压力测试环境所有的攻击场景都可以沉淀成脚本。下次再有人问你这套5G仿真网络的安全性怎么样你不需要翻PPT直接跑三组脚本一组空口加密对照、一组注册洪泛、一组切片隔离测试数据摆出来结论自然就清楚了。5. 配置与参数细节这些地方最容易让仿真骗了你5.1 加密算法配置别把空算法当成正常配置OAI和free5GC的默认配置并不总是开启强加密。很多开源项目的默认配置为了便于调试会把NAS加密算法设为NEA0这样抓包就能直接看到明文。这在开发调试阶段没有问题但如果你忘了改配置就去做安全性验证得到的结果会完全失真——你会误以为这个5G网络没有加密能力实际上只是配置没有打开。我的习惯是每次做安全对照实验时先跑一组所有加密算法设为NEA0的全空配置抓包确认明文可见再把算法切换成128-NEA2重新跑同一组业务流抓包确认密文呈现。两组结果放在一起对比才能真实反映加密机制的贡献。顺便提一句在切换算法后建议重新观察CPU开销的变化加密带来的处理开销在低端服务器上会很明显这也是真实网络里需要考虑的取舍。5.2 密钥协商与身份隐藏的建模粒度如果你用系统级仿真器研究安全性几乎不可能观察到密钥协商的细节因为系统级仿真器根本不会建模NAS层安全上下文。但如果你用全协议栈工具就一定要注意SUCI和SUPI的转换流程是否完整。在free5GC里UE注册时先发送SUCIAMF调用UDM完成SUCI到SUPI的解析然后发起鉴权流程。如果这套流程在仿真里被简化掉那你后续复现重放攻击、中间人攻击时结论都是无效的——因为在真实协议里攻击者需要先破解身份隐藏机制才能伪装成合法用户。仿真里看到的行为必须建立在完整的安全上下文中不能拿一个简化模型去评价真实协议的健壮性。5.3 时钟同步、重放窗口这些容易被忽视的小事仿真环境里时钟同步问题往往被低估。核心网网元通过时间戳和序列号来防止重放攻击如果容器环境的时钟发生漂移很可能导致合法的重传消息被误判为重放攻击或者反过来让真正的重放攻击蒙混过关。我之前踩过这样一个坑在KVM虚拟机上跑OAI加free5GC业务一切正常但只要开启完整性保护校验注册流程就会间歇性失败。排查了一整天最后发现是虚拟机时钟漂移导致NAS层序列号校验错乱。解决方案也很简单在宿主机和虚拟机之间配置时间同步服务问题立刻消失。这类问题单独看起来和安全性没什么关系但在仿真环境下它就是会以安全机制异常的形式表现出来。5.4 切片参数保持一致别让配置错误变成安全隐患切片隔离实验里最典型的配置错误是各网元之间的SST/SD不一致。AMF配置了切片A和切片B但SMF只认切片A终端注册到切片B后PDU会话建立请求就会在某个环节被意外拒绝。这种问题虽然来源是配置错误但在安全测试中它常常会被误归因为切片访问控制生效导致你得出隔离策略很严格的错误结论。为了避免这个问题实验前要检查所有核心网网元的切片配置是否全局一致记录终端签约数据中允许的切片列表再设计测试用例。只有先确认合法流程畅通才能把异常拒绝归因于安全策略而不是配置疏漏。6. 我这几年踩过的坑以及给后来者的几条实用建议6.1 坑一默认配置下的空口加密为空这个前面已经提过但不妨再说一遍因为它太典型了。我做第一次OAI安全对照实验时抓包看到NAS消息里的IMSI、网络能力字段全部明文呈现先是怀疑OAI代码有bug后来检查配置文件才发现加密算法列表里只有NEA0。那次之后我给自己定了一条规矩任何全协议栈仿真环境部署完成后的第一件事不是跑业务而是抓包确认当前加密配置下哪些字段可见、哪些不可见把这个状态记录成文档。这比任何安全测试都重要。6.2 坑二攻击脚本设计得太理想化早期我做信令洪泛就是一上来发一万个注册请求结果AMF直接崩掉结论是该系统无防护能力。但这样的结论没有太大工程价值因为真实攻击者不可能只用一种流量模式打单点。现在我做压力测试一定会混合正常注册、周期更新、切换请求、紧急呼叫让攻击流量穿插其中。这样测试出来的结果才是系统在真实扰动下的表现而不是一个能不能被打死的极端问题。6.3 坑三只用平均指标评价安全性有一次实验结果里注册时延平均值只从120ms涨到了400ms团队差点给定论攻击影响有限。我坚持再看了分布数据结果发现P99时延已经超过5秒超时失败的比例也在快速爬升。平均值这个东西最会粉饰太平在安全评估里一定要看高百分位时延和失败码分布。现在我的实验报告里平均值只占一小块P99、P99.9、超时比例、从攻击开始到恢复的总时长才是主体内容。6.4 建议把安全回归测试纳入日常流程我越来越觉得仿真里的安全性考虑不应该是一次性的专题实验而应该沉淀成一套可反复执行的回归测试。每次升级OAI、free5GC或者修改核心网配置之后都重新跑一遍空口加密对照、注册洪泛、切片隔离三组用例确认没有引入新的行为变化。这套回归脚本的价值不仅在项目交付阶段更在后续维护和二次开发时。仿真里的安全性考虑说到底不是让你在项目文档里多写几页安全架构图而是让你用尽可能低的成本提前看到真实攻击在协议栈里的呼吸和扰动。我的习惯是每个项目收尾时留一套一键可跑的安全回归脚本哪怕只是最基础的注册洪泛加加密对照。下次有人再问你们这套5G网络仿真安全性是怎么考虑的我直接把命令行敲一遍给他看。数据摆在那里比任何文字说明都有说服力。