DHCP資源耗盡案例及對策
許多VoIP電話默認配置為在每次啟動或者重啟時，動態向DHCP服務器申請IP地址。如果電話在啟動時DHCP不可用，或者DHCP服務器已經分配了最大額度的IP地址，于是電話就會變得不可用。一個耗盡DHCP地址的工具dhcpx是Phenoelit的最新版本的IPRAS（Internetwork Routing Protocol Attack Suite）的一部分，詳見http://www.phenoelit.de/irpas/ download.html。
DHCP是一個廣播協議，這意味著來自IP電話等DHCP客戶端的REQUEST消息可以被本網段中的所有設備看到，但是不會被轉發到其他子網。如果DHCP服務器部署在其他網絡，路由器上必須開啟DHCP轉發功能。DHCP轉發將廣播消息轉化為單播消息，并將消息轉發到配置的DHCP服務器。在大多數路由器和3層交換機上都支持DHCP轉發功能。
DHCP消息是bootp（bootstrap協議）消息。UDP端口67是bootstrap服務器端口，而端口68是bootstrap客戶端端口。bootp消息載荷可以承載在UDP和TCP上，然而，在我們的實驗中只看到交互的UDP/IP消息。
DHCP資源耗盡案例研究
我們配置了兩臺DHCP服務器，其中的一臺是PC機上運行的Linux Red Hat Fedora Core 4中自帶的DHCP服務器，此PC機直接連接到子網的交換機上。另一臺是Cisco2821路由器上自帶的DHCP服務。我們用Avaya Communication Manager IP電話來展示這類攻擊（也可以應用其他IP電話，因為這種攻擊并不是Avaya電話獨有的）。
我們對基于Linux的PC DHCP服務器上的dhcpd.conf文件進行配置，允許它最多分配兩個IP地址。這些地址恰巧是到目前為止已經靜態分配給Avaya H.323 IP電話的IP地址。我們也修改dhcpd.conf文件，使DHCP服務器將會以針對Avaya IP電話的選項176信息來響應DHCP DISCOVER廣播。DHCP選項176是一個私有的選項，換句話說，設備商可以提供只針對他們自有設備的信息。Avaya 4602 H.323 IP電話需要下列特有的選項176信息：
TFTP服務器的IP地址。
呼叫服務器的IP地址（Avaya Communication Manager）。
呼叫服務器的端口。
TFTP服務器和呼叫服務器相同，即10.1.14.100（在Avaya Communication Manager S8300）。
我們配置Cisco2821路由器的DHCP服務器分配最多10個連續的IP地址，并且這些IP地址和基于Linux的PC DHCP服務器分配的兩個地址不重疊。然而，我們沒有配置Cisco DHCP來提供選項176信息。
我們從http://www.phenoelit.de/irpas/download.html上下載IRPAS（Internetwork Routing Protocol Attack Suite）工具集，編譯工具集，應用dhcpx（Dynamic Host Confusion Program）工具來耗盡DHCP的IP地址。
驅使Avaya 4602 H.323 IP電話在啟動時發起DHCP請求操作的一個方法就是，清除靜態分配給它的IP地址。我們斷開每個電話的網線并重新插上網線，當電話啟動到一定過程時，會提示用戶（通過LCD）按"*"鍵來允許通過鍵盤輸入配置參數。我們按"*"鍵并清除LCD上顯示的所有參數，包括TFTP服務器IP地址、呼叫服務器（Communication Manager）IP地址和端口、子網掩碼、路由器網關IP地址、VLAN信息，等等。保存新的參數值后電話繼續啟動過程。
在啟動后，H.323 IP電話會在子網內廣播一個DHCP DISCOVER消息。兩個DHCP服務器都會用DHCP OFFER消息來響應。因為運行在Linux上的PC DHCP服務器提供了選項176信息，每個電話從運行在Linux上的PC DHCP服務器選擇各自的OFFER消息，而不是從Cisco DHCP服務選擇。每個電話完成各自的握手過程，并注冊到Avaya Communication Manager，這樣呼叫就可以在他們之間以正常的方式進行了。
我們拔掉IP電話，并讓它的IP地址過期。為了方便測試，我們配置IP地址的有效期為2分鐘。我們應用dhcpx進行了兩次試驗。每一次都達成了目標，換句話說，耗盡了所有OFFER消息中可用的IP地址，然而，每次試驗中的表現都不同。dhcpx的命令行方式信息如下：
- ./dhcpx
- ./dhcpx [-v[v[v]]] -i <interface> [-A]
- [-D <destination ip>]
- [-t <discovery time in secs>]
- [-u <ARP time in secs>]
我們應用的命令如下：
- ./dhcpx -vvv -i eth0 -D 10.1.14.110
第一次試驗中，dhcpx如命令行所指示那樣攻擊Linux的PC DHCP服務器，該服務器地址為10.1.14.110。dhcpx向DHCP服務器發送了大量DISCOVER消息來激活服務器的大量的OFFER消息。因為只有兩個可用地址，因此都很快被DHCP服務器進行了分配。DISCOVER消息是向DHCP服務器（10.1.14.110）進行單播的，也就是，目標MAC地址為目標DHCP服務器的MAC地址。然而，目標IP地址為子網的廣播地址255.255.255.255。這不會有影響，因為如果MAC地址不是子網廣播地址255.255.255.255.255.255時，IP地址是不相關的。dhcpx工具在每個DISCOVER消息中應用隨機的源MAC地址，DHCP服務器會對那些MAC地址做出響應。#p#
沒有料到的是，dhcpx工具開始時發送廣播DISCOVER消息，也就是MAC地址和IP地址都是子網廣播地址。Cisco路由器的DHCP服務器以OFFER消息來進行響應。dhcpx工具永遠不會完成DORA（Discover Offer Request Acknowledge）握手，而只是繼續廣播DISCOVER消息。因為服務器在一段時間內保留被分配的IP地址（如幾秒或幾分鐘），這和dhcpx工具繼續運行并接受OFFER消息在本質上有相同的影響。兩個DHCP服務器能夠分配的IP地址很快被耗盡了。我們停止運行dhcpx工具并讓兩個DHCP服務器上的OFFER消息過期，這樣它們將會有IP地址可以分配。整個過程中，H.323電話一直沒有接入到網絡中。
在第二次試驗中，dhcpx攻擊通過命令行中的-D選項將攻擊目標只限定為目標DHCP服務器，它同樣也能搞定每個分配的IP。瀏覽一下dhcpx的源碼，這種能力就是我們在第一次試驗中所要的。此時，我們將每個電話的混合的以太網/電源連接器插入到電話上，電話會啟動并廣播DISCOVER消息。Linux主機的DHCP服務器不會響應DISCOVER消息，因為它沒有IP地址可以分配。Cisco路由器上的DHCP服務器以OFFER消息進行響應。這些OFFER消息被電話接受，但是很快又被釋放。記住，Cisco DHCP服務器沒有配置為提供選項176包括Avaya特定信息的功能。這些電話最后進入了一個DISCOVER循環，每一個電話不停廣播DISCOVER消息，接受Cisco DHCP分配的IP地址并很快釋放這些地址。這些電話也會在LCD上滾動這些消息并告警L2Q（Layer 2 Quality）參數沖突和循環狀態。不管怎樣，電話服務實實在在地被拒絕了。
我們停止dhcpx工具的攻擊。因為我們配置基于Linux的PC DHCP服務器的IP地址每2分鐘過期一次，被dhcpx占用的兩個IP地址很快就可以被DHCP再分配，換句話說，DHCP服務器很快可以響應來自電話的DISCOVER消息。其中的一個Avaya電話（最新H.323模塊的那個-R2.3）很快從Linux DHCP服務器接收一個OFFER消息。它接受了此OFFER消息并在Avaya Communication Manager上進行注冊。裝有較老模塊（R.182）的H.323電話依然處于DISCOVER循環中，我們對此模塊所發生的事情并不知情。我們將此電話從網絡上拔下并又接入到網絡中。在啟動過程的第一個DISCOVER周期中，它接收到并接受了來自Linux DHCP服務器的OFFER消息，于是它注冊到Avaya Communication Manager上并能夠以正常模式進行呼叫。這些電話每隔70秒鐘會向Linux DHCP服務器重續他們的IP地址。
幾次之后，我們發現R1.82電話在LCD上顯示：
- Discover......
或許在此版本的電話上，DHCP功能實現存在漏洞。我們將此電話從網絡上拔下并又接入到網絡中。它啟動后，獲取IP地址并能在一段不確定的時間內正常運行。DHCP服務器通常配置為幾天過期。在R1.82 H.323模塊中的漏洞或許會在租約時間遠小于通常配置的時間時觸發。
DHCP耗盡對策
可以通過一些方法來減少DHCP耗盡攻擊，可以配置DHCP服務器不給未知的MAC地址和不信任的網絡分區分配IP地址。Cisco交換機的一個功能稱為DHCP探測，它能作為DHCP防火墻部署在可信的和不可信的網絡接口之間，詳見http://www.cisco.com/ univercd/cc/td/doc/product/lan/cat4000/12_1_13/config/dhcp.htm。
【編輯推薦】
