<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
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 ).<br>
<br>
Rune Kock wrote:
<blockquote
cite="mid:fa8654f10808211023g129becf3s632f922b797ef247@mail.gmail.com"
type="cite">
<pre wrap="">On Thu, Aug 21, 2008 at 18:28, Eric Thibodeau <a class="moz-txt-link-rfc2396E" href="mailto:kyron@neuralbs.com"><kyron@neuralbs.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Rune Kock wrote:
</pre>
<blockquote type="cite">
<pre wrap="">How would enterprise-grade equipment help?
</pre>
</blockquote>
<pre wrap="">I would suspect such equipment can tell you on which port XYZ MAC address is
connected, which makes identifying the culprit much MUCH easier.
</pre>
</blockquote>
<pre wrap=""><!---->
Yes, Paul mentioned a Dell switch with that functionality.
</pre>
<blockquote type="cite">
<pre wrap="">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).
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
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.<br>
<br>
See below for more details:<br>
<blockquote
cite="mid:fa8654f10808211023g129becf3s632f922b797ef247@mail.gmail.com"
type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">- drop DHCP, and configure all clients statically. Not fun.
</pre>
</blockquote>
<pre wrap="">At worst, long leases with static assignments in the dnsmasq
configuration...
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
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.<br>
<br>
<blockquote
cite="mid:fa8654f10808211023g129becf3s632f922b797ef247@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">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 )
</pre>
<blockquote type="cite">
<pre wrap="">- use some kind of software-firewall or access program (PPPoE?) on the
clients. Definitely not fun.
</pre>
</blockquote>
<pre wrap="">Nah. But I seem to remember seeing some sort of "secure" DHCP somewhere but
I wouldn't go there...
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">- split the lan into small segments. Doable, but will only confine
the problem to one segment, not remove it.
</pre>
</blockquote>
<pre wrap="">I don't really see how this would really help unless the segments are
physical (broadcast domain) segments.
</pre>
</blockquote>
<pre wrap=""><!---->
True, I was thinking about physical segments.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">In the end, perhaps the only way is to shout DON'T DO THAT to the
users, and hope they listen...
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
Yes, if a technical fix isn't possible, I'll have to make the users
aware of the situation.
Rune
</pre>
</blockquote>
<br>
Eric
</body>
</html>