深度解析 3GPP TS 33.518：4.2.3 & 4.3 & 4.4 NRF的安全基石 - 从平台加固到健壮性模糊测试

本文技术原理深度参考了3GPP TS 33.518 V18.0.0 (2023-06) Release 18规范中，关于“4.2.3 Technical Baseline”、“4.3 NRF-specific adaptations of hardening requirements”以及“4.4 NRF-specific adaptations of basic vulnerability testing requirements”的核心章节。本文将重点解读这些看似简洁却内涵丰富的“引用型”条款，并深入剖析NRF必须面对的终极压力测试——健壮性与模糊测试。

引言：从“聪明”到“强壮”的转变

在华讯通信的5G核心网安全实验室里，李慧和她的团队刚刚成功完成了对NRF切片授权功能的测试。那一声清脆的“403 Forbidden”响应，证明了被测NRF具备了精准的协议层安全逻辑——它足够“聪明”，能够明辨是非。

在周五的周会上，李慧将测试计划翻到了新的一页。她对团队说：“各位，我们刚刚验证了NRF的大脑——它的协议安全逻辑。现在，我们要开始检验它的‘身体素质’。一个再聪明的将军，如果身子骨弱不禁风，也无法在残酷的战场上生存。从今天开始，我们的测试焦点将从‘协议’转向‘平台’，我们要回答一个核心问题：我们的NRF，足够‘强壮’吗？”

年轻工程师小王迅速翻阅规范的后续章节，发现从4.2.3到4.4.3，大量的章节内容都只有一句话：“There are no NRF-specific additions to clause X.X.X of TS 33.117”。他不禁疑惑道：“李姐，这些章节好像没什么内容，是不是意味着这部分工作很简单？”

李慧笑了，她身边一位头发微白、眼神锐利的老工程师——团队里的渗透测试专家“老陈”也笑了。李慧示意老陈来解答这个问题。

老陈清了清嗓子，沉声说道：“小王，你看到的这几句‘没有特定补充’，恰恰是这座冰山的水下部分。它不是‘没有要求’，而是告诉我们，NRF必须全盘接受3GPP为所有网元制定的、那部厚重的‘通用安全法典’——TS 33.117。这非但不简单，反而意味着我们的工作量巨大且繁杂。今天，我们就来一起掀开这块幕布，看看这‘看不见’的要求背后，究竟隐藏着怎样一个庞大的安全体系。”

---

1. 看不见的冰山：解读“通用技术基线” (Clause 4.2.3 Technical Baseline)

老陈走到白板前，写下了“4.2.3 Technical Baseline”。“我们先从‘技术基线’开始。基线，就是一个产品安全的‘最低纲领’，是它出厂时就必须具备的内功。”

他指出，虽然TS 33.518在4.2.3的各个子章节中都只引用了TS 33.117，但这实际上是向NRF产品提出了一个系统性的、全方位的安全要求。

1.1 数据与信息的全生命周期保护 (Clause 4.2.3.2)

原文引用 (例如 4.2.3.2.3 Protecting data and information in storage):

There are no NRF-specific additions to clause 4.2.3.2.3 of TS 33.117.

“看到这句话，我们的大脑就要自动翻译。”老陈说，“我们要立刻打开TS 33.117，去看4.2.3.2.3节到底写了什么。那里会明确要求：所有存储在非易失性介质（硬盘）上的敏感数据，例如NF的配置、凭证、以及包含身份标识的Profile信息，都必须使用强大的加密算法（如AES-256）进行加密。”

老陈将数据保护的要求扩展到整个生命周期：

• 防未授权查看 (Unauthorized viewing): 这意味着NRF必须有严格的访问控制机制。一个运维人员，如果没有对应的权限，他绝不能通过后台数据库或日志文件，直接查看到另一个NF的IP地址或服务密钥。

• 存储保护 (In storage): 这就是刚才说的静态加密。老陈强调，测试时不仅要确认“是否加密”，还要检查“如何加密”。密钥管理方案是否安全？密钥是否定期轮换？这些都是我们要拷问的。

• 传输保护 (In transfer): 这要求NRF与任何其他NF（通过Nnrf接口）以及与运维管理平台之间的所有通信，都必须强制使用TLS 1.2或更高版本进行加密。我们的测试中，必须用抓包工具（如Wireshark）去验证，是否存在任何明文传输的敏感信息，以及TLS的加密套件是否摒弃了所有已知的弱算法（如RC4, DES）。

• 个人数据访问日志 (Logging access to personal data): 虽然NRF主要处理NF数据，但一旦其存储的信息能关联到终端用户（例如通过SUPI/GPSI的查询），那么对这类数据的任何访问——无论是谁、在何时、做了什么——都必须被记录在案，形成不可篡改的审计日志。

1.2 可用性、完整性、认证与授权

老陈继续剖析技术基线的其他方面：

• 可用性与完整性 (Clause 4.2.3.3): “NRF是5G的信令十字路口，它一旦瘫痪，全网都会出问题。因此，它必须能抵抗DDoS攻击。我们的测试，就是要模拟流量洪水，看它是否会轻易地资源耗尽而崩溃。同时，它的内部数据和软件本身，必须有完整性校验机制（如签名、Hash），防止被恶意篡改。”

• 认证与授权 (Clause 4.2.3.4): “这里特指管理面的认证授权。所有试图通过SSH、HTTPS等方式登录NRF进行配置和维护的工程师，都必须经过强身份认证（比如使用RADIUS/TACACS+），并且严格遵循最小权限原则。一个初级运维人员，绝不能拥有修改核心路由策略的权限。”

• 会话保护 (Clause 4.2.3.5) 与 日志 (Clause 4.2.3.6): “所有管理会话必须有超时机制，防止终端被他人利用。同时，NRF必须产生详尽的日志，记录所有重要的安全事件、系统错误和管理操作，并将这些日志安全地发送到集中的SIEM平台进行分析。”

“大家看，”老陈总结道，“仅仅一个4.2.3章节，通过引用，就为我们展开了一幅覆盖数据、系统、管理等多个维度的立体防护网。我们的任务，就是把TS 33.117里的这些原则，变成一份详细的测试Checklist，逐项去验证。”

---

2. 加固堡垒：解读“强化要求” (Clause 4.3 Hardening Requirements)

李慧接过话头：“如果说‘技术基线’是NRF天生要具备的‘内功’，那么‘强化要求’就是后天修炼的‘金钟罩’。它关注的是NRF产品所依赖的底层基础设施，确保这些基础组件本身不会成为安全短板。”

同样，4.3章节也大量引用了TS 33.117。

原文引用 (例如 4.3.3 Operating systems):

There are no NRF-specific additions to clause 4.3.3 of TS 33.117.

“这里的潜台词是，”李慧解释道，“我们不关心你的NRF应用跑在哪个Linux发行版上，但无论是什么版本，它都必须经过严格的安全加固。”

她列出了几个核心的加固领域：

• 操作系统 (Operating systems):

  • 最小化安装： 交付的系统中，是否移除了所有与NRF运行无关的服务、端口和软件包？比如，一个NRF服务器上绝不应该还开着FTP或Telnet服务。

  • 访问控制： 是否实施了严格的文件权限管理？密码策略是否足够复杂？登录失败是否会触发账户锁定？

  • 安全配置： 内核参数是否经过优化以抵御常见的网络攻击（如SYN Flood）？是否开启了SELinux或AppArmor等强制访问控制模块？

• Web服务器 (Web servers):

  • 背景： NRF的服务化接口（Nnrf）是基于HTTP/2的，这意味着它依赖一个高性能的Web服务器（如Nginx, Apache等）或内置的HTTP服务栈。

  • 加固要求： 这个Web服务器的配置必须是安全的。例如，必须禁用不安全的HTTP方法（如TRACE），必须配置HSTS（HTTP Strict Transport Security）头部强制浏览器使用HTTPS，必须隐藏敏感的版本信息，防止攻击者进行指纹识别。

• 网络设备与其他NF (Network devices & Network functions):

  • “这部分要求NRF作为一个‘网络公民’，能够与其他设备安全地协同工作。它的网络配置必须是安全的，例如管理网和业务网必须严格隔离。同时，它与其他NF的交互，必须遵循SBA架构的安全规范。”

“所以，‘强化’这部分测试，要求我们的团队成员戴上‘系统管理员’和‘网络工程师’的帽子，深入到NRF的操作系统和网络配置层面，去排查每一个潜在的风险点。”李慧总结道。

---

3. 主动狩猎：基础脆弱性测试 (Clause 4.4 Vulnerability Testing)

“好了，通过‘基线’和‘强化’，我们已经把NRF的‘静态防御’做得差不多了。但真正的战场是动态的。”老陈再次走到台前，“现在，我们要从‘防守方’转变为‘攻击方’，主动去寻找NRF的弱点。这就是4.4章节——基础脆弱性测试的精髓。”

前面的4.4.2（端口扫描）和4.4.3（漏洞扫描）同样引用了TS 33.117。

• 端口扫描 (Port Scanning): “我们的任务，就是用Nmap这样的工具，对NRF的所有IP地址进行一次彻底的‘摸底’。扫描结果必须与厂商提供的‘官方端口开放清单’完全一致。任何一个清单之外的开放端口，都可能是一个后门，必须立刻质询。”

• 漏洞扫描 (Vulnerability Scanning): “我们会使用Nessus或OpenVAS等专业的漏洞扫描器，对NRF进行一次全方位的‘CT扫描’。扫描器会根据其庞大的漏洞库（CVEs），检查NRF的操作系统、Web服务器、各类软件包是否存在已知的安全漏洞。任何扫描出的中高危漏洞，都必须被修复，没有商量的余地。”

“但是，”老陈话锋一转，指向了规范的4.4.4节，“端口扫描和漏洞扫描，找的都是‘已知的未知’。真正考验一个产品健壮性的，是那些‘未知的未知’。这就引出了我们今天最重要的主题——模糊测试。”

---

4. 终极压力测试：健壮性与模糊测试 (Clause 4.4.4 Robustness and fuzz testing)

这是从4.2.3以来，第一个出现具体技术细节的章节。

The test cases under clause 4.4.4 of TS 33.117 are applicable to NRF.

The interface defined for the NRF are in 4.2.3 of TS 23.501.

… Following TCP/IP layer model and considering all the protocols over transport layer, for NRF, the following interface and protocols are in the scope of the testing:

• For Nnrf: the TCP, HTTP2 and JSON protocols.

老陈的眼中闪烁着兴奋的光芒。“这段话，是给我们这些‘破坏者’的行动指南。它明确了我们的主攻方向：Nnrf接口，以及构成这个接口的三层协议栈：TCP, HTTP/2, JSON。”

“什么是模糊测试（Fuzz Testing）？”小王问道。

“一个绝妙的比喻是：”老陈答道，“假设你是一个锁匠，想要测试一把锁的质量。常规测试是拿正常的钥匙去开。而模糊测试，是你造出一大堆奇形怪状、歪瓜裂枣的‘钥匙’，甚至是一些根本不像钥匙的金属片，然后疯狂地捅进锁芯，看这把锁会不会被你玩坏。我们的目标不是打开锁，而是把它搞崩溃。”

4.4.1 为什么要对NRF进行模糊测试？

“NRF的Nnrf接口，是它与外界沟通的嘴巴和耳朵。这个接口的实现如果不够健壮，就会‘病从口入’。”老陈解释了攻击的三个层次：

1. JSON层： NRF接收和发送的数据，都封装在JSON（JavaScript Object Notation）格式中。JSON解析器是软件中非常容易出问题的地方。如果攻击者发送一个精心构造的、畸形的JSON，比如括号不匹配、数据类型错误、超长字符串，一个脆弱的解析器可能会导致内存溢出、程序崩溃，甚至远程代码执行。

2. HTTP/2层： Nnrf接口跑在HTTP/2之上。相比HTTP/1.1，HTTP/2是一个更复杂的二进制协议，有帧、流、多路复用等概念。这意味着攻击面更广。攻击者可以发送不符合规范的HTTP/2帧，或者利用流量控制机制进行资源耗尽攻击。

3. TCP层： 这是最基础的传输层。经典的TCP/IP攻击，如SYN Flood、Land Attack等，同样可以用来测试NRF网络栈的健壮性。

4.4.2 模糊测试实战场景

老陈在白板上勾勒出了一个测试场景。

“假设我们要对NRF的NFDiscovery服务进行模糊测试。一个正常的请求可能是这样的：”

 
// POST /nnrf-nfm/v1/nf-instances
 
{
 
  "nfType": "SMF",
 
  "requester-snssai": { "sst": 1, "sd": "000001" }
 
}
 

“现在，我们的模糊测试工具会开始‘捣乱’，”老陈说着，写下了几种畸形的Payload：

• 类型篡改 (Type Tampering):

   
  {
   
    "nfType": 12345, // 把字符串变成数字
   
    "requester-snssai": "hello world" // 把对象变成字符串
   
  }
   

• 边界值/超大数据 (Boundary/Oversized Data):

   
  {
   
    "nfType": "SMF",
   
    "requester-snssai": { "sst": 1, "sd": "a....(此处省略1万个'a')...a" } // 极长的sd值
   
  }
   

• 格式破坏 (Format Corruption):

   
  {
   
    "nfType": "SMF" // 故意缺少右边的花括号
   

• 非预期参数注入 (Unexpected Parameter Injection):

   
  {
   
    "nfType": "SMF",
   
    "$where": "1 == 1", // 尝试注入类似SQL或NoSQL的查询指令
   
    "__proto__": {} // 尝试原型链污染
   
  }
   

“我们的测试平台会以每秒数千次的频率，自动生成并发送成千上万种这样的‘垃圾’请求。在整个过程中，我们会严密监控NRF的行为。”

4.4.3 期望的结果

“我们期望看到什么？”老陈自问自答，“我们不期望NRF能‘理解’这些垃圾。我们期望的是，面对这些狂轰滥炸，NRF能够表现出一个‘绅士’的姿态：

• 绝不崩溃： 它的进程必须保持稳定运行。

• 资源平稳： CPU、内存使用率不能出现异常飙升或泄漏。

• 优雅拒绝： 对于这些无效请求，它应该能快速识别并返回一个明确的错误码（如400 Bad Request），而不是超时或无响应。

• 日志清晰： 它应该记录下这些异常的请求，以便事后分析。”

“任何导致NRF服务中断、资源耗尽或异常退出的Fuzzing结果，都表明其健壮性存在严重缺陷，必须被评定为高危漏洞。”

---

5. 总结

会议结束时，小王对安全的理解已经上升到了一个全新的维度。他明白了，NRF的安全，远不止是遵循几条协议规则那么简单。

李慧做了最后的总结：“今天，我们一起探索了NRF安全体系的‘冰山之下’。我们明白了，一个安全的NRF产品，必须建立在一个坚实的地基之上。这个地基由三块巨石构成：

• 通用技术基线 (Technical Baseline): 确保了产品在数据、系统、管理等各方面的基础安全能力。

• 平台强化 (Hardening): 确保了产品所依赖的操作系统和底层服务被加固，消除了已知的薄弱环节。

• 主动脆弱性测试 (Vulnerability Testing): 通过模拟攻击，特别是模糊测试这种极限压力测试，确保产品在面对未知和恶意的输入时，依然能够保持健壮和稳定。”

“从协议逻辑的‘聪明’，到平台健壮性的‘强壮’，两者结合，才能铸就一个真正值得信赖的、能够承担5G核心网中枢重任的NRF。我们的测试工作，就是要确保它既有智慧，又有力量。”

---

FAQ

Q1：为什么3GPP选择在SCAS规范中大量引用TS 33.117，而不是直接把内容写进来？

A1：这是一种非常高效和一致的标准化策略。TS 33.117作为“通用安全保障要求目录”，是所有网络设备都需要遵守的“共同语言”。通过引用的方式，可以：1) 避免重复：无需在每个网元（NRF, AMF, SMF…）的SCAS中重复撰写相同的要求。2) 保证一致性：所有网元都参照同一个基线，确保了5G核心网整体的安全水平是均衡的。3) 便于维护：当某个通用安全要求需要更新时（例如，发现新的密码学漏洞），只需要更新TS 33.117一份文档，所有引用它的SCAS规范就能自动“受益”。

Q2：模糊测试（Fuzz Testing）和常规的功能测试、性能测试有什么区别？

A2：它们的目标和方法完全不同。功能测试验证的是软件在预期输入下能否产生预期的输出，关心的是“正确性”。性能测试验证的是软件在高负载（但合法）的输入下，其响应时间、吞吐量等指标能否达标，关心的是“效率”。而模糊测试，是向软件提供非预期的、畸形的、随机的输入，其目的不是看功能是否正确，而是看软件是否会崩溃或出现异常行为，关心的是“健壮性”和“安全性”。

Q3：执行模糊测试需要哪些专业的工具？

A3：模糊测试通常需要借助专业的工具来自动生成和发送大量的测试用例。市面上有许多成熟的开源和商业工具。例如，对于API和Web服务，可以使用像Burp Suite的Intruder、OWASP ZAP的主动扫描器、或者更专业的API Fuzzing工具如Sulley、Boofuzz、AFL++（配合相应的协议解析器）等。这些工具能够根据用户提供的模板或协议规范，自动生成成千上万种变异的测试数据。

Q4：“强化（Hardening）”和“打补丁（Patching）”是一回事吗？

A4：不是一回事，但它们都是保障平台安全的重要手段。“强化”是一个主动的、前置的安全配置过程，旨在通过最小化系统、关闭不必要的服务、采用安全的配置参数来减少系统的攻击面。它是在系统上线之初就应该完成的。而“打补丁”是一个被动的、持续的安全维护过程，旨在修复软件发布后新发现的漏洞。一个经过良好强化的系统，即使某个服务存在漏洞，也可能因为该服务已被禁用而免受攻击。一个持续打补丁的系统，则能不断消除新出现的威胁。两者相辅相成，缺一不可。

Q5：对于NRF的JSON和HTTP/2模糊测试，最可能发现哪一类安全漏洞？

A5：对于JSON解析器，最可能发现的是由解析逻辑缺陷导致的拒绝服务（DoS）漏洞。例如，一个精心构造的嵌套极深的JSON对象可能导致解析器递归栈溢出，使服务崩溃。在某些不安全的解析库中，甚至可能发现远程代码执行（RCE）漏洞。对于HTTP/2协议栈，模糊测试可能发现的漏洞包括：导致连接中断或服务器无响应的DoS漏洞（如SETTINGS帧或流量控制滥用），以及在协议实现复杂逻辑处的内存泄漏问题。这些漏洞都直接威胁到NRF的可用性和稳定性。