DHCP 饥饿,一个简单的解决方案?

DHCP 饥饿,一个简单的解决方案?

我知道有很多解决方案可以缓解 DHCP 耗尽攻击。但一个真正简单的解决方案难道不是将 DHCP 地址池设置为 1.1.1.1 - 254.254.254.254(或其他某个非常大的地址池),这样恶意实体就无法在实际时间范围内耗尽整个地址池?为什么不这样做呢?

在无线网络环境中考虑这种情况,没有加密,也没有身份验证(免费公共无线热点的典型特征)。

答案1

使用整个 IP 地址空间似乎有点过分。假设您谈论的是封闭环境(例如,在 NAT 后面),那么您可以使用 10.0.0.0\8,而不会遇到任何与路由相关的问题。假设您的实际网络(即真实机器的数量)很小,那么拥有潜在的巨大广播域的一般问题实际上并不那么重要,如果您将租约时间设置得相对较短(几分钟),您可以确保单个攻击者实际上无法耗尽您的范围。但是,您仍然必须抵御可能相对大量的流量,其中包含数百万个虚假请求,并且它将是广播流量,请记住,因此您网络上的所有真实设备也都会看到它 - 因此网络上的每个人都必须处理来自中断的大量杂散噪音。您的交换机现在也将开始跟踪所有这些 [假] MAC\IP 地址组合,因此您允许攻击者增加他们消耗的资源量,而这些资源也是有限的。对于严重的攻击,我认为如果范围实际上很大,DHCP 耗尽攻击代码可能会以比许多 DHCP 服务器处理的速度更快的速度发出请求 - 如果攻击者可以足够快地生成请求,DHCP 服务器上的物理资源(处理响应和跟踪活动租约表所需的 CPU 和 RAM)最终可能会被消耗,最终结果可能对您更糟 - 您现在已经将针对新连接的拒绝服务攻击与可能导致 DHCP 服务器和交换机崩溃的攻击(这些可能是可利用的)进行了交换。

如果这是一个合理的担忧,并且您无法忍受客户端遭受 DoS 攻击的可能性,那么您应该使用具有防止这种情况发生的机制的交换机 - 有特定的 DHCP 饥饿缓解机制,如 DHCP 侦听,但仅启用控制来限制 MAC 地址欺骗通常会对此有所帮助,并且还可以防止 CAM 表泛洪。最好的方法是启用端口身份验证,但这在任何大型受控环境中都很难实现,并且在非托管场景(例如 WiFi 热点)中没有用处。我不认为存在一个明确的通用解决方案,这是一个平衡各种可用选项的风险并选择最适合您环境的选项的问题。

答案2

这种方法存在许多问题。

首先,如果您按照您所说的去做,那么您实际上就会切断自己与互联网的联系,因为该范围包括(几乎)所有可能的 IPv4 地址。

其次,通过这样做,你将不得不面对巨大的广播域。典型的网络最佳实践建议使用较小的子网(例如具有 /22 或更长网络掩码的子网)来限制广播域的大小。如果子网大于该值,则路由和交换机(取决于它们的可靠性)可能会因必须处理如此多的广播流量而变得不堪重负。

答案3

切换到 IPv6!

特别是如果您只使用 ICMP 自动协商而没有 DHCP 服务器。:)

答案4

为什么不将 DHCP 租约时间缩短到足以让攻击者陷入失败的境地呢?:)

相关内容