使用Dhcpstarv解决DHCP服务器冲突问题

最新推荐文章于 2023-06-06 21:50:48 发布

weixin_30412013

最新推荐文章于 2023-06-06 21:50:48 发布

阅读量439

点赞数

文章标签：网络

原文链接：http://www.cnblogs.com/custa/p/3519940.html

版权

本文介绍了解决内网环境中多个DHCP服务器导致设备PXE安装混乱的问题。通过限制DHCP服务器仅对特定MAC地址分配IP，并使用Dhcpstarv工具消耗不期望的DHCP响应，确保设备能正确获取安装配置。

摘要由CSDN通过智能技术生成

场景：

内网环境需要开启多个DHCP服务器，分别给不同的设备进行PXE安装。

存在的问题：

多个DHCP的情况下，设备在启动时随机从一个DHCP服务器获取IP（哪个DHCP服务器先响应就从哪个获取）并从那个服务器读取配置进行引导安装。

如果提供IP的DHCP服务器不是期望的那个，就无法得到正确的配置文件，也就无法进行正常引导安装。

初步解决方法：

DHCP服务提供配置可以对响应进行限制，仅给某些设备（设备的MAC）分配IP，对其它设备的请求则不予响应。

/etc/dhcpd.conf配置大致如下：

subnet 128.128.0.0 netmask 255.255.0.0 {

......

filename "pxelinux.0";

}

deny unknown-clients;

host <hostname1> { hardware ethernet <XX:XX:XX:XX:XX:XX>;}

host <hostname2> { hardware ethernet <XX:XX:XX:XX:XX:YY>;}

这样配置以后，DHCP服务器仅会对<XX:XX:XX:XX:XX:XX> <XX:XX:XX:XX:XX:YY>这些MAC进行响应。

依然存在的问题：

如果每个DHCP服务器都做了限制，仅给指定MAC分配IP，并且没有两个DHCP服务器同时配置了同一MAC，那么每个MAC能够得到响应的DHCP服务器就是唯一确定的。

但不可避免，有些DHCP服务器并没有或者忘记设置，依然导致DHCP响应泛滥，设备还是可能从不期望的DHCP服务器获取响应。

进一步的解决方法：

要求每个使用的DHCP服务器在/etc/dhcpd.conf指定具体的MAC。对于那些泛滥响应的DHCP服务器，使用Dhcpstarv将其提供的IP（DHCP 响应）消耗掉。Dhcpstarv的执行方式就是不断伪造一些MAC地址进行DHCP请求，把DHCP服务器能够响应的IP地址都消耗掉。

具体操作：

当你想启动DHCP服务，给某台设备进行PXE安装，但是发现同一网络中还存在另一个DHCP服务器也在提供DHCP服务，那么就可以使用Dhcpstarv了。

命令使用（ethX就是连接到要消耗的网络的网卡，不要指定错了）：

# ./dhcpstarv -v -i ethX

类似下面的输出就说明dhcpstarv正在消耗DHCP响应

14:54:20 01/10/14: got address 128.128.18.199 for 00:16:36:4c:d7:48 from 128.128.18.5

14:54:20 01/10/14: got address 128.128.18.200 for 00:16:36:06:98:de from 128.128.18.5

等不再有类似的输出结果，说明DHCP的响应被消耗差不多了。让dhcpstarv程序继续运行，启动你自己的DHCP服务器。

恢复方法：

如果DHCP服务器未进行限制MAC配置，不幸被Dhcpstarv消耗完，可以通过以下方法恢复“被攻击”DHCP服务器：

1. 修改配置文件/etc/dhcpd.conf，增加限制MAC的配置：

deny unknown-clients;

host <hostname1> { hardware ethernet <XX:XX:XX:XX:XX:XX>;}

host <hostname2> { hardware ethernet <XX:XX:XX:XX:XX:YY>;}

2. 删除文件 /var/lib/dhcp/db/dhcpd.leases

3. 重启DHCP服务

如何定位攻击来源：

Dhcpstarv在发送的DHCP请求包中伪造随机的源MAC，其伪造方式是：固定前3个字节硬件设备“制造商”为“001636”，后3个字节随机生成。源代码位置：

dhcpstarv-0.2.1/src/main.c:130行

unsigned char vendor_mac_prefix[] = { 0x00, 0x16, 0x36 };

但是，以太网帧的源MAC还是发送数据帧的网卡的真实MAC，因此为了定位Dhcpstarv伪造的DHCP请求包的来源，可以通过抓包，根据以太网帧中的源MAC确定Dhcpstarv的位置。

DHCP请求包是封装在UDP数据报，UDP数据报偏移36字节的位置即是DHCP请求包的源MAC，过滤UDP数据报的前3个字节为“001636”，就可以得到Dhcpstarv伪造的DHCP请求包。命令如下：

# tcpdump -i bond0 -ne src port 68 and udp[36:2]=0x0016 and udp[38]=0x36

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on bond0, link-type EN10MB (Ethernet), capture size 96 bytes

13:51:31.254469 00:18:82:b0:7e:22 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 286: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:16:36:81:30:15, length 244

13:51:32.000714 00:18:82:b0:7e:22 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 304: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:16:36:81:30:15, length 262

转载于:https://www.cnblogs.com/custa/p/3519940.html