17. 安全考量
本节考察可能针对 TURN 部署发起的攻击, 并讨论如何通过协议中的机制或实现中的推荐实践来缓解这些攻击.
针对 TURN 的大多数攻击都可以通过服务器要求请求经过认证来缓解. 因此, 本规范强制使用认证. 必须实现的机制是 STUN 的长期凭据机制. 可以使用具有相同或更强安全属性的其他认证机制. 但是, 必须确保这些机制能够以可互操作的方式被调用.
17.1. 外部攻击
外部攻击是指攻击者在系统中没有凭据, 并试图破坏客户端或服务器所看到的服务.
17.1.1. 获取未授权的分配
攻击者可能出于多种恶意目的, 希望在 TURN 服务器上获取一个 allocation. TURN 服务器提供了一种发送和接收分组的机制, 同时隐藏客户端的实际 IP 地址. 这使得 TURN 服务器对希望用它掩盖真实身份的攻击者很有吸引力.
攻击者也可能只是希望免费使用 TURN 服务器的服务. 由于 TURN 服务会消耗提供者的资源, 其使用通常预期会伴随成本.
这些攻击通过使用长期凭据机制来防止. 该机制允许 TURN 服务器确定请求者的身份, 以及请求者是否被授权获取 allocation.
17.1.2. 离线字典攻击
TURN 使用的长期凭据机制容易受到离线字典攻击. 能够窃听客户端与服务器之间消息交换的攻击者, 可以尝试多个候选密码并检查其中是否有正确值, 从而确定密码. 当密码熵较低时 (例如来自字典的词), 这种攻击会奏效. 可以通过使用具有高熵的强密码来缓解这种攻击. 在需要更强缓解措施的情况下, 可以在客户端与服务器之间使用 TLS 传输.
17.1.3. 伪造的 Refresh 和 Permission
攻击者可能希望攻击一个活动 allocation, 方法是向它发送一个立即过期的 Refresh 请求, 以删除该 allocation 并中断客户端服务. 通过认证 refresh 可以防止这种攻击. 类似地, 想要发送 CreatePermission 请求来创建指向不希望目的地的 permission 的攻击者, 也会因认证而被阻止. 这类攻击的动机见第 17.2 节.
17.1.4. 伪造数据
攻击者可能希望向客户端或对等方发送数据, 使其看起来分别来自对等方或客户端. 为此, 攻击者可以向客户端发送伪造的 Data indication 或 ChannelData 消息, 或者向 TURN 服务器发送伪造的 Send indication 或 ChannelData 消息.
由于 indication 和 ChannelData 消息未经认证, TURN 无法防止这种攻击. 但是, 这种攻击通常存在于基于 IP 的通信中, TURN 并不会显著加剧它. 考虑主机 A 与主机 B 之间一个不使用 TURN 的普通 IP 会话. 攻击者可以使用伪造的 A 的 IP 地址发送分组, 从而向 B 发送一个看起来来自 A 的分组. 这种攻击要求攻击者知道 A 和 B 的 IP 地址. 使用 TURN 时, 希望通过 Data indication 向客户端发送分组的攻击者, 需要知道客户端的 IP 地址 (和端口), TURN 服务器的 IP 地址和端口, 以及对等方的 IP 地址和端口 (以便放入 XOR-PEER-ADDRESS 属性). 若要向客户端发送伪造的 ChannelData 消息, 攻击者需要知道客户端的 IP 地址和端口, TURN 服务器的 IP 地址和端口, 以及 channel number. 这一特定组合比非 TURN 情况稍微更容易猜测.
这些攻击更适合通过应用层认证技术来缓解. 对于实时流量, 使用 SRTP [RFC3711] 可以防止这些攻击.
在某些情况下, TURN 服务器可能位于网络中的某个位置, 使其能够向客户端自身无法直接到达的主机发送数据. 例如, 服务器位于防火墙后面, 该防火墙允许来自防火墙外部的分组到达服务器, 但不允许到达防火墙后的其他主机. 在这些情况下, 攻击者可能能够向服务器发送一个 Send indication, 其中的 XOR-PEER-ADDRESS 属性包含防火墙后某个其他主机的传输地址. 如果服务器允许将流量中继到任意对等方, 这就会为攻击者提供一种攻击防火墙后任意主机的方式.
为了缓解这种攻击, TURN 要求客户端在向某个主机发送数据之前先建立到该主机的 permission. 因此, 除非攻击者能够创建经过认证的请求, 否则攻击者只能攻击客户端已经与之通信过的主机. 此外, 服务器管理员可以配置服务器, 限制其会中继数据的 IP 地址和端口范围. 为提供更高安全性, 服务器管理员可以要求客户端对客户端与服务器之间的所有通信使用 TLS.
17.1.5. 冒充服务器
当客户端从 TURN 服务器获知 relayed address 后, 会在应用协议中使用该 relayed address 来接收流量. 因此, 希望拦截或重定向该流量的攻击者可能尝试冒充 TURN 服务器, 并向客户端提供伪造的 relayed address.
长期凭据机制可以防止这种攻击, 因为它为响应提供消息完整性, 并认证响应确实来自服务器. 此外, 攻击者无法重放旧的服务器响应, 因为 STUN 头部中的 transaction ID 会防止这一点. 频繁改变 nonce 值也会进一步抑制重放攻击.
17.1.6. 窃听流量
TURN 主要关注认证和消息完整性. 机密性只是次要考量, 因为 TURN 控制消息不包含特别敏感的信息. 消息中的主要协议内容是对等方的 IP 地址. 如果防止 TURN 连接上的窃听者获知这些信息很重要, 可以在 TLS 上运行 TURN.
由 TURN 中继的应用数据, 其机密性最好由应用协议本身提供, 因为在 TLS 上运行 TURN 不会保护服务器与对等方之间的应用数据. 如果应用数据的机密性很重要, 应用应加密或以其他方式保护其数据. 例如, 对于实时媒体, 可以通过使用 SRTP 来提供机密性.
17.1.7. TURN 环路攻击
攻击者可能试图使数据分组在两个 TURN 服务器之间无限循环. 攻击过程如下. 首先, 攻击者向服务器 A 发送一个 Allocate 请求, 其源地址为服务器 B. 服务器 A 将其响应发送给服务器 B, 并且为了使攻击成功, 攻击者必须能够看到或猜出该响应的内容, 以便获知分配得到的 relayed transport address. 然后, 攻击者向服务器 B 发送一个 Allocate 请求, 其源地址为服务器 A. 同样, 攻击者必须能够看到或猜出响应内容, 以获知分配得到的 relayed transport address. 使用同样的伪造源地址技术, 攻击者随后在服务器 A 上将一个 channel number 绑定到服务器 B 上的 relayed transport address, 并在服务器 B 上将同一个 channel number 绑定到服务器 A 上的 relayed transport address. 最后, 攻击者向服务器 A 发送一个 ChannelData 消息.
结果是, 一个数据分组从服务器 A 上的 relayed transport address 循环到服务器 B 上的 relayed transport address, 再从服务器 B 上的 transport address 到服务器 A 上的 transport address, 然后再次循环.
对此攻击的缓解方式如下. 通过要求请求经过认证, 和/或通过随机化为 relayed transport address 分配的端口号, 服务器迫使攻击者必须截获或看到发送给第三方 (在此例中为另一台服务器) 的响应, 才能认证请求并获知 relayed transport address. 如果没有这两项措施之一, 攻击者就能在不看到响应的情况下猜测其内容, 从而更容易实施攻击. 此外, 通过要求请求经过认证, 服务器迫使攻击者拥有服务器会接受的凭据, 这会使其成为内部攻击而非外部攻击, 并允许将攻击追溯到发起攻击的客户端.
进一步的缓解措施是, 对属于同一 username 的 allocation 所用于中继数据的带宽施加按 username 的限制, 以限制该攻击对其他 allocation 的影响. 还可以在中继数据分组时递减 TTL (如果底层操作系统允许).
17.2. 防火墙考量
TURN 的一个关键安全考量是, TURN 不应削弱部署在客户端与 TURN 服务器之间的防火墙所提供的保护. 预计 TURN 服务器通常会出现在公共 Internet 上, 而客户端则通常位于由企业防火墙服务的企业网络内. 如果 TURN 服务器为进入企业提供了 "后门", TURN 就会被这些防火墙阻断.
因此, TURN 服务器会模拟实现地址相关过滤 [RFC4787] 的 NAT 设备的行为, 这是许多防火墙中的常见属性. 当 NAT 或防火墙实现这种行为时, 只有内部 IP 地址和端口最近向某个外部 IP 地址发送过分组, 来自该外部 IP 地址的分组才被允许发送到该内部 IP 地址和端口. TURN 服务器引入 permission 概念, 在 TURN 服务器上提供完全相同的行为. 除非客户端先尝试联系攻击者, 否则攻击者不能向 TURN 服务器发送分组并期望它被中继给客户端.
需要注意的是, 某些防火墙的策略比地址相关过滤更严格. 防火墙也可以配置为地址和端口相关过滤, 或配置为禁止所有入站流量. 在这些情况下, 如果允许客户端连接 TURN 服务器, 与客户端通信所受限制将小于防火墙通常允许的限制.
17.2.1. 伪造的 Permission
在防火墙和 NAT 设备中, permission 是由从网络内部穿越到外部对等方的分组隐式授予的. 因此, 按定义, 防火墙或 NAT 外部的任何实体都不能创建 permission. 使用 TURN 时, 这一限制不再成立. 由于 TURN 服务器位于防火墙外部, 防火墙外部的攻击者现在可以向 TURN 服务器发送消息, 并尝试为自己创建 permission.
这种攻击会被阻止, 因为所有创建 permission 的消息 (即 ChannelBind 和 CreatePermission) 都经过认证.
17.2.2. 黑名单 IP 地址
许多防火墙可以配置黑名单, 以防止防火墙后的客户端向黑名单 IP 地址范围发送分组, 或从黑名单 IP 地址范围接收分组. 这是通过分别检查进入和离开防火墙的分组的源地址和目的地址来实现的.
TURN 中也存在这种能力, 因为允许 TURN 服务器任意限制其会向哪些对等方地址范围中继数据.
17.2.3. 在知名端口上运行服务器
防火墙后的恶意客户端可能尝试连接 TURN 服务器并获取一个 allocation, 然后用它运行服务器. 例如, 该客户端可能尝试运行 DNS 服务器或 FTP 服务器.
使用 TURN 时这不可行. TURN 服务器永远不会接受来自客户端尚未安装 permission 的对等方的流量. 因此, 对等方不能简单地连接到已分配端口来获得服务.
17.3. 内部攻击
在内部攻击中, 客户端拥有合法凭据, 但违反这些凭据所附带的信任关系. 这些攻击无法通过密码学手段防止, 但需要在协议设计中予以考虑.
17.3.1. 针对 TURN 服务器的 DoS
希望破坏其他客户端服务的客户端可能获取一个 allocation, 然后用流量洪泛它, 试图淹没服务器并阻止服务器服务其他合法客户端. 推荐服务器限制其会为给定 username 中继的带宽量, 可以缓解这种攻击. 这不会阻止客户端发送大量流量, 但允许服务器立即丢弃超额流量.
由于每个 allocation 都使用 TURN 服务器 IP 地址上的一个端口号, 服务器上的 allocation 数量是有限的. 攻击者可能尝试通过请求大量 allocation 来耗尽所有 allocation. 推荐服务器限制给定 username 同时处于活动状态的 allocation 数量, 可以防止这种攻击.
17.3.2. 匿名中继恶意流量
TURN 服务器提供一定程度的匿名化. 客户端可以向对等方发送数据而不暴露自己的 IP 地址. 因此, TURN 服务器可能成为攻击者发动针对目标的攻击且不怕被发现的有吸引力工具. 实际上, 客户端可以将多个 TURN 服务器串联起来, 使数据分组在到达目标之前经过任意数量的 relay.
关注此攻击的管理员可以维护日志, 捕获客户端的实际源 IP 和端口, 甚至可能记录该客户端安装的每个 permission. 如果发现某个攻击是通过 TURN 服务器中继的, 这些日志可用于取证追踪并确定原始来源.
17.3.3. 操纵其他 Allocation
攻击者可能试图通过发送 Refresh 请求或 CreatePermission 请求来破坏 TURN 服务器上其他用户的服务, 这些请求 (通过源地址欺骗) 看起来像是来自 TURN 服务器的另一个用户. TURN 通过要求 CreatePermission, Refresh 和 ChannelBind 消息中使用的凭据与创建初始 allocation 时使用的凭据匹配来防止这种情况. 因此, 攻击者伪造的请求会被拒绝.
17.4. 其他考量
通过 Allocate 请求获知的任何 relayed address, 都无法与传输模式或隧道模式下的 IPsec Authentication Header (AH) [RFC4302] 正常配合工作. 但是, 隧道模式的 IPsec Encapsulating Security Payload (ESP) [RFC4303] 应仍能工作.