Can't block a DHCP server

Comodo Internet Security - CIS Firewall Help - CIS
#1

Hi, on the network of the office where i work there is a DHCP server, but in the last days i often receive a wrong address (192.168.40.128) from another unknown DHCP server (192.168.40.254).
I tried to prevent this from happen with Comodo Firewall, but it doesn’t seem to work.
I tried with different global rules, but no way.
Now i have these rules active as the first three:

Deny and Log
Protocol = UDP
Direction = In
Source Address = IPv4 Address [192.168.40.254]
Destination Address = Any
Source Port = A Port Range [67 - 68]
Destination Port = A Port Range [67 - 68]

Deny and Log
Protocol = TCP or UDP
Direction = In
Source Address = IPv4 Address range [192.168.40.0 192.168.40.255]
Destination Address = Any
Source Port = Any
Destination Port = Any

Deny and Log
Protocol = TCP or UDP
Direction = In/Out
Source Address = MAC Address [00-50-56-FF-C0-D4]
Destination Address = Any
Source Port = Any
Destination Port = Any

But if i release and renew, i receive again the same weird address… what can i do?

Thanks
Ciao
Andrea

#2

Looks like there is a rogue DHCP server active on your network, I would contact your network admin.

As in this case the rogue DHCP owner could set you up to route the traffic to the “default gateway” of his Man-In-The-Middle attack host…

#3

Ronny,
thanks for the answer.

Yes, sure that’s the first thing i did.
But as our network admin is quite slow to react, i wanted meanwhile to take advantage of the situation to learn better using the firewall and block the (supposed) rogue DHCP myself…

#4

That’s a tricky thing as the DHCP offer is part of the DHCP Request outgoing allowed by svchost.
At that point CIS decides to allow the traffic back in… I doubt this is possible in the current state CIS is allowing the “stateful traffic back in”.

I should have to fiddle around a bit with CIS and wireshark to see if this is even possible…

#5

There are two possibilities I can think of that might offer a temporary solution.

A. If you are certain the IP address of the 'rouge ’ DHCP server is 192.168.40.254, create a rule for svchost (in Application rules) that explicitly blocks UDP out to that address. Because of the nature of DHCP, which uses a limited broadcast to find DHCP servers, if communication fails to/from the first responder, it will give any other DHCP servers a chance to allocate.

B. If you know the IP address of the genuine DHCP server, create an explicit rule for svchost that uses UDP out to the DHCP servers address on port 67 and then block all other UDP communication for svchost on port 67.

This latter option has more potential pitfalls the former, again, because of the nature of the communication between DHCP client and DHCP server. It’s certainly worth a try, however.

#6

I tried every possible option IP, MAC, In, Out etc and even ARP poison the local host… Nothing blocked this…
I’m going to ask Dev’s if this is “by-design”…

#7

@Radaghast
Nothing to do.
I tried the “A” but it doesn’t work… and in wireshark i see the packets going forth and back without problems…
I tried the “B” but if i block the UDP on 67 outwards it doesn’t get an address at all because it blocks even the DHCP DISCOVER…

@Ronny
But is it possible that for the stateful nature of the firewall, the initial broadcast is considered a session initiation, even if it doesn’t contain the IP address of the destination?

Thanks to both of you for the support…
ciao
Andrea

#8

I was afraid option B might have problems. Unfortunately, Windows stores DHCP lease information in the registry at:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces{GUID}

In some cases the value stored in this key can prevent the proper functioning of the release/renew commands. There are ways around this, which if implemented, may allow for the blocking of the ‘rouge’ server as outlined above, but still allow a local broadcast on UDP 255.255.255.255:67 to find the ‘real’ DHCP server

Still, see what Ronny comes back with.

#9

The issue is under investigation.

#10

For what it’s worth, I was able to simulate this on my LAN. By blocking IP out to the rogue DHCP server, but allowing a local broadcast on 255.255.255.255:67, I was able to pick up an address from my chosen DHCP server.

#11

I think I tried that also, can you post the setup you used?

#12

I usually use the router for DHCP, but for this exercise I turned on the DHCP service on my Windows 2008 server box. This placed two DHCP servers on the LAN, both offering slightly different scopes. Without making any changes to the svchost rules, a release/renew always received an address from the router. This is due to the registry settings.

To prevent this behaviour, I blocked all out-going activity to the router but allowed a local broadcast on port 67. Using this method, the test PC was able to obtain address from the 2008 DHCP server. I was also able to reverse the situation by blocking the 2008 DHCP server and obtaining an address from the router.

#13

Can you also block both and not receive an IP at all?

This seems different from my findings… but I only tested with a DHCP relaying router.
Not with a directly connected DHCP server on the LAN.

#14

If I block all communication out on port 67, a release and renew will eventually produce an APIPA address, It does take while though…

#15

I didn’t use specific UDP port rules, only the more global IP one’s…
I’ll see if I can test tomorrow with specific UDP 67/68 rules.

#16

Thanks for the hint, in this days i’m out of office, but on monday i’m testing this for sure…

ciao
Andrea

#17

No way, it doesn’t work.

In fact i don’t understand how it could work, as it wasn’t so different from the previous attempts i made… if i analyze the traffic with wireshark i don’t see any packet going directly to the DHCP Server, both the DISCOVER and the REQUEST are broadcast, so they are allowed to pass…