3、RTP/RTCP协议攻击：RTP时间戳篡改、SSRC冲突攻击、RTCP反馈抑制、序列号乱序注入
各位好，我们接着往下聊。上一节我们把VoLTE的信令面攻击捋了一遍，这一节该轮到媒体面了。说白了，就是RTP和RTCP这两个协议。
RTP负责传语音数据，RTCP负责传控制信息。攻击者盯上它们，目的很单纯——让你的语音质量崩掉。我这些年做VoLTE安全测试，碰到最多的攻击手法，基本都集中在这四个点上：时间戳篡改、SSRC冲突、RTCP反馈抑制、序列号乱序注入。
咱们一个一个拆开讲。
3.1 RTP时间戳篡改
先问个问题：RTP时间戳是干嘛用的？
简单说，它告诉接收端“这个语音包应该在什么时间被播放”。VoLTE用的是固定采样率，比如AMR-NB是8kHz，AMR-WB是16kHz。每个语音帧对应一个时间戳增量。正常情况下，接收端根据时间戳来安排播放顺序和抖动缓冲。
攻击者如果篡改了这个时间戳，会发生什么？
我举个例子。假设攻击者把时间戳改得比实际大很多，接收端一看，“哟，这个包还早着呢”，于是把它扔到抖动缓冲深处。结果呢？这个包迟迟不被播放，等到真正该播的时候，它已经过期了。语音就出现了断续、卡顿。
反过来，如果把时间戳改小，接收端会认为这个包“迟到了”，直接丢弃。嗯，这就是典型的丢包攻击。
攻击效果：
- 时间戳增大 → 播放延迟、语音不同步
- 时间戳减小 → 包被丢弃、语音断续
- 时间戳随机变化 → 抖动缓冲紊乱、语音质量急剧下降
我在项目中遇到过一种情况：攻击者不是简单改一个包的时间戳，而是每隔几个包就微调一次。这种“温水煮青蛙”式的攻击，终端很难察觉，但用户听感上就是“声音忽快忽慢”。
避坑指南：
我曾经在测试中发现，有些终端对时间戳的校验非常宽松。只要时间戳在某个范围内，它就照单全收。建议在终端侧增加时间戳连续性检测，如果相邻包的时间戳差值超过正常范围（比如AMR-NB的增量应该是160），直接丢弃或标记异常。
3.2 SSRC冲突攻击
SSRC是什么？同步信源标识符。每个RTP流都有一个唯一的SSRC，接收端靠它来区分不同的流。
攻击者如果伪造一个和合法流相同的SSRC，会发生什么？
接收端会懵掉。它收到两个相同SSRC的包，不知道哪个是真的。更糟糕的是，很多终端的RTP接收逻辑是：如果收到相同SSRC的包，就认为是同一个流，然后根据序列号和时间戳来排序。结果就是两个流的数据混在一起，语音完全乱掉。
我见过一个真实的案例。某运营商的VoLTE网络里，攻击者注入了一个伪造的RTP流，SSRC和合法用户一模一样。合法用户的语音被“覆盖”了，接收端播放的全是攻击者的声音。这已经不是降级了，这是劫持。
注意：
SSRC冲突攻击的隐蔽性很高。因为RTP协议本身没有强制要求校验SSRC的唯一性。很多终端收到相同SSRC的包，只会简单覆盖或合并。攻击者甚至可以利用这个特性，实现“语音替换”攻击。
怎么防御？我个人习惯在网侧增加SSRC冲突检测。如果同一个会话中出现了两个相同SSRC的流，立即告警并阻断其中一个。终端侧也可以做，但效果不如网侧好。
3.3 RTCP反馈抑制
RTCP是RTP的控制协议。它主要干三件事：
- 发送接收报告（RR/SR）
- 提供服务质量统计
- 支持反馈机制（比如AVPF）
攻击者如果抑制了RTCP反馈，会怎样？
发送端收不到接收报告，就不知道网络状况怎么样。它可能继续以高码率发送，而实际上接收端已经丢包严重了。或者，它可能误以为网络很好，不做任何调整。
我记得有一次测试，我们模拟了RTCP反馈抑制攻击。发送端完全不知道接收端的情况，一直以AMR-WB 23.85kbps的码率发。实际上接收端的丢包率已经超过30%了。语音质量？惨不忍睹。
攻击手法：
- 丢弃RTCP RR包 → 发送端无法获取接收统计
- 延迟RTCP反馈 → 发送端反应滞后
- 伪造RTCP反馈 → 发送端被误导
还有一种更狠的：攻击者伪造RTCP反馈，告诉发送端“网络状况非常好，继续加大码率”。发送端信以为真，结果导致网络拥塞，语音质量反而更差。
避坑指南：
我曾经建议团队在发送端实现RTCP超时检测。如果连续几个周期收不到RTCP反馈，就主动降低码率或切换到更鲁棒的编码模式。别傻等，等来的可能是灾难。
3.4 序列号乱序注入
序列号是RTP包的唯一序号。接收端靠它来排序、检测丢包、检测乱序。
攻击者如果注入乱序的序列号，会怎样？
接收端的抖动缓冲会乱掉。它可能认为某个包丢了，然后请求重传。但实际上包没丢，只是序列号被改了。结果就是不必要的重传请求，浪费带宽，增加延迟。
更严重的是，如果攻击者注入一个序列号非常大的包，接收端会认为之前的所有包都丢了，然后清空抖动缓冲，重新开始。这会导致语音中断。
我见过一种攻击：攻击者每隔一段时间注入一个序列号异常的包，导致接收端反复重置抖动缓冲。用户听到的就是“断断续续”的语音，而且每次中断后恢复，都会有一段静音期。
注意：
序列号乱序注入攻击对抖动缓冲的冲击很大。尤其是那些实现比较简单的终端，对序列号异常的处理很粗暴——直接清空缓冲。这种攻击几乎无法通过编码优化来防御，必须在接收端做序列号合法性校验。
怎么防？我建议在接收端维护一个序列号窗口。只有落在窗口内的包才被接受，窗口之外的直接丢弃。窗口大小可以根据网络状况动态调整，但不要太大，否则攻击者容易钻空子。
3.5 知识体系总览
说了这么多，咱们用一张图来总结一下这四种攻击的核心逻辑。
这张图把四种攻击的核心逻辑和防御措施都串起来了。你想想看，攻击者其实就是在利用协议设计上的“信任”——RTP和RTCP默认所有包都是合法的。但现实是，攻击者可以随意伪造、篡改、注入。
好了，这一节的内容就到这儿。四种攻击手法，每一种都有它的特点。时间戳篡改破坏时序，SSRC冲突混淆身份，RTCP反馈抑制蒙蔽发送端，序列号乱序冲击接收缓冲。防御的思路也很清晰：校验、检测、超时、过滤。
下一节我们会聊更深入的内容，到时候见。
公众号:蓝海资料掘金营，微信deep3321