找出让 DHCP服务器瘫痪的凶手

前一段时间，总部的同事告诉我无线网不能用了，发现获取不到IP了，登录到DHCP服务器查看，发现DHCP服务器出故障了，具体的故障现象如下图，出现大量bad_adddress迅速占满DHCP的地址池。

然后他自己抓了一份数据包让我也帮忙分析一下。

我过滤了DHCP，重点观察了下它的DHCP包。发现出现大量的DHCP Decline数据包。

在这里可能有人很少听说DHCP Decline，简单来说这个包的意思就是如果CLIENT发现DHCP SERVER分配的IP地址已经被别人使用，则CLIENT会发出DHCP DECLINE报文通知DHCP SERVER禁用这个IP地址以免引起IP地址冲突，此时地址池就会显示bad_address。

看来引起DHCP服务器瘫痪的原因就是这大量的Decline数据包了，现在要找到原因为什么会出现这么多Decline。

在此我找到一个decline详细的分析了一下它前后的数据包，发现了下图的整个DHCP流程。

上图前4个包为标准的DHCP 4步。

数据包序列号917 963 964 997：显示clinet的mac为8b07（截图看不到）。8B07通过DHCP获取到了一个172.18.56.189的IP。

数据包1092为：8b07获取到189这个IP后执行了一次arp请求确认189没有人使用。

不过不巧的是数据包1173显示：MAC地址为A053的终端说“不好意思，189这个IP我已经用了”

此时数据包1178显示：8B07认为DHCP给我的这个IP172.16.56.189已经被别人用了,于是给服务器发送Decline。

继续分析下一个Decline原因，发现同样8B07又获取到了一个新IP 172.18.46.190。而同样A053的终端又说172.18.46.190我已经用了！！看来这个A053有大问题。于是重点过滤了A053出现了下图的情况

上图看来很明显了8B07不管获取到了哪个地址A053都会回复我在用了，导致8B07发送了大量Decline使DHCP服务器地址池很快耗尽瘫痪。

解决方法：果断登录AC控制器把A053这个MAC拉黑。所有问题一下子全部解决了。

后续：猜测A053这个主机是中了ARP中毒，小小的一个ARP病毒竟然有这么大的影响。安全这一步省了就可能出现×××烦，要想做到尽可能的安全AP AC 交换机 服务器等都需要尽可能的严密策略。以后的博文我们可以再详细谈谈。