IP address conflicts
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
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
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