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>