IP address conflicts

Ted Mittelstaedt tedm at toybox.placo.com
Mon Sep 27 21:03:01 PDT 2004

> -----Original Message-----
> From: owner-freebsd-questions at freebsd.org
> [mailto:owner-freebsd-questions at freebsd.org]On Behalf Of Tim Aslat
> Sent: Sunday, September 26, 2004 9:50 PM

> I agree, and this is what we are trying to do.  However a school with
> 20+ buildings, and 1000+ network points and a considerable number of
> switches makes it a little more difficult.

And, let me guess, most switches purchased at different times, different
different number of ports, etc.

And all of them on a single network, not broken up into small subnets - that
is the first mistake.

Probably many of the predicessors didn't understand you can use cheap
as routers.

What a nightmare.

> I actually think it's more than 1 culprit, and I couldn't be 100%
> certain whether they are using their own notebooks or school machines
> until I catch them in the act.

Well, as these things go when you do finally catch one it's going to be
the slowest and stupidest one of the lot.  When he gets expelled the rest of
them are going to call an all-out war and get a lot more sophisticated a
lot faster.

> Please bear in mind that I have over 50 switches kicking around in
> various parts of the school, and only 4 of them are managed.  This could
> be a very expensive exercise.

It's not the number of switches that matter it's the number of active
ports.  50 what, 8 port switches?  or 24 port switches?

Of course, there are some other ways of handling this too.  "Oppps, looks
like another switch died, we are just having a rash of these failures
Must be bad power.  And amazing - it's the switch that the head of the
Engineering department and his staff are using!  Guess they will just have
to go without since we don't have the money for new switches"  It's amazing
how money will appear out of thin air if certain oxen get gored.

> > Also, if you are a bona-fied school, contact some of the switch
> > vendors, they
> > may make a deal with you under the table.
> This isn't a bad idea.  Might be well worth looking into, especially
> with the number we are going to need.

If you do go this route then screw the desktop switches, get yourself some
decent slotted hubs.  You want a much higher port density than the crummy
24 in a typical rack mounted switch.  Besides that, the switch vendor is
gonna want to use your school as an example of how to do things right.
if your going to go begging then you need to beg for the best stuff they

> I appreciate the sentiment :)  however if a quick hack can cover my butt
> until I get budget clearance to get real switches in place, then I'm all
> for it.  Like you, I don't like quick hacks, but it they do the job
> until I can put something better in place, it's better than nothing.
> One question though.  Would it be enough to get some half decent
> switches just on the servers, or would I need to replace every single
> switch in the network?

You need to replace every single switch.  When one of these bozos assumes
a server IP number, he's going to most likely use a different MAC address.
You need to be able to query the mac table in the switch to see what port
that address is coming in from.

Later on, when you have expelled a few of them, they are going to cop wise
and start using the SAME mac address of your server, either with the same
IP number or a different IP number.  At that point, your going to need to
use the filters provided in good switches so that the switches will only
allow the MAC addresses of your servers to come in to the physical port
that is plugged into those servers.  (or the physical port that is plugged
into the uplink port)

> > What you merely do is go around to ALL of the machines on the network
> > that need
> > to get to the proxy/web/mailservers and put in static ARP entries for
> > the MAC
> > addresses of the legitimate servers.  Then when your little friends
> > try their
> > trick, nobody is going to notice it, except of course for the machine
> > that they make their modification to.
> This sounds like more trouble than it's worth, but maybe there's a way I
> can distribute the settings somehow at logon.

If the logon server is being interfered with by the kiddies, then nobody
can logon and get the settings.

And, until you get the decent switches online, as soon as the kiddies
you are on to them, they are going to start coming all over themselves with
excitement to play the "Let's see if I'm smarter than the admin" game.

It's like the original Star Wars movie.  They had to break the tractor beam
at it's source, not at the central computer where someone could just
lock it back on.

You can maybe distribute the initial batch file with the static arp in it
one time - that of course will let the kiddies know that something's up.
They won't give you a second chance so you better have a whole collection of
arp entries in that batch file.

Eventually your going to be forced into getting more intelligent switches.
What your going to have to do is put 1 of them at each uplink point - such
as at the entry point of each building, if that is how your laid out - and
then put MAC filters into them.

When that is done at least you can contain it - if the kiddie is doing a
MAC spoof then he's going to be isolated to the building that all the dumb
hubs and switches are on that he is in and all the users in that building
will be trashed - but at least the rest of the school won't be.

> > After a semester or two the kiddies will give up and you won't have to
> > do this
> > anymore.
> More than likely.  Unfortunately this is a legacy network held together
> with band-aids and fencing wire.  I'm gradually making changes to the
> infrastructure, but it all costs money and in this case, it definitely
> won't happen overnight, but it is happening.

It will happen overnight once the kiddies declare war and start making all
your servers unavailable.

Right now you have it at the early stages.  The people your battling are
probably so stupid they are using Windows boxes and just changing the IP,
and don't know the difference between a MAC spoof and a horse hoof.

But once you realize this is a layer-2 battle, and start fighting them
effectively on the MAC front, they are going to learn quick.  Your a lot
more vulnerable than you realize.  There's quite a lot that a knowledgeable
network cracker can do to tear apart a network held together with bandaids
and bailing wire.  You need to start banging the drum now for an immediate
cash infusion, because a year from now when the network is offline for
long periods and people are desperate, you won't have any credibility
unless you have been predicting doom for a long enough time that their
brains remember you have been doing it.

Good luck!


More information about the freebsd-questions mailing list