Date: Mon, 27 Sep 2004 08:03:25 -0400 From: Bart Silverstrim <bsilver@chrononomicon.com> To: Tim Aslat <tim@spyderweb.com.au> Cc: freebsd-questions@freebsd.org Subject: Re: IP address conflicts Message-ID: <3C63F041-107D-11D9-98C2-000D9338770A@chrononomicon.com> In-Reply-To: <20040927141959.789dc1ea@bofh.spyderweb.com.au> References: <20040927085147.7b2d8575@bofh.spyderweb.com.au> <LOBBIFDAGNMAMLGJJCKNCEGBEPAA.tedm@toybox.placo.com> <20040927141959.789dc1ea@bofh.spyderweb.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 27, 2004, at 12:49 AM, Tim Aslat wrote: > In the immortal words of "Ted Mittelstaedt" <tedm@toybox.placo.com>... >> Once again, I must assume that these notebooks legitimately owned by >> students and staff are NOT owned by the people that are changing the >> IP numbers. > > 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. Do what spammers do...set up all the school machines to act as zombies and when you detect the asshats pulling their little trick, flood them with connection requests to poof them off the network :-) >> If you have a situation where you KNOW who is doing it, and they are >> getting away with this, with the full knowledge of the Dean and others >> in the college, >> then you may as well just start looking for another job. If I was in >> your shoes >> I would. > > Nobody is actually getting away with it, it's just frustrating not > knowing who. Doesn't arpwatch look for the mac changes on the network, which could help you track down the MAC which is pulling the address when it shouldn't? I see messages from arpwatch from some of our servers when DHCP leases change. Will at least help you narrow down the suspects...If you get a MAC address, you can run a detailed NMap against them to try identifying platform information as well as get the make/model of their network card from the MAC. That MAC, unless they're spoofing it, will give you evidence to use against them. There's also Nessus you can use on the system once you narrow it down...see what if any vulnerabilities there may be. Not that *I* advocate doing something like this. I'd *never* advocate breaking into another machine just because it was causing problems on your network. Once you have their MAC, you could also watch and see what address that MAC is magically changed to when the "attack" stops...then redirect their traffic using some ARP redirection (etherpeek? dsniff?) to redirect their requests through a local BSD machine acting as a gateway (forwarding packets). Sniff the traffic for awhile until a username comes through when looking for POP mail or some other text-based requests, then you know who it is (or at least who's at that machine). It's your school's network, and usually there's policies in place saying that a user does not have guaranteed privacy to information going over school or university networks (or business networks, for that matter), especially if the hardware is school owned (and you don't really have a way of telling this with this attack, unless you have a list of MACs owned by the school and know for a fact that the user isn't spoofing the MAC). Just some ideas I'd consider. > 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. > > Thanks for the suggestions. Can you contact your upstream provider for a couple static IPs or a static IP that you could use to subnet and NAT your servers for the public off the regular student network? That way the idiots in your own network shouldn't be *able* to affect your web servers, mail servers, etc... Of course, they could continue screwing with your internal servers, but at least this would reduce the damage they inflict.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C63F041-107D-11D9-98C2-000D9338770A>