找出讓 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 交換機 服務器等都需要盡可能的嚴密策略。以后的博文我們可以再詳細談談。