许多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。
【编辑推荐】
