DHCP饥饿，一个简单的解决scheme？

使用整个IP地址空间似乎有点过分。 假设你正在谈论一个包含的环境（比如在NAT之后），那么你可以使用10.0.0.0 \ 8而不会遇到任何路由相关的问题。 如果您的实际networking（即真实机器的数量）很小，那么拥有一个潜在巨大的广播域的一般问题就不是那么相关，如果您将租赁时间设置得相对较低（几分钟），您可以确保它对于单个攻击者实际上耗尽你的范围是不实际的。 然而，你仍然需要抵御数以百万计的虚假请求，可能会是一个相对较大的stream量，这将是广播stream量记住，所以你的networking上的所有真正的设备也会看到它 – 所以每个人的虚假噪声很多networking必须处理中断。 您的交换机现在也将开始跟踪所有这些[假的] MAC \ IP地址组合，这样您就可以让攻击者增加他们消耗的资源量，而且这些也是有限的。 对于严重的攻击，我认为DHCP耗尽攻击代码可能比许多DHCP服务器能够处理的请求更快，如果这个范围实际上是巨大的 – 物理资源（处理响应和跟踪活动租约表所需的CPU和RAM）如果攻击者能够足够快地产生请求，并且最终的结果可能会更糟，那么DHCP服务器可能最终会被简单地消耗掉 – 现在，您已经用新的连接交换了拒绝服务攻击，攻击可能会导致您的DHCP服务器和交换机（那些可能被利用）。

如果这是一个有效的担忧，而且您不能忍受针对客户端的DoS的可能性，则应该使用具有防止这种机制的交换机 – 有特定的DHCP饥饿缓解机制，如DHCP侦听，但只是启用控制来限制MAC地址欺骗通常会帮助这一点，并在CAM表泛滥。 最好的方法是启用端口validation，但是在任何大型受控环境中都难以实现，并且在非托pipe场景（如WiFi热点）中无法使用。 我不相信有一个明确的通用解决scheme，这是平衡各种可用选项的风险，并select一个在你的环境中最好的。

这种方法有很多问题。

首先，如果你做了你所expression的东西，你将会有效地将自己从互联网上切断，因为这个范围包括（几乎）所有可能的IPv4地址。

其次，通过这样做，你可以自己设定一个巨大的广播域名。 典型的networking最佳实践build议使用small-ish子网（比如那些具有/ 22或更长网掩码的子网）来限制广播域的大小。 如果子网的数量比这个大，那么你的路由和开关设备（取决于它们的强健程度）可能会因为处理那么多的广播stream量而淹没。

切换到IPv6！

特别是如果你只使用ICMP自动协商而不使用DHCP服务器。 🙂

为什么不缩短DHCP租赁时间，以便让攻击者失败的战斗:)

没有简单的解决scheme，因为这不是一个微不足道的问题。

它的核心是DoS攻击无线以太网安装，不pipe是像DHCP范围耗尽攻击那样的“智能”，还是像发射器充斥无线电使用的频谱那样的“无脑”的东西，都不能停止，因为无线电不能有select地忽略任何给定发射机的信号。 空气是共享的媒介，这只是物理。

在有线以太网中，您可以closures多余的DHCP请求（或其他types的DoS攻击）来源的端口。 在过多的DHCP请求来自禁用接入点的情况下（以及禁用与该AP关联的每个移动单元），没有什么“微不足道的”可以做的。

最好的方法是在交换机级别上进行检查 – 检查这个攻击和缓解的详细解释： dhcp-starvation-quick-and-dirty

如果你这样做，那么你会介绍需要build立大量的路由，第3层交换机，DHCP中继代理，访问控制列表，防火墙规则等。想象一下，我的服务器是在10.1.1.1，我的网关在10.1.1.2和我的DHCP客户端在167.10.1.250：现在我需要一种方法将stream量从我的客户端路由到我的服务器和网关，到另一个子网上获得IP地址的其他客户端等。这将使networking几乎不可用。 这样的networkingpipe理实际上是不可能的。