Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 28 Sep 2004 01:00:34 -0700
From:      "Ted Mittelstaedt" <tedm@toybox.placo.com>
To:        "russell" <russm-freebsd-questions@slofith.org>
Cc:        "freebsd-questions@FreeBSD.ORG" <freebsd-questions@freebsd.org>
Subject:   RE: IP address conflicts
Message-ID:  <LOBBIFDAGNMAMLGJJCKNCEGEEPAA.tedm@toybox.placo.com>
In-Reply-To: <1B8BF170-110A-11D9-B224-000A95DA456C@slofith.org>

next in thread | previous in thread | raw e-mail | index | archive | help


> -----Original Message-----
> From: owner-freebsd-questions@freebsd.org
> [mailto:owner-freebsd-questions@freebsd.org]On Behalf Of russell
> Sent: Monday, September 27, 2004 9:52 PM
> To: Ted Mittelstaedt
> Cc: bsdfsse; freebsd-questions@FreeBSD.ORG
> Subject: Re: IP address conflicts
>
>
> On 28/09/2004, at 1:25 PM, Ted Mittelstaedt wrote:
>
> >> or use a tool like arpwatch that is specifically designed to let you
> >> know when MAC/IP relationships change on your network.
> >
> > You don't even need to do that - any router on the network is going to
> > log
> > the MAC address because they will see the arp change, as will the other
> > servers.
>
> yeah, of course they'll see the change. but what will they do about it?
> update their internal ARP table and that's about it, unless they're
> smart enough (and correctly configured) to do more. arpwatch is simple
> to install and will notify you straight away when things happen that
> might need your attention.
>

My guess is that the phone calls from the people that suddenly cannot get
mail are as effective as arpwatch would be in this situation.

Even if arpwatch notifies him the instant it happens he's still going to be
screwed
without a managed switch the offender is coming from.

Don't get me wrong I'm not advocating against putting more monitoring
on the network.  It is just with this situation no amount of monitoring
is going to compensate for a bunch of dumb, unmanaged hubs all tied
together.  There's a danger of putting too much energy into software
when what is going to help most is more powerful hardware.

It's actually amazing that he's not already melted down under a host of
broadcast storms and such already.  From the description it sounds like
the Ethernet rules have been broken many times here already.

> >> you log the MAC addresses of all the fixed workstations in the school,
> >> then when one of them starts doing the wrong thing you know *exactly*
> >> where to go to nab the culprit.
> >
> > How, exactly?  Do you think that he has a list of all MAC addresses on
> > the
> > network and who is using them?
>
> the educational institutions I've worked in tend to be pretty anal
> about having a database of what computers they own and where they're
> located - something to do with stopping people from walking off with
> their assets. if your vendor is good they'll provide the machine MAC
> address along with the serial number and amount of installed RAM. if
> not then there's some walking to do. spend half a day and document the
> fixed machines on the network.
>

He's already said they have over 2K nodes on the
network many of which are student-owned laptops.  You could take a month
on something like this and still not have all of them.  Not to mention
that in a few seconds the owner of the offending system can easily
spoof the mac address to a fake one, or more likely, that of another,
innocent, machine on the network.

> > Getting the MAC address is not the problem.  Finding it on what is
> > essentially
> > a completely flat network is.  You need managed switches for this so
> > you can
> > see what port the offending MAC address is on.
>
> now you're assuming that there's documentation as to what ports come
> out at what wall points, and that there's not still a lab full of
> dead-ass old machines sitting on 10Base2.
>

He already said most of his hubs are non-managed.
To do any kind of tracking down to the port level means these hubs
are going to have to be replaced with managed switches.  When that happens
you would definitely document the wiring if you haven't already.

And as far as thinnet goes, I wouldn't pay a lot of attention to that
because large thinnet segments go down so much already a few more
problems won't even be noticed.  Any of his thinnet chains are going to
have to terminate in a switch eventually, you just make sure that
the port they terminate in is in a managed switch.

> >> If it's not one of the fixed
> >> workstations then you've got a bit more work to find the kiddie, but
> >> it's nothing insurmountable.
> >
> > Unless of course the kiddies are using made up MAC addresses like
> > BADBEEF, DEADBEEF, CO1DCOED, and such.
>
> I'm assuming here, having worked in uni computer labs and seen this
> sort of crud being done, that what's happening is someone is changing
> the network settings on a PC... I don't recall seeing a text field next
> to the "enter your IP address" box that says "enter your MAC
> address"...
>

That is because it is not in that location.  The MAC address is setup by
the nic device driver, not by the OS.  Most Windows nic device drivers
have a field where a user-defined MAC address can be entered.

For example, on a convenient system here, Win2K on a Taiwanese motherboard
based on the VIA chipset, under the Administrator user you go:

Start->Settings->Network & Dialup COnnections->right click Local Area
Connection->
Properties->then click the Configure button underneath the VIA Rhine II Fast
Ethernet Adapter->click the Advanced tab->click Network Address and change
the radio button
from Not Present to Value, then type in the new MAC address in the box to
the right.

Ted



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?LOBBIFDAGNMAMLGJJCKNCEGEEPAA.tedm>