跳到主要内容

22. 安全考虑 (Security Considerations)

本节讨论与隐私无关的安全考虑. 关于隐私的专门讨论, 参见第 23 章.

对 DHCP 的威胁本质上是内部人员威胁 (假设网络配置正确, 并且企业边界网关阻止了 DHCP 端口). 但是, 无论网关如何配置, 内部人员和外部人员可能发起的攻击都是相同的.

DHCP 在客户端和服务器之间缺少端到端加密. 因此, 劫持, 篡改和窃听攻击都可能发生. 某些网络环境 (下文会讨论) 可以通过多种方式加固, 以尽量降低这些攻击的影响.

客户端和服务器共同面临的威胁是"资源耗尽 (resource-exhaustion)" DoS 攻击. 这类攻击通常会耗尽可用的已分配地址, 可委派前缀, CPU 或网络带宽; 只要存在共享资源, 就可能出现此类攻击. 部分耗尽型攻击可以通过适当的服务器策略加以缓解, 例如限制任一客户端可获得的最大租约数, 限制一个客户端可拒绝的租约数, 以及限制单个客户端在一段时间内可发送的消息数量.

22.1. 客户端安全考虑 (Client Security Considerations)​

一种针对 DHCP 客户端的攻击是建立恶意服务器, 目的是向客户端提供错误的配置信息. 这样做的动机可能是发起"中间人 (man-in-the-middle)"攻击, 使客户端在访问某项服务 (如 DNS 或 NTP) 时与恶意服务器通信, 而不是与有效服务器通信. 恶意服务器也可能通过错误配置客户端来发起 DoS 攻击; 这种攻击会导致客户端的所有网络通信失败.

恶意 DHCP 服务器可能通过 SOL_MAX_RT (见第 21.24 节) 和 INF_MAX_RT (见第 21.25 节) 选项, 使客户端将其 SOL_MAX_RT 和 INF_MAX_RT 参数设置为不合理的高值. 如果客户端没有收到其他有效响应, 这可能导致客户端完成其 DHCP 协议事务时出现不适当的延迟. 假设客户端也收到了来自有效 DHCP 服务器的响应, 较大的 SOL_MAX_RT 和 INF_MAX_RT 值将不会产生任何影响.

DHCP 客户端面临的另一类威胁来自配置错误或意外配置的 DHCP 服务器, 这些服务器会用非预期的错误配置参数来应答 DHCP 客户端请求.

如果客户端实现支持 reconfigure 机制, 参见第 22.3 节.

22.2. 服务器安全考虑 (Server Security Considerations)​

DHCP 服务器面临的特定威胁是无效客户端伪装成有效客户端. 其动机可能是窃取服务, 或出于各种恶意目的绕过审计.

中继代理与服务器之间交换的消息可能被用于发起中间人攻击或 DoS 攻击. 如 [RFC8213] 所述, 服务器与中继代理之间的通信, 以及中继代理之间的通信, 可以通过使用 IPsec 进行认证和加密.

但是, 在中继代理与服务器之间为 IPsec 使用手动配置的预共享密钥, 并不能防御重放的 DHCP 消息. 重放消息可能通过耗尽处理资源构成 DoS 攻击, 但不会通过错误配置或耗尽其他资源 (例如可分配地址和可委派前缀) 来构成 DoS 攻击.

如果服务器实现支持 reconfigure 机制, 参见第 22.3 节.

22.3. Reconfigure 安全考虑 (Reconfigure Security Considerations)​

第 20.4 节描述的 RKAP 可以防止恶意 DHCP 服务器利用 Reconfigure message 对客户端发起 DoS 或中间人攻击. 如果攻击者能够截获 DHCP 服务器以明文形式向客户端发送密钥的初始消息, 则该协议可能被攻破.

由于 Reconfigure message 提供了攻击机会, DHCP 客户端必须丢弃任何不包含认证信息的 Reconfigure message, 也必须丢弃任何未通过认证协议验证流程的 Reconfigure message.

DHCP 客户端还可能因为收到来自恶意服务器的 Reconfigure message 而遭受攻击, 该消息会使客户端从该服务器获取错误的配置信息. 注意, 虽然客户端通过中继代理发送其响应 (Renew, Rebind 或 Information-request message), 因而该响应只会被 DHCP 消息所中继到的服务器接收, 但恶意服务器可以先向客户端发送 Reconfigure message, 随后 (经过适当延迟后) 再发送会被客户端接受的 Reply message. 因此, 即使恶意服务器不在客户端与服务器之间的网络路径上, 它仍可能对客户端发起 Reconfigure 攻击. 使用密码学上可靠且不易被预测的 transaction IDs, 也会降低此类攻击成功的概率.

22.4. 缓解考虑 (Mitigation Considerations)​

如果按下文所述进行部署, 各类网络环境也能提供不同级别的安全性.

  • 在企业和工厂网络中, 按 [IEEE8802.1x] 使用认证可以防止未知或不受信任的客户端连接到网络. 但是, 这并不一定能保证已连接的客户端会成为良好的 DHCP 或网络参与者.

  • 对于客户端通常连接到交换机端口的有线网络, 窥探 DHCP multicast (或 unicast) 流量会变得困难, 因为交换机会限制传送到某个端口的流量. 客户端的 DHCP 消息 (multicast 到 All_DHCP_Relay_Agents_and_Servers) 只会转发到 DHCP 服务器 (或中继) 的交换机端口, 而不是所有端口. 同样, 服务器 (或中继) 的 unicast 回复也只会传送到目标客户端的端口, 而不是所有端口.

  • 在公共网络中 (如咖啡店或机场的 Wi-Fi 网络), 无线电覆盖范围内的其他人可能窥探 DHCP 和其他流量. 但是在这些环境中, 如果遵循第 23 章提供的隐私考虑, 从 DHCP 流量本身 (无论是客户端到服务器, 还是服务器到客户端) 几乎学不到什么信息. 即使设备没有遵循这些隐私考虑, 能从中学到的信息也很少, 且这些信息无论如何通常都会在后续通信中可见 (如设备的 Media Access Control (MAC) 地址). 此外, 由于所有客户端通常都会收到类似的配置细节, 主动发起 DHCP 请求的恶意行为者也能获知其中许多信息. 如上所述, 一项威胁是攻击者可能获知客户端的 RKAP 密钥 (如果初始 Solicit/Advertise/Request/Reply 交换受到监视), 并触发过早的重新配置; 但是, 在这些网络上禁止客户端之间的直接通信, 或使用 [RFC7610] 和 [RFC7513], 可以较容易地防止这种情况.

许多 rogue server 攻击可以通过使用 [RFC7610] 和 [RFC7513] 中描述的机制来缓解.

最后于 更新