第一章：核心网协议基础
各位同学好，我是老周。在电信核心网安全这个行当摸爬滚打了十几年，今天咱们来聊聊5G核心网的那些协议。说实话，刚接触5G的时候，我也被这一堆缩写搞得头晕——SBI、PFCP、GTPv2、Diameter……但后来我发现，搞懂这些协议，其实就是搞懂核心网怎么“说话”的。
1.1 5G核心网架构概述
5G核心网，说白了就是一张大网的大脑。它负责管理用户、处理会话、控制策略。跟4G相比，5G核心网最大的变化是什么？我个人的理解是——它从“专有硬件”走向了“云原生”。
5G核心网采用了服务化架构（SBA）。什么意思呢？就是把原来那些网元功能拆成一个个独立的“服务”。比如AMF管接入，SMF管会话，UPF管数据转发。这些服务之间通过统一的接口通信，也就是我们后面要重点讲的SBI接口。
核心网关键网元速览：
- AMF：接入和移动性管理，管用户能不能进来、走到哪了
- SMF：会话管理，管用户的数据通道怎么建、怎么拆
- UPF：用户面功能，管数据包怎么转发、怎么计费
- PCF：策略控制，管用户能用多少带宽、有什么权限
- UDM：统一数据管理，存用户签约信息
我刚开始做5G核心网测试时，最头疼的就是这些网元之间的交互逻辑。你想想看，一个用户发起呼叫，背后要经过AMF、SMF、PCF、UDM一圈下来，任何一个环节出问题，呼叫就失败了。嗯，这里要注意——协议模糊测试的价值就在于此：我们专门往这些接口上扔“坏数据”，看系统会不会崩溃。
1.2 SBI接口与HTTP/2协议
SBI（Service Based Interface）是5G核心网的一大亮点。它让网元之间不再用传统的点对点协议，而是统一走HTTP/2。为什么选HTTP/2？我个人的看法是——它支持多路复用、头部压缩、服务器推送，性能比HTTP/1.1好太多了。
但问题也来了。HTTP/2本身是给Web用的，现在搬到电信核心网里，安全风险就暴露出来了。我在做协议模糊测试时，经常往SBI接口里塞一些畸形的HTTP/2帧——比如乱改流ID、伪造HEADERS帧、塞超大的DATA帧。你猜怎么着？有些实现直接就崩了。
小技巧：测试SBI接口时，重点关注这几个点：
- HTTP/2的流状态机——乱序帧会不会导致状态混乱？
- 头部压缩表——HPACK解压时会不会内存溢出？
- GOAWAY帧——优雅关闭流程是否健壮？
举个例子，我曾经在某个厂商的AMF设备上，发了一个PRIORITY帧，把流优先级设成负数。结果那台AMF直接CPU飙升到100%，整个基站下的用户都掉线了。嗯，这就是典型的协议实现缺陷。
1.3 PFCP协议基础
PFCP（Packet Forwarding Control Protocol）是控制面和用户面之间的桥梁。SMF通过PFCP告诉UPF：这个用户的数据包该怎么转发、要不要计费、要不要做QoS。
PFCP的报文结构其实不复杂。它由头部和IE（信息元素）组成。头部里有消息类型、序列号、SEID（会话端点标识）等关键字段。IE则是各种参数，比如FAR（转发动作规则）、URR（用量报告规则）。
| 字段 | 长度 | 说明 |
|---|---|---|
| 版本 | 3 bit | 当前为1 |
| 消息类型 | 8 bit | 如Session Establishment Request (1) |
| SEID | 64 bit | 会话端点标识，用于关联控制面和用户面 |
| 序列号 | 32 bit | 用于请求-响应匹配 |
做PFCP模糊测试时，我习惯从SEID下手。为什么？因为SEID是会话的核心标识。如果你把SEID改成0xFFFFFFFF，或者改成随机值，UPF会怎么处理？有些实现会直接丢弃，但有些会尝试查找会话——如果查找逻辑没写好，就可能出现空指针解引用。
注意：PFCP的IE长度字段很容易被利用。我曾经见过一个案例，攻击者把IE长度改成65535，结果UPF在解析时申请了超大内存，直接OOM了。所以测试时一定要覆盖这种边界情况。
1.4 GTPv2协议基础
GTPv2（GPRS Tunneling Protocol v2）是4G/5G核心网中控制面信令的“老将”。它主要用于MME和SGW之间、SGW和PGW之间的信令交互。虽然5G核心网主推SBI，但GTPv2在现网中依然大量存在——尤其是和4G互操作的场景。
GTPv2的报文结构包括：GTP头部 + 信令消息。头部里有TEID（隧道端点标识）、消息类型、序列号等。TEID的作用和PFCP的SEID类似，都是用来标识一条隧道。
我记得有一次做互操作测试，发现GTPv2的Create Session Request消息里，如果携带了重复的Bearer Context IE，某些MME会直接崩溃。这就是典型的协议解析器没有做好去重校验。
GTPv2常见消息类型：
- Create Session Request/Response（创建会话）
- Modify Bearer Request/Response（修改承载）
- Delete Session Request/Response（删除会话）
- Echo Request/Response（心跳检测）
做GTPv2模糊测试时，我建议重点关注TEID的合法性校验。有些实现只检查TEID是否为0，但没检查是否属于当前会话。你发一个随机TEID的Delete Session Request，它可能就把别人的会话给删了——这在实际网络中可是大事故。
1.5 Diameter协议基础
Diameter协议是AAA（认证、授权、计费）领域的“老前辈”。在4G核心网中，它用于HSS和MME之间的信令交互。到了5G，虽然SBI逐渐取代了Diameter，但很多现网中Diameter依然在跑——尤其是和传统网络对接的场景。
Diameter的报文结构：头部（版本、长度、标志位、命令码、应用ID等）+ AVP（属性值对）。AVP是Diameter的核心，每个AVP都有类型、长度、值三个字段。
我个人觉得，Diameter最容易被攻击的地方是AVP的嵌套解析。比如Grouped AVP里面可以嵌套其他AVP，如果嵌套层数太深，或者循环引用，解析器就可能栈溢出。我曾经在测试中构造了一个100层嵌套的AVP，结果某个厂商的Diameter实现直接段错误了。
避坑指南：测试Diameter时，这几个AVP一定要重点测：
- Session-Id（会话标识）——长度超长或包含特殊字符
- Auth-Session-State（认证状态）——非法枚举值
- Result-Code（结果码）——未定义的值
- Vendor-Specific-Application-Id（厂商应用ID）——伪造厂商ID
嗯，说到这里，我想强调一点：协议模糊测试不是乱扔数据。你得理解协议的逻辑，知道哪些字段是关键路径，哪些字段是边界条件。否则你测出来的只是表面问题，真正的深水区根本碰不到。
好了，第一章的内容就到这里。这些协议基础是后续章节的基石，建议大家动手抓包看看实际报文长什么样。下一章我们会深入SBI接口的HTTP/2模糊测试实战，到时候我会带大家写一个简单的模糊测试工具。