16. Security Considerations (安全考虑)
16.1. Attacks against the Protocol (针对协议的攻击)
16.1.1. Outside Attacks (外部攻击)
攻击者可以尝试修改传输中的 STUN 消息,以导致 STUN 操作失败。通过消息完整性机制,使用短期或长期凭证,可以检测到对请求和响应的这些攻击。当然,一旦检测到,被篡改的数据包将被丢弃,导致 STUN 事务实际失败。此攻击仅由路径上的攻击者可能发起。
可以观察但不能修改传输中的 STUN 消息的攻击者(例如,存在于共享访问介质(如 Wi-Fi)上的攻击者)可以看到 STUN 请求,然后立即发送 STUN 响应(通常是错误响应),以破坏 STUN 处理。对于使用 MESSAGE-INTEGRITY 的消息,也可以防止此攻击。但是,某些错误响应(特别是与认证相关的错误响应)无法受 MESSAGE-INTEGRITY 保护。当 STUN 本身通过安全传输协议(例如 TLS)运行时,这些攻击将被完全缓解。
根据 STUN 用法,这些攻击可能影响很小,因此不需要消息完整性来缓解。例如,当 STUN 用于基本 STUN 服务器以发现用于 ICE 的服务器反射候选地址时,不需要认证和消息完整性,因为在连接性检查阶段会检测到这些攻击。但是,连接性检查本身需要保护才能使 ICE 整体正常运行。如第14节所述,STUN 用法描述何时需要认证和消息完整性。
由于 STUN 使用共享密钥的 HMAC 进行认证和完整性保护,它容易受到离线字典攻击。使用认证时,应该 (SHOULD) 使用不易受离线字典攻击影响的强密码。使用 TLS 保护通道本身可以缓解这些攻击。但是,STUN 最常通过 UDP 运行,在这些情况下,强密码是防止这些攻击的唯一方法。
16.1.2. Inside Attacks (内部攻击)
恶意客户端可能试图通过向服务器发送大量 STUN 请求来对服务器发起 DoS 攻击。幸运的是,服务器可以无状态地处理 STUN 请求,这使得此类攻击难以发起。
恶意客户端可能使用 STUN 服务器作为反射器,向其发送具有伪造源 IP 地址和端口的请求。在这种情况下,响应将传递到该源 IP 和端口。这种攻击没有数据包数量的放大(STUN 服务器为客户端发送的每个数据包发送一个数据包),尽管数据量略有增加,因为 STUN 响应通常大于请求。入口源地址过滤可以缓解此攻击。
通过 SOFTWARE 属性透露代理的特定软件版本可能使其更容易受到针对已知包含安全漏洞的软件的攻击。实现者应该 (SHOULD) 使 SOFTWARE 属性的使用成为可配置选项。
16.2. Attacks Affecting the Usage (影响用法的攻击)
本节列出了可能针对 STUN 用法发起的攻击。每个 STUN 用法必须 (must) 考虑这些攻击是否适用于它,如果适用,讨论对策。
本节中的大多数攻击围绕攻击者通过绑定请求/响应事务修改 STUN 客户端学习到的反射地址。由于反射地址的使用是用法的功能,这些攻击的适用性和补救措施是特定于用法的。在常见情况下,路径上的攻击者很容易修改反射地址。例如,考虑 STUN 直接通过 UDP 运行的常见情况。在这种情况下,路径上的攻击者可以在绑定请求到达 STUN 服务器之前修改其源 IP 地址。然后,STUN 服务器将在 XOR-MAPPED-ADDRESS 属性中向客户端返回此 IP 地址,并将响应发送回该(伪造的)IP 地址和端口。如果攻击者还可以拦截此响应,它可以将其重定向回客户端。使用消息完整性检查保护此攻击是不可能的,因为消息完整性值无法覆盖源 IP 地址,因为介入的 NAT 必须能够修改此值。相反,防止以下列出的攻击的一种解决方案是客户端验证学习到的反射地址,就像在 ICE [MMUSIC-ICE] 中所做的那样。其他用法可能使用其他方法来防止这些攻击。
16.2.1. Attack I: Distributed DoS (DDoS) against a Target (针对目标的分布式DoS攻击)
在此攻击中,攻击者向一个或多个客户端提供指向预期目标的相同伪造反射地址。这将欺骗 STUN 客户端认为它们的反射地址等于目标的地址。如果客户端分发该反射地址以在其上接收流量(例如,在 SIP 消息中),流量将被发送到目标。此攻击可以提供实质性的放大,特别是与使用 STUN 启用多媒体应用程序的客户端一起使用时。但是,它只能针对从 STUN 服务器到目标的数据包通过攻击者的目标发起,限制了它可能的情况。
16.2.2. Attack II: Silencing a Client (使客户端静默)
在此攻击中,攻击者向 STUN 客户端提供伪造的反射地址。它提供的反射地址是路由到无处的传输地址。结果,客户端在分发反射地址时不会收到任何预期接收的数据包。这种利用对攻击者来说不是很有趣。它影响单个客户端,这通常不是所需的目标。此外,任何可以发起攻击的攻击者也可以通过其他方式拒绝对客户端的服务,例如阻止客户端从 STUN 服务器甚至 DHCP 服务器接收任何响应。与第 16.2.1 节中的攻击一样,仅当攻击者位于从 STUN 服务器到此未使用的 IP 地址发送的数据包的路径上时,此攻击才可能。
16.2.3. Attack III: Assuming the Identity of a Client (假设客户端的身份)
此攻击类似于攻击 II。但是,伪造的反射地址指向攻击者本身。这允许攻击者接收原本发往客户端的流量。
16.2.4. Attack IV: Eavesdropping (窃听)
在此攻击中,攻击者强制客户端使用路由到其自身的反射地址。然后,它将收到的任何数据包转发给客户端。此攻击将允许攻击者观察发送到客户端的所有数据包。但是,为了发起攻击,攻击者必须已经能够观察从客户端到 STUN 服务器的数据包。在大多数情况下(例如从接入网络发起攻击时),这意味着攻击者已经可以观察发送到客户端的数据包。因此,此攻击仅对从客户端到 STUN 服务器路径上但通常不在路由到客户端的数据包路径上的攻击者观察流量有用。
16.3. Hash Agility Plan (哈希敏捷性计划)
本规范使用 HMAC-SHA-1 来计算消息完整性。如果在以后的时间发现 HMAC-SHA-1 被破坏,将应用以下补救措施。
我们将定义一个 STUN 扩展,引入使用新哈希计算的新消息完整性属性。客户端将需要在其请求或指示中包含新旧消息完整性属性。新服务器将使用新的消息完整性属性,旧服务器将使用旧的。在部署混合实现的过渡期之后,旧的消息完整性属性将被另一个规范弃用,客户端将停止在请求中包含它。
还需要注意的是,HMAC 使用的密钥本身是使用用户密码的 MD5 计算的。选择 MD5 哈希是因为存储密码以该形式的遗留数据库。如果将来的工作发现 MD5 输入的 HMAC 不安全,并且需要不同的哈希,也可以使用此计划进行更改。但是,这将要求管理员重新填充其数据库。