How do I protect my host from rogue DHCP servers?

[Igor2022]

So I have FreeBSD 14.0 with several real network interfaces (em0, igb0, wlan0, wlan1) and several loopback interfaces for jails. This configuration isn't final yet as I'm still experimenting. One of the real interfaces is facing the ISP, obviously, and hence it's configured by dhclient. It could be em0 or wlan1, depending on location. Other interfaces are configured statically in /erc/rc.conf. All internal and jail loopback interfaces are assigned fixed ip4 addresses from the private address space 192.168.0.0/16. For example, let's assume lo1 for jails uses ip4 192.168.30.1.

What bothers me is that I have no control over the upstream DHCP server. I realize that I'm being a bit paranoid here, but what if upstream DHCP server assigned my public interface the same ip I use for my internal interfaces (in this example, 192.168.30.1)? I tried such evil configuration in my home testbed, and it succeeded! I ended up with ifconfig reporting the same ip4 address for both em0 and lo1, with lo1 completely thrown out of the routing table (no mention of lo1 in netstat -4rn ever) and inaccessibe. So I guess, such misconfiguration would ruin (well, 'interfere with' at the very least) the operation of jailed services. That basically constitutes a successful denial of service attack: som external action disrupts operation of my local services. Well, I don't think my ISP would ever pull such joke, but malicious DHCP servers are still possible in unsafe environments (say, visiting EvilHackers' cafe and using their free WiFi spot).

I've searched some boards/Q&A sites to see if it's possible to configure dhclient to never accept certain offers (the ones with certain iface addresses) but that seems not possible. It seems dhclient can ignore offers from certain servers, which isn't quite the same.

Am I overthinking the threat? What mitigation is possible? Should a dhclient feature request be filed (assuming it really has no way to decline malicious offers)?

 

[mer]

DHCP servers should only be handing out addresses in the range they have configured.
Is it possible that your ISP could be handing out in the same range you have statically configured? Sure. If internally you make to use the allowed private IP ranges chances become smaller, assuming the ISP hands out public IPs. If the ISP hands out in the private range, then they are doing NAT somewhere so you may need to change your internal config.

say, visiting EvilHackers' cafe and using their free WiFi spot

One could say "don't do that" or don't turn up your jails in that environment.

 

[gpw928]

Your ISP should not be allocating addresses from the private address spaces described in RFC-1918:

• Class-A Private Networks (10.0.0.0/8)
• Class-B Private Networks (172.16.0.0/12)
• Class-C Private Networks (192.168.0.0/16)

The above addresses can not be routed (i.e. visible) on the Internet.

However, in practical terms, ISPs tend to do as they please, and they often break the rules by connecting clients to an RFC-1918 private address space enclave, and routing out of that enclave onto the Internet, using NAT. This saves them from having to use a scarce IPV4 public address for each client. It also means that although your host will be able to open outbound connections to the Internet, it will not be visible to accept any incoming connections.

ISPs tend to be consistent, so look at the address range your ISP is allocating, and if it is in an address space reserved for private networks, don't use it internally. I have never seen an ISP allocate DHCP addresses from the 192.168.0.0/16 space -- that would be suicidal. Optus in Australia allocate from the 10.0.0.0/24 network for cellular mobile data services.