Date: Sat, 2 Oct 2004 11:27:23 -0700 From: "Ted Mittelstaedt" <tedm@toybox.placo.com> To: "Bart Silverstrim" <bsilver@chrononomicon.com>, "Tim Aslat" <tim@spyderweb.com.au> Cc: freebsd-questions@freebsd.org Subject: RE: IP address conflicts Message-ID: <LOBBIFDAGNMAMLGJJCKNCEGMEPAA.tedm@toybox.placo.com> In-Reply-To: <3C63F041-107D-11D9-98C2-000D9338770A@chrononomicon.com>
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 Bart > Silverstrim > Sent: Monday, September 27, 2004 5:03 AM > To: Tim Aslat > Cc: freebsd-questions@freebsd.org > Subject: Re: IP address conflicts > > > > 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. > The problem is that if the attacker has a modicum of intelligence they will have done this to someone elses' system. This is a college. For example, someone in a dorm room just surfing the web gets up to take a piss. As soon as they walk out the door and go down the hall, some joker down the hall runs into their room and in a few seconds changes the IP number of their PC to that of the mailserver then runs out. Bullshit like this happens all the time. The only solution is to use managed switches with a modicum of intelligence to where you can build a MAC filter that disallows packets that originate from the end users that have the same MAC as the mailserver, (to block spoofers) and that allows you to dump the internal MAC table. That way when someone pulls their fun your going to see their MAC in your routers, and you can then look at the switches and see exactly what port is being used. Ted
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?LOBBIFDAGNMAMLGJJCKNCEGMEPAA.tedm>