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