IP address conflicts

Bart Silverstrim bsilver at chrononomicon.com
Fri Oct 1 12:30:57 PDT 2004

On Sep 27, 2004, at 12:49 AM, Tim Aslat wrote:

> In the immortal words of "Ted Mittelstaedt" <tedm at 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.

More information about the freebsd-questions mailing list