Use Dhcpstarv to solve DHCP server conflicts

 

Scenario:

In the Intranet environment, you must enable Multiple DHCP servers to install PXE on different devices.

 

 

Problems:

When Multiple DHCP servers are enabled, the device randomly obtains the IP address from a DHCP server (the DHCP server obtains the IP address from which the DHCP server responds first) and reads the configuration from that server for Pilot installation.

If the DHCP server that provides IP addresses is not the Expected One, the correct configuration file cannot be obtained, and the normal boot and installation cannot be performed.

 

 

Preliminary solution:

The DHCP Service provides configuration to restrict responses. Only IP addresses are allocated to certain devices (MAC devices) and requests from other devices are not responded.

The configuration of/etc/dhcpd. conf is roughly as follows:

Subnet 128.128.0.0 netmask 255.255.255.0.0 {

......

Filename "pxelinux.0 ";

 

}

Deny unknown-clients;

Host

Host

After this configuration, the DHCP server only responds to the MAC addresses <XX: XX> <XX: YY>.

 

 

 

Existing problems:

If each DHCP server has limits, only the IP address is assigned to the specified MAC, and no two DHCP servers have configured the same MAC at the same time, the DHCP server that each MAC can receive a response is uniquely identified.

But inevitably, some DHCP servers do not have or forget to set up, which still leads to a flood of DHCP responses. The device may still never expect the DHCP server to get a response.

 

 

 

Further solution:

Each DHCP server must specify a specific MAC address in/etc/dhcpd. conf. For DHCP servers with flood responses, use Dhcpstarv to consume the IP addresses (DHCP responses) it provides. Dhcpstarv is executed by repeatedly forging some MAC addresses for DHCP requests, consuming all IP addresses that the DHCP server can respond.

 

Specific operations:

When you want to start the DHCP service and install PXE for a device, but find that another DHCP server in the same network is also providing the DHCP service, you can use Dhcpstarv.

Command ):

 

#./Dhcpstarv-v-I ethX

 

Similar to the following output, dhcpstarv is consuming DHCP responses.

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

 

There are no other similar output results, indicating that DHCP responses are almost consumed. Let the dhcpstarv program continue to run and start your own DHCP server.

 

 

Recovery Method:

If the DHCP server does not restrict MAC configuration and is unfortunately exhausted by Dhcpstarv, you can recover the "attacked" DHCP server by using the following methods:

1. modify the configuration file/etc/dhcpd. conf and add the configuration to restrict MAC:

 

Deny unknown-clients;

Host

Host

 

2. delete the file/var/lib/dhcp/db/dhcpd. leases

3. Restart the DHCP service.

 

 

How to locate the attack source:

Dhcpstarv spoofs random source MAC in the DHCP request packet sent. The spoofing mode is fixed to "001636" for the hardware device of the first three bytes ", the last three bytes are randomly generated. Source code location:

Dhcpstarv-0.2.1/src/main. c: 130 rows

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

 

However, the source MAC of the Ethernet frame is the real MAC of the NIC that sends the data frame. Therefore, to locate the source of the DHCP Request Packet forged by Dhcpstarv, you can capture packets, determine the location of Dhcpstarv based on the source MAC in the Ethernet frame.

The DHCP request packet is encapsulated in the UDP datagram. The 36-byte location of the UDP datagram is the source MAC of the DHCP request packet. The first three bytes of the UDP datagram are filtered as "001636 ", then we can obtain the DHCP Request Packet forged by Dhcpstarv. The command is as follows:

# 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, ethertype IPv4 (0x0800), length 286: 0.0.0.68> 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, ethertype IPv4 (0x0800), length 304: 0.0.0.68> 255.255.255.67: BOOTP/DHCP, Request from 00: 16: 36: 81: 30: 15, length 262