这个系列写到第15期，前前后后聊了不少关于5G网络仿真的组网、协议栈、参数调优和实测分析。按计划这期该说安全了，但我得提前说一句：这块在仿真圈子里，确实是长期被忽视的角落。很多人搭好一套基于OAI、ns-3或OMNeT++的5G仿真环境，第一反应是调吞吐量、测时延、看切换，很少有人会认真想"我这个仿真网络本身是不是安全的"。可实践证明，如果一开始不在仿真里考虑安全问题，后续所有实验结论都可能失真，而且仿真平台本身也会面临真实的攻击风险。
这期内容聚焦在"5G网络仿真中的安全性考虑"，我打算从威胁模型、安全机制、实操配置、问题排查几个角度，把仿真里真正值得关注的安全点全部过一遍。不管你是高校5G实训室的老师、做无线协议栈研究的同学，还是想验证5G安全方案的工程师，这篇文章都尽量按"能直接参考"的标准来写。
1. 为什么说仿真的安全问题不是"以后再说"的事
先说个容易混淆的概念。我们平时说的"5G网络仿真"，其实包含两种完全不同的形态。一种是用System-Level模拟器，比如ns-3、OMNeT++配合Simu5G这种，跑的是数学建模出来的信道模型和协议流程，空口信号是虚拟的，所有网元都是模拟计算。另一种是像OAI这种"真实代码仿真"，也就是把5G协议栈用开源软件完整实现，gNB、AMF、SMF、UPF、UE都是真实运行的进程，甚至可以用软件无线电设备把空口信号发到真空中去。这两种形态，对安全问题的处理方式完全是两回事。
在纯模拟器里，安全更多是"配置项"而不必太担心被真实攻击。比如ns-3里你可以打开或关闭某个安全算法，模拟一下恶意节点行为，但攻击者很难真的攻破一台模拟节点——因为节点只是内存里的一段模组。这个阶段的重点是把安全逻辑建模正确，不要为了简化直接把加密、鉴权全部关掉，导致实验结果完全脱离真实5G的行为。这一点很多做仿真的同学容易偷懒，默认配置里明明带了安全机制，非要图省事改成全明文，结果测出来的注册流程、切换时延都变了味。
在OAI这种真实代码仿真里，就完全不一样了。你拉起来的那一套网元，跑的是真正的SCTP连接、真正的GTP-U隧道、真正的NAS信令。它监听的端口在操作系统层面是真实开放的，它发送和接收的数据包是真实走网卡的。也就是说，一个旁路的攻击者完全可以用抓包工具嗅探信令，可以尝试连到AMF的端口上，甚至可以通过构造畸形包去探测协议栈的处理逻辑。仿真环境并不会因为"只是测试网络"就自动拥有免死金牌。
所以我一直跟人讲：仿真里的安全，至少有两层意思。第一层，你要仿真的这个5G网络，在设计上必须包含安全机制（认证、加密、完整性保护），这样实验结论才可信；第二层，承载仿真的这套软硬件平台，本身要有基本的防护（网络隔离、权限控制、数据保护），否则你的实验环境和实验数据都会成为靶子。这两层缺一不可，但绝大部分人只看到了第一层，甚至第一层都懒得做。
2. 一个5G仿真环境里，哪些环节最容易成为缺口
要谈安全性考虑，首先得知道威胁从哪里来。我把仿真环境拆开来看，大体上有三个攻击面容易出问题：空口接入侧、核心网侧，以及仿真平台自身。这三个面我一个个说透。
2.1 空口那一侧：伪基站与鉴权旁路
5G的空口是无线信道，天然就是开放的。哪怕是在实验室里用OAI跑纯软件仿真，只要gNB和UE之间的数据在物理网卡上以真实数据包形式传输（比如通过环回口或者虚拟网桥），攻击者就有机会插入到通信路径上。最典型的威胁就是伪基站。真实世界里，伪基站通过广播虚假的小区信息吸引手机接入，从而截获IMSI、下发恶意信令；在仿真环境里，你可以用一台额外的机器模拟一个恶意gNB，看看你的UE会不会因为小区选择策略不够严格而误入。
这个实验很多做无线安全研究的团队都做过。但这里有个容易被忽略的点：UE侧和网络侧的鉴权保护必须都在线，伪基站实验才有意义。如果仿真里直接把鉴权关了，或者把USIM参数设成默认统一值，那任何"恶意的gNB"都可以轻松接入UE，实验结果什么也证明不了。更麻烦的是，很多开源协议栈在早期版本里对NAS消息的保护是默认关闭的，需要手动开启。如果你不主动去检查UE是否验证网络签名，伪基站攻击在仿真里就是畅通无阻的。
还有人会做空口重放和篡改实验，就是在UE和gNB之间架一个代理，把抓到的信令原样重发一遍，或者把某个字段改掉再发出去。这时候你就能直观看到，5G的完整性保护机制（NAS层的NIA算法和AS层的完整性保护）是怎么在重放攻击面前立起屏障的。如果仿真环境把NIA0（空完整性算法）作为默认，那重放篡改信令基本可以说是"随便玩"，这个实验反馈给研究者的信息量就是零。
2.2 核心网那一侧：默认端口和弱管理
核心网这边的问题更隐蔽，但破坏力更大。OAI的5G核心网组件跑起来后，AMF会在SCTP 38412端口监听NGAP连接，UPF在UDP 2152端口处理GTP-U数据包。这些端口在实验机上往往是真实暴露在局域网里的。如果实验室小伙伴互相能ping通，那别人理论上也可以直接对着AMF端口发送SCTP报文，尝试建立NGAP连接或者发起恶意注册请求。
更常见的安全隐患是管理接口和数据面接口不分离。很多人在单台服务器上同时跑核心网多个网元，所有网元之间的数据监听在同一张网卡上，然后用一个统一的SSH账号管理整台机器。一旦这个账号密码被爆破或者泄露，攻击者就直接掌握了核心网的命门。再加上不少人为了方便调试，会关掉防火墙、用默认密码、把抓包端口开在0.0.0.0上——整套环境在办公网里基本等于裸奔。
我见过一个很典型的案例：某实训室把OAI核心网跑在一台Windows主机上，为了方便远程调试把相关端口映射到了公网，结果第二天凌晨日志里出现大量异常SCTP连接尝试。实际上攻击者并不关心你仿真的是什么，扫到端口就顺手摸一把，摸进去之后拿你的计算资源挖矿、挂代理。这对仿真本身而言不算"5G协议安全问题"，但它直接毁掉了你的实验环境。后面我会专门讲怎么通过基本加固来避免这类情况。
2.3 仿真平台本身：虚拟机、镜像和数据文件
第三个攻击面，是承载仿真的平台自身。OAI这种方案经常跑在虚拟机、容器或双系统环境里。有人图省事，在Windows上装VMware跑整套OAI，又因为性能问题在Windows里把虚拟化相关的安全特性关掉。先说结论：要不要关虚拟化安全特性，取决于你的虚拟机监控器配置，但一旦关掉Hypervisor层面的防护，虚拟机进程与宿主机内核之间的隔离就弱了一截。放在仿真场景里，如果你运行的环境本身又下载过来路不明的预编译镜像，风险就会明显放大。
镜像和快照往往是最大的"数据后门"。想象一下：你在仿真平台里存了一个快照，快照里带着USIM参数、核心网密钥配置、抓到的pcap信令文件。这个快照如果被拷走或者上传到不安全的存储，里面各种敏感实验参数就全泄露了。pcap信令文件尤其要重视，里面可能包含IMSI、IMEI、网络标识、密钥派生相关的信息。很多做仿真的同学习惯把pcap直接丢在共享目录里，供全实验室的人分析。平时看着没什么，可真出了泄露问题，这些数据会非常麻烦。
所以我的建议很明确：仿真平台要当成一个真实的、可受攻击的IT系统来对待。加密虚拟机镜像、限制SSH来源IP、抓包文件及时清理或加密存储，这些操作花费不了多少时间，但是能挡住绝大多数无差别攻击。
3. 仿真中值得落地的安全机制：从算法到切片隔离
光知道哪里危险还不够，设计仿真实验时还得把5G的安全机制真正落地。这一节我把几个关键机制逐一提出来，解释它们是什么、在仿真里怎么体现、以及哪些参数需要你亲手去调。
3.1 先把5G的安全架构捋一遍
5G的安全体系比4G复杂不少，但在仿真里你真正会碰到的核心概念就几个：根密钥K、双向鉴权、密钥派生链、以及加密和完整性保护算法。
先说双向鉴权。5G AKA流程大概是这样的：UE里存放着根密钥K和运营商根密钥OPc等参数，网络侧（通常是AUSF/UDM）也保存同一份参数。注册时，网络侧下发一个随机数和身份认证向量，UE用K和OPc算出一个响应值，网络侧比对；反过来，UE也要验证网络侧发来的服务端签名。这个过程成功后，双方再基于K派生出一系列会话密钥，包括KAMF、KgNB等等。仿真里最常见的失败点，就是UE侧的USIM参数和核心网侧的签约参数不一致，导致MAC比对失败，认证直接卡住。
密钥派生之后，就是信令保护。控制面信令分两个层面，NAS层信令（UE和AMF之间）使用NAS加密算法和完整性保护算法；AS层信令（UE和gNB之间）在RRC建立过程中激活。5G定义了多组算法：加密算法NEA0是空算法（不加密）、NEA1对应SNOW 3G、NEA2对应AES-128；完整性算法NIA0是空完整性、NIA1对应SNOW 3G、NIA2对应AES。还有ZUC系列算法，一般记为NEA3/NIA3，具体支持程度取决于协议栈实现。
在真实网络里，运营商会禁用NEA0和NIA0，强制走非空算法。但仿真里很多开源协议栈为了调试方便，默认就把这些算法允许列表全打开了，协商结果经常是落到NEA0/NIA0上。如果你不主动改配置，就可能在抓包里看到明文NAS信令——而且你自己还以为已经加密了。这个问题我后面会专门讲怎么排查。
3.2 加密和完整性算法在仿真里怎么选
这是我在实操中觉得最值得细说的地方。选算法要根据实验目标来，总体有几种情况。
如果是为了验证功能流程，比如UE注册、PDU会话建立、切换，你其实可以把安全算法全部打开，选NEA2+NIA2这种强加密组合。这样跑出来的注册流程与真实商用网络的流程更贴近，后续测试业务时延、吞吐量也有参考价值。缺点是对调试不太友好，因为抓包之后看不到明文NAS信令，定位流程问题全靠日志。刚开始跑仿真的人会觉得"为什么我抓包看不到注册请求内容"，其实这是加密生效了，不是bug。
如果是为了定位协议流程问题，很多时候还是要容忍NEA0/NIA0空算法。比如怀疑某个字段导致切换失败，需要抓包逐字段比对时，明文状态效率更高。这种情况下，建议在隔离的实验环境里临时关掉加密，但一定要明确记在实验记录里，别把最终结果建立在明文模式下。
如果是为了做安全方向的研究，比如验证伪基站检测、重放攻击防护、密钥协商异常，那就要精心构造算法组合。比如你要测试UE在空完整性算法下会不会被篡改消息骗过，就只在网络侧开NIA0，观察UE行为。而当你想测试UE对降级攻击（capability downgrade）的抵抗能力，就要看UE在安全能力协商阶段是否强制拒绝空算法。这类实验在OAI里完全可以做，需要对配置文件的算法优先级列表做精确控制。
注意一点：ZUC算法在一些开源实现里可能没有启用编译选项，或者只支持部分版本。如果你实验里必须用ZUC，要提前确认协议栈版本和编译配置，否则协商会自动落到其他算法上，实验结论可能和你的预期完全相反。
3.3 用切片隔离做横向防护
网络切片是5G的特色机制。从安全角度理解，切片可以看成是"给不同业务划隔离的赛道"。一个切片的异常流量、恶意信令，不应该影响到其他切片里的业务。在仿真里，这个概念特别适合用来做横向防护实验。
具体操作上，你可以在核心网里配置多个S-NSSAI，每个S-NSSAI对应不同的切片标识和不同的UPF实例。UE侧根据应用诉求选择携带不同的NSSAI发起注册和会话建立。仿真里验证切片隔离常见的方法是：先让两个UE分别接入两个切片，跑通业务；然后在网络侧单独对其中一个切片施加攻击（比如在UPF网关上伪造GTP-U封装包），观察另一个切片的业务是否受到影响。如果网络设计与真实5G一致，另一个切片应该基本不受影响。
但需要注意，切片隔离在仿真里的效果很大程度上取决于承载网络和UPF隔离的实现粒度。纯软件仿真的多个UPF进程如果都跑在同一台机器上，网络层流量还是会经过同一块网卡，那"隔离"更多是逻辑层面的。要测试到真正的隔离强度，需要配合虚拟机或容器做资源和网卡隔离。这个度要把握好，不然容易得出结论说"切片很安全"，其实只是你实验环境太简陋罢了。
4. 实操：用OAI搭一套带安全配置的5G仿真环境
理论讲多了，不如直接上一套可操作的流程。这一节我以OAI 5G SA仿真为例，从基线环境搭建开始，到配置认证参数、安全算法，再到验证加密是否生效，完整跑一遍。以下步骤基于常见的OAI版本，具体字段在不同版本可能有差异，建议对照你使用的分支查阅官方README。
4.1 准备一个干净的基线环境
OAI这套体系分两大块，一块是无线接入网（gNB和UE），一块是5G核心网（AMF、SMF、UPF、AUSF、UDM、NRF等）。做纯软件仿真时，gNB、UE和核心网可以都跑在同一台性能较好的服务器上，也可以拆成两台、三台机器。我的建议是至少准备一台8核以上、16GB内存、Ubuntu 20.04或22.04的服务器，磁盘空间留够100GB，因为编译过程比较吃资源。
第一步是先把OAI核心网和RAN跑起来，先不碰任何安全配置，跑通一个最简单的"UE注册并建立PDU会话"基线。这一步的意义是确认环境本身是健康的。如果基线都跑不通，后面调安全配置时你根本分不清是安全问题还是链路问题。记录下基线状态下AMF的IP和端口、gNB的NGAP配置、UE的IMSI和密钥参数，这些在后续安全实验里都要用到。
基线跑通后，我强烈建议立刻做一个网络快照或镜像备份。这一步很多人忽略，一旦后面改配置把环境改坏了，恢复起来特别费劲。
4.2 配置认证参数与安全算法
在OAI里，核心网侧的用户签约数据一般在UDM里配置，常用的是命令行工具或预设的JSON配置文件。你需要关注几个关键项：SUPI/IMSI、根密钥K、OPc以及网络侧PlmnId和TAC。我在实操中遇到的认证问题，百分之八十都是K或OPc在UE侧和核心网侧不一致。OAI默认的USIM参数在文档里都有，但如果改过UE侧，核心网侧的UDM签约数据一定要跟着改，两边完全对齐才能完成5G AKA认证。
安全算法的配置通常不在UDM，而在gNB和UE的运行时配置里。有些版本支持在网元启动时通过命令行参数指定加密和完整性算法的优先级列表，有些版本是在配置文件中定义。实际研究时，你只需要记住两件事：第一，算法优先级列表的顺序就是协商时的偏好顺序；第二，空算法（NEA0/NIA0）默认是否允许由配置开关控制。为了尽快看到效果，建议把算法列表配成NEA2和NIA2，并明确关闭对空算法的允许。
以gNB侧为例，起动命令和配置中会涉及安全模式相关的控制参数。不同OAI版本对这些参数的封装有差异，所以这里不贴死命令，而是给一个通用的核查思路：找到gNB启动配置或是启动命令的帮助输出，搜索含security、cipher、integrity、algo这类关键字的选项；再找到UE侧启动配置，同样搜索这些关键字。两侧能协商出的公共算法必须至少有一个非空算法，否则协商会失败，或者在极端情况下系统直接回退到空算法。
4.3 开启安全后如何验证生效
配置完别急着说"搞定"，一定要验证。我常用的方法是抓包加日志双重确认。
抓包层面，在核心网所在宿主机上抓取AMF与gNB之间的流量（NGAP走SCTP，端口通常是38412），以及gNB接口上的NAS流量。如果NAS加密生效，抓包里还能看到NAS消息的外层（比如NAS container的头部），但看不到内层明文内容。RRC建立之后的消息，在Wireshark里往往是无法直接解析出明文NAS IE的。对比之下，如果抓包里能看到完整的注册请求字段，比如plain的5GMM消息消息类型、身份标识，那说明协商落到了空加密算法上。
日志层面，看AMF日志里注册流程走到Security Mode Command时，到底选出了什么算法。通常日志会打印selected ciphering algorithm和selected integrity algorithm之类的信息。两侧一致，且不是空算法，基本就可以确认加密链路是通的。如果在Security Mode Complete之后流程继续正常走完，则说明UE侧验签通过，双向鉴权成功。
额外再强调一个细节：有些OAI版本在日志中把算法ID打印成数字，比如0代表NEA0，2代表NEA2，别认错了。我一开始就是把数字2当成ZUC，调了好半天才发现其实是AES。
4.4 三个值得做的安全对照实验
配置好了，顺手可以做三组对照实验，能让安全机制的效果立刻显现出来。
第一组是"明文与密文对比"。在开启NEA2/NIA2前后，分别在相同位置抓包，把两次抓包的NAS消息截图或导出字段放到一起对比。你会发现开启后，NAS信令内部字段内容变成不可读的密文；这个对比实验我在给实训室学生演示时效果特别好，直观且说服力强。
第二组是"密钥不一致"实验。故意把UE侧USIM里的根密钥K改掉一个字节，保持核心网侧不变，重新发起注册。你会看到UE或者核心网走到鉴权环节时返回鉴权失败，日志里出现MAC mismatch、Authentication Failure之类的信息。这组实验能演示5G AKA的防伪能力——没有正确密钥的设备，进不了网。
第三组是"伪基站诱导"实验。如果需要做安全方向研究，可以在仿真网络外启动一个模拟的恶意gNB，广播一个信号质量更好但参数错误的小区，观察UE在小区选择时是否误接入。配合NIA2开启的状态，再用伪造的重放信令尝试激活安全上下文，看能不能成功。这组实验比前两组复杂，但它是空口安全研究里最能出内容的方向之一。
5. 我在仿真安全上踩过的坑和排查清单
最后这部分，分享一些我在实际运维和教学过程中踩过、见过、也帮别人排查过的坑。整理成清单，方便你直接对照。
5.1 注册失败、鉴权失败的排查
问题现象通常是UE一直发注册请求，但到不了注册完成，核心网日志里报出认证失败或安全模式失败。最突出的几个原因，按出现频率排：
第一，USIM参数不一致。这个前面反复说了，K、OPc、IMSI任何一个对不上，AKA流程就过不去。排障时先确认UE侧和UDM侧配置是否完全一致，重点检查K和OPc的字节顺序有没有写反。第二，算法无交集。网络侧只配置了UE不支持的算法，或者UE侧强制禁用空算法而网络侧只允许空算法，都会导致安全模式协商失败。处理方式是先打开NEA0/NIA0把流程跑通，确认不是认证问题后，再逐步收敛到目标算法。第三，时钟和序列号问题。5G AKA里SQN同步也是鉴权成功的必要条件，如果仿真环境里重启了很多次，SQN状态乱了，也会导致同步失败。简单处理方式是重置核心网侧用户数据和UE侧的USIM状态，让SQN回到初值对齐。
5.2 加密没生效却以为生效
这一类排查中最误导人的是"抓包软件显示问题"。Wireshark对于NAS消息的解析逻辑很聪明，但有时候即使数据是加密的，它也会通过一些特征猜测出消息类型，比如显示成"NAS Key Set Identifier"或者"NAS Security Mode Command"。新手容易误以为看到这些NAS层字段就说明有加密，其实那些只是外层明文字段，内层内容照样密文。判断标准应该是能不能看到完整的明文消息内容字段，比如可以展开看到"Message type: Registration request"里后续每个IE的具体值。如果只看见外层结构，看不到内层明文内容，那就是加密生效了，别去瞎调。
还有一种情况是算法协商确实落到了NEA0，但两端日志里没有明显报错，流程照常走完。这往往是因为配置文件里允许了空算法，且空算法在优先级列表里排在最前面。解决办法我刚才说过，直接关闭对NEA0/NIA0的允许，把目标算法置顶。
5.3 实验环境被扫描和清理建议
这一节不是5G协议问题，但碰到的概率极高。仿真环境一旦跑在共享网络里，端口扫描几分钟内就能找上门。OAI核心网AMF的SCTP端口、Open5GS相关网元的SBI接口（通常HTTP的80/8080端口等）都很显眼。我建议实验网络单独弄个VLAN，或者直接用一台独立实验交换机，网元之间的流量只在实验网段内传递。宿主机防火墙只放行必要的SSH来源IP，其它入站全部拒绝。
实验数据管理也不能马虎。我见过有人把整套OAI实验结果直接打包放在共享网盘上，甚至把pcap也一并发上去。实际上一个几分钟的注册和业务抓包，就能存几百兆，里面还有IMSI、IMEI、密钥相关的信令内容。我的习惯是：pcap集中存放在加密目录，文件命名带实验日期和算法配置标签，实验结束后按项目周期定期清理。另外，虚拟机模板、容器镜像、系统快照都要定期检查，防止把旧版本里带着弱配置的镜像又拿出来复用。
说实话，安全在5G仿真里是个"平时不觉得，出问题就头疼"的领域。我自己也是踩过几次坑才养成上面这些习惯。尤其是加密算法协商这块，每次换一个OAI版本都要重新确认一遍默认配置，因为开源项目的默认策略变动频繁。如果你现在正打算搭一套带安全验证的5G仿真环境，不妨按这期文章里的实验清单逐步过一遍，先做明文与密文对比，再做密钥不一致和伪基站诱导实验。等这几个实验跑完，你对5G安全机制的印象会扎实得多。
