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


    场景:

    内网环境需要开启多个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

     

  • 相关阅读:
    Space Ant(极角排序)
    Marriage Match II(二分+并查集+最大流,好题)
    Leapin' Lizards(经典建图,最大流)
    Food(最大流)
    99. Recover Binary Search Tree
    97. Interleaving String
    100. Same Tree
    98. Validate Binary Search Tree
    95. Unique Binary Search Trees II
    96. Unique Binary Search Trees
  • 原文地址:https://www.cnblogs.com/custa/p/3519940.html
Copyright © 2020-2023  润新知