[Dnsmasq-discuss] Request for brain-storm: Rogue dhcp-servers on the lan

[Eric Thibodeau]

Any of the solutions mentioned below are "patches" except probably for 
the level 2 switch filtering/denying DHCP server-type replies from your 
customers other than from your own server (or is it level3 at this 
point...in between maybe ;P ).

Rune Kock wrote:
> On Thu, Aug 21, 2008 at 18:28, Eric Thibodeau <kyron at neuralbs.com> wrote:
>   
>> Rune Kock wrote:
>>     
>>> How would enterprise-grade equipment help?
>>>       
>> I would suspect such equipment can tell you on which port XYZ MAC address is
>> connected, which makes identifying the culprit much MUCH easier.
>>     
>
> Yes, Paul mentioned a Dell switch with that functionality.
>
>   
>> And, a
>> really cool thing with dnsmasq, you could even trigger an alarm when an
>> unknown MAC is added to the network or if a given MAC address matches
>> certain a criterion such as manufacturer (ie: your network only has 3COM
>> nics and a Cisco/Linksys MAC address suddenly appears, the script sounds a
>> BEEP on the server and sends an administrative alert).
>>     
>
> Well, that is great when you want tight control of your network.  My
> network is mostly used by people in their homes, and I would prefer
> not to get involved in whatever equipment they attach -- beyond what's
> necessary to keep the network running, that is.
>   
Well, it sounds like you're running some sort of ISPish service sort of 
like one you'd see as a community service with somewhat "loose" 
management...btw, I am not saying this as an insult I am attempting to 
picture your actual setup and constraints. If you have the luxury of a 
level2 switch and 1-client per port, you could probably deny DHCPOFFER 
from any ports other than your own DHCP (don't quote me on the actual 
DHCP message, just block serve responses is the idea). Even if you have 
more than 1 client/port you should enable such filtering to at least 
isolate the propagation of invalid addresses.

See below for more details:
>>> - drop DHCP, and configure all clients statically.  Not fun.
>>>       
>> At worst, long leases with static assignments in the dnsmasq
>> configuration...
>>     
>
> Yes, long leases would help a bit.  I don't think assigning the static
> IPs from dnsmasq would be any better than dynamic IPs -- in both
> cases, the clients are susceptible to a rogue DHCP-server.
>
> Maybe a mix is an idea: configuring the most important computers
> statically, and using DHCP for the rest.
>   
Yes, most definitely, configure your servers with a static IP (served by 
DHCP with rather long leases) and keep them on an isolated broadcast 
network (if possible) and try to use an improbable network address base 
like 10.103.42.x/24 for them so chances are they won't come in conflict 
with another router's accidental assignment.

>> Funny how I'm working on a script that can build the
>> initial configuration (an poking at Mr. Kelly for incremental IP assignments
>> but that's only a wish and I don't want him to break his code ;oP )
>>
>>     
>>> - use some kind of software-firewall or access program (PPPoE?) on the
>>> clients.  Definitely not fun.
>>>       
>> Nah. But I seem to remember seeing some sort of "secure" DHCP somewhere but
>> I wouldn't go there...
>>     
>
> Any solution would have to work on a wide range of different client
> machines.  So I agree that some non-standard secure DHCP is probably
> out of the question.
>
>   
>>> - split the lan into small segments.  Doable, but will only confine
>>> the problem to one segment, not remove it.
>>>       
>> I don't really see how this would really help unless the segments are
>> physical (broadcast domain) segments.
>>     
>
> True, I was thinking about physical segments.
>
>   
>>> In the end, perhaps the only way is to shout DON'T DO THAT to the
>>> users, and hope they listen...
>>>       
>> This is the right answer IMHO, a net admin sometimes has to be authoritative
>> and "put your foot down". As a consultant, I charge extra for "user did
>> stupid thing" problems and it's in the contract and _not_ in small print so
>> that the customer thinks more than twice before plugging anything into
>> network.
>>     
>
> Yes, if a technical fix isn't possible, I'll have to make the users
> aware of the situation.
>
>
> Rune
>   

Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20080821/f66153f0/attachment.htm