From: Robert Lowe (Robert.H.Lowe@lawrence.edu)
Date: Tue Oct 14 2003 - 12:14:53 CDT
John Crowley wrote:
> To #1, that was something I thought about myself. It actually would be
> easy to do with the code I wrote. I think if you change the if statement
> to:
> if($_ =~ /$FORM{'user'}/)
> instead of
> if($_ =~ /$RECORDS{$IP}/)
>
> it will block based on username. I decided that for when we get DMCA
> subpoenas it would be better to take the violating machine off instead of
> the user.
They'd just get one of their friends to register it for them.
> You are correct on #2 though. However we don't see a lot of MAC spoofing
> here. And you still have the potential problem of someone manually
> setting a real DNS server manually.
I used to see this regularily. I had scripts that used a simple Berkeley
dB to track the MAC/IP address relationship over time using arp tables,
as compared with leases. It would eventually find all those who were
manually configuring IP addresses.
> Setting up black hole lists on
> switches and routers is not a bad idea, and would resolve these issues.
> Our network guy here is pretty crunched, so I wanted to be able to get
> this restriction setup useable by our help desk.
>
>
> I've been thinking about an alternate netreg setup actually. We plan on
> creating a different netreg server for our faculty and staff. I am
> debating giving this system a copy of our zone file, so before you
> register you can still get to on campus resources.
Simply delegate from the bogus root zone, rather than making a copy of
the zone(s). Only queries for that domain will be forwarded -- all others
will be answered directly. You probably already did something similar to
counteract the effects of Blaster.
Otherwise, make it a slave for the zone(s). If you've delegated internally
(I have 80+ internal zones), then slaving can give you finer granularity
to allow access to some zones, while restricting others.
> Off campus DNS would
> still resolve to the netreg box.
I don't follow this. You allow access to this box from off-campus?!
-Robert
> An alternate idea to this is only allowing our email server to resolve, so
> everything but email is restricted, but you will still be able to receive
> information on why you are restricted via email.
>
> John Crowley
> Unix Systems Administrator
> Smith College
>
>
>>Looks good, John! I wonder how useful this functionality would really
>>be though, for a couple of reasons: 1) it's hard to restrict a person,
>>which is usually what you really want, and 2) it's easy to get another
>>MAC address. To really stop a MAC address, I'd rather create a blackhole
>>list in a switch or router, which is effective even if someone manually
>>assigns themselves an IP address. What do you think?
>>
>>-Robert
**********************************************************************
To unsubscribe from this list, send an e-mail message to
majordomo@southwestern.edu containing a single line with the words:
unsubscribe netreg
Send requests for assistance to: owner-netreg@southwestern.edu
**********************************************************************
This archive was generated by hypermail 2.1.4 : Thu Aug 12 2004 - 12:01:41 CDT