Skip to main content

11. 安全考虑 (Security Considerations)

本章讨论SCTP协议的安全问题、潜在威胁以及相应的防护机制。

11.1. 安全目标 (Security Objectives)​

SCTP的主要安全目标包括：

11.1.1. 完整性保护 (Integrity Protection)​

校验和机制：

- 使用CRC32c校验和保护整个SCTP数据包
- 检测传输错误和恶意篡改
- 比TCP的16位校验和更强

验证标签 (Verification Tag)：

- 每个SCTP数据包包含32位验证标签
- 防止数据包伪造和注入攻击
- 在关联建立期间交换

11.1.2. 可用性保护 (Availability Protection)​

Cookie机制：

- 防止SYN洪水攻击
- 服务器端无状态
- 延迟资源分配

多宿主支持：

- 提供路径冗余
- 增强抗拒绝服务能力
- 自动故障转移

11.1.3. 机密性 (Confidentiality)​

注意：SCTP本身不提供 (does NOT provide) 数据加密。

建议：

  • 使用TLS over SCTP (RFC 3436)
  • 使用DTLS over SCTP
  • 使用IPsec

11.2. SCTP对潜在威胁的响应 (SCTP Responses to Potential Threats)​

11.2.1. 伪造攻击 (Masquerade Attacks)​

威胁：攻击者假装成合法端点。

SCTP防护：

1. 验证标签验证
   - 每个数据包必须包含正确的验证标签
   - 标签在关联建立时交换
   - 错误标签的数据包被丢弃

2. 四次握手
   - INIT -> INIT ACK -> COOKIE ECHO -> COOKIE ACK
   - 验证对等方的地址
   - State Cookie包含加密信息

State Cookie内容：

- 对等方的验证标签
- 对等方的初始TSN
- 时间戳
- 生存时间
- HMAC签名

11.2.2. 重放攻击 (Replay Attacks)​

威胁：攻击者捕获并重放有效的SCTP数据包。

SCTP防护：

1. TSN（传输序列号）
   - 单调递增
   - 检测重复数据包
   - 窗口机制防止旧数据包

2. Cookie生存时间
   - State Cookie包含时间戳
   - 过期Cookie被拒绝
   - 防止INIT ACK重放

3. 验证标签
   - 每个关联唯一
   - 关联终止后失效
   - 防止跨关联重放

11.2.3. 拒绝服务攻击 (Denial of Service Attacks)​

11.2.3.1. SYN洪水类型攻击​

威胁：攻击者发送大量INIT块，耗尽服务器资源。

SCTP防护 - Cookie机制：

1. 收到INIT
   - 不分配TCB
   - 不分配资源
   - 生成State Cookie

2. State Cookie
   - 包含建立关联所需的所有信息
   - 使用HMAC保护
   - 发送INIT ACK（包含Cookie）

3. 收到COOKIE ECHO
   - 验证Cookie的HMAC
   - 检查Cookie生存时间
   - 此时才分配TCB

优势：
- 服务器端无状态
- 攻击者必须收到INIT ACK
- 难以进行源地址欺骗

推荐的Cookie生成算法：

Cookie = HMAC(Secret, Peer-Address | Peer-Port | My-Tag | 
               Peer-Tag | Timestamp | ...)

11.2.3.2. 数据包洪水攻击​

威胁：攻击者发送大量数据包，耗尽带宽或处理能力。

SCTP防护：

1. 验证标签过滤
   - 快速丢弃无效标签的数据包
   - 最小化处理开销

2. 校验和验证
   - 早期检测损坏或伪造的数据包
   - 避免后续处理

3. 拥塞控制
   - 限制发送速率
   - 防止网络拥塞

11.2.3.3. 多宿主利用攻击​

威胁：攻击者滥用多宿主功能进行攻击。

场景：攻击者在INIT中包含受害者的地址，使服务器向受害者发送流量。

SCTP防护 - 地址验证：

1. HEARTBEAT验证
   - 向新地址发送HEARTBEAT
   - 等待HEARTBEAT ACK
   - 仅在确认后使用新地址

2. 地址参数处理
   - 不信任INIT中的所有地址
   - 主要使用源地址
   - 其他地址需要验证

3. 实现建议
   - 限制可添加的地址数量
   - 对未验证地址应用速率限制
   - 记录可疑行为

11.2.4. 窃听 (Eavesdropping)​

威胁：攻击者监听SCTP通信，窃取敏感信息。

SCTP限制：

SCTP本身不提供加密
- 数据以明文传输
- 需要额外的安全层

推荐解决方案：

1. TLS over SCTP (RFC 3436)
   - 应用层加密
   - 适用于面向流的应用

2. DTLS over SCTP
   - 数据报加密
   - 适用于消息导向的应用

3. IPsec
   - 网络层加密
   - 透明保护所有SCTP流量
   - ESP模式提供机密性和完整性

11.2.5. 盲攻击 (Blind Attacks)​

威胁：攻击者在不监听流量的情况下发送伪造数据包。

困难因素：

1. 必须猜测
   - 正确的验证标签（32位）
   - 正确的源和目标端口
   - 正确的TSN范围

2. 成功概率
   - 验证标签：1/2^32
   - 加上TSN验证：更低

3. SCTP响应
   - 错误数据包被静默丢弃
   - 不提供反馈给攻击者
   - 难以进行暴力攻击

特殊保护 - ABORT和SHUTDOWN COMPLETE：

这些块可以设置T位：
- T=1：使用接收数据包中的验证标签
- 允许响应"Out of the Blue"数据包
- 但受到严格限制，防止滥用

11.3. SCTP与防火墙的交互 (SCTP Interactions with Firewalls)​

11.3.1. 防火墙挑战​

状态跟踪：

防火墙需要理解SCTP状态机：
- CLOSED
- COOKIE-WAIT
- COOKIE-ECHOED
- ESTABLISHED
- SHUTDOWN-PENDING
- SHUTDOWN-SENT
- SHUTDOWN-RECEIVED
- SHUTDOWN-ACK-SENT

多宿主处理：

挑战：
- 单个关联可能使用多个IP地址
- 流量可能来自不同的源地址
- 动态添加/删除地址

解决方案：
- 跟踪关联而非单个连接
- 识别验证标签对
- 允许关联内的地址变化

11.3.2. 防火墙建议​

基本过滤规则：

1. 验证SCTP校验和
   - 丢弃校验和错误的数据包
   - 减轻某些攻击

2. 状态跟踪
   - 仅允许有效状态转换
   - 拒绝无效的块组合

3. INIT处理
   - 可能需要速率限制
   - 防止INIT洪水

4. 多宿主支持
   - 允许ASCONF块（如果支持动态地址）
   - 验证HEARTBEAT交换

推荐配置：

允许的出站：
- INIT, COOKIE ECHO, DATA, SACK, HEARTBEAT, SHUTDOWN
- 其他控制块

允许的入站：
- INIT ACK, COOKIE ACK, DATA, SACK, HEARTBEAT ACK, SHUTDOWN ACK
- 响应已建立关联的块

阻止：
- 无效状态转换
- 未请求的INIT ACK
- 验证标签错误的数据包

11.3.3. NAT考虑​

NAT问题：

SCTP包含IP地址信息：
- INIT和INIT ACK中的地址参数
- ASCONF块中的地址
- NAT需要理解并重写这些

挑战：
- 需要应用层网关(ALG)
- 增加NAT复杂性
- 可能影响多宿主功能

建议：

1. 避免在INIT中包含私有地址
2. 使用公共地址或NAT遍历技术
3. 考虑使用SCTP-aware NAT/ALG

11.4. 保护不支持SCTP的主机 (Protection of Non-SCTP-Capable Hosts)​

11.4.1. 问题​

场景：攻击者使用SCTP INIT攻击不支持SCTP的主机。

影响：

- 目标主机可能不理解SCTP
- 可能发送ICMP错误响应
- 攻击者可能利用此进行放大攻击

11.4.2. SCTP行为​

收到ICMP错误：

SCTP端点应该：
1. 记录ICMP错误
2. 可能标记路径为不可达
3. 不应立即中止关联
4. 继续尝试其他路径（如果多宿主）

速率限制：

SCTP实现应该：
- 限制向单个目标的INIT发送速率
- 避免参与放大攻击
- 实现指数退避

11.4.3. 网络保护​

建议：

1. 入口过滤
   - 防止源地址欺骗
   - BCP 38 (RFC 2827)

2. 出口过滤
   - 限制到非SCTP端口的SCTP流量
   - 保护遗留系统

3. 主机防火墙
   - 丢弃不支持协议的数据包
   - 不发送ICMP响应（或速率限制）

总结​

SCTP的安全机制：

  1. 验证标签：防止伪造和盲攻击
  2. Cookie机制：防止SYN洪水类型攻击
  3. CRC32c校验和：检测篡改和错误
  4. 地址验证：防止多宿主滥用
  5. 四次握手：增强身份验证

安全限制：

  • 不提供加密（需要TLS/DTLS/IPsec）
  • 不提供源认证（需要上层机制）

最佳实践：

  • 使用加密层保护敏感数据
  • 实施速率限制和监控
  • 正确配置防火墙和NAT
  • 遵循安全编码实践
  • 及时应用安全更新
Last updated on