[unisog] Net Registration Systems
skohrman at honeynet.apu.edu
Thu Apr 15 14:23:50 GMT 2004
We've faced a similar dilemma, and until recently answered it with a
combination of the freeware netreg.org product, some dhcp customizations,
iptables firewalling, and vlans. Recently we acquired the Perfigo product
because it provides an answer to all these issues and then some.
It's not exactly cheap, and we're still in the early phases of
implementation. However, we're pretty convinced that it will fit our needs
based on our evaluation testing.
From: Clarke Morledge [mailto:chmorl at wm.edu]
Sent: Monday, April 12, 2004 9:39 AM
Subject: Re: [unisog] Net Registration Systems
On Fri, 9 Apr 2004, Jonathan Richard Brockmeier wrote:
> What Net Registration Systems that intergrated with DHCP/DNS are being
> I know about:
Well, this is a rather LENGTHY reply (sorry), but we've found this to be a
rather complicated issue. But maybe it might stir some positive discussion
about various solutions.
Here's our dilemma. We looked at netreg but the problem is that you can
spoof the system with static IP addresses. Sure, there are ways that you
can work around this, but we've decided to investigate another approach --
I'd appreciate some feedback from the list to see if we're crazy or not.
We want to assign end user systems to appropriate VLANs at the access closet
level based on either the port number on the switch or the MAC address of
the end user system to determine which subnet you should be on.
By default we want to assign all ports and/or MAC addresses to a particular
registration VLAN. We will hand out DHCP leases for that VLAN that has a
very limited set of access restrictions. When you are in the registration
VLAN, we will allow DNS to work but we will intercept all web access to
direct users to a registration web page (and block all other non-HTTP
traffic). The user will have to do some song and dance (we haven't worked
out the details fully on this yet) to verify that the system is indeed
patched and Windows Updated. Only after we can reasonably verify an approved
system with the appropriate user credentials will we change the VLAN setting
for the port or MAC address to put the user in the appropriate VLAN. By
bouncing the switch port off and on (or in the worst case telling the user
to reboot) we then enable the user to get a new DHCP lease for the new
unrestricted subnet. We record the MAC address of the user so that if the
computer moves to a different spot on the network then we can know exactly
what VLAN/subnetwork to put it in without requiring re-registration.
We think this is less prone to abuse since we can control the VLAN settings
on our closet switches. We will only allow untagged packets ingress into
our switches from our users.
If some system starts misbehaving on the unrestricted subnets, we can flip
their VLAN settings on the switches to drop them either back into the
registration VLAN or onto some other PenaltyBox VLAN until the system can be
fixed (we will use our HTTP/web intercept mechanism -- essentially tricks
you do with iptables on Linux -- to notify users that they've been
Among the challenges we are facing are these:
(1) it would be a whole lot easier to control users if we can restrict users
to one computer per port. But this is sometimes a lot easier said than
done. MAC address locking aside, there is sometimes political and economic
factors involved; e.g. we've got 25 users but only 24 ports -- do we really
have to commit another 24 port switch to satisfy the one user when daisy
chaining a cheap hub will do?
(2) older switches don't always give us the flexibility to assign VLANs the
way we would want them. Years ago, vendors talked quite a bit about using
MAC based VLANs; i.e. classifying traffic into different VLANs based on MAC
address. Unfortunately, until recently it has been difficult to find
infrastructure products that will allow you to classify VLANs based on MAC
addrsses, even though it has long been common to have port based VLANs.
What makes this even more complicated is that vendors tend to implement MAC
based VLANs in proprietary ways. MAC based VLANS are more flexible, IMHO,
since it allows the user the flexibility to move around the network
physically (mobile laptops between dorm rooms and classrooms) and still keep
the system in the appropriate VLAN.
(3) dealing with MAC address spoofing. We have not seen much of this yet,
but I'm sure it is coming.
(4) we are chiefly relying more and more on SNMP to/from our switches to
manage this. I've got some concerns as to whether we can effective pull this
(5) we are assuming that everyone has a web browser .... OK, we've got to
make exceptions somehow since that isn't always the case.
> How do you deal with guests?
This is why MAC address locking does not always appeal in all cases. We've
got places like libraries, student lounges and campus centers where systems
are coming and going all of the time. Our scheme gives us the flexibility
to handle this scenario fairly well. But we will require that guests have
some type of prior campus user account that we use to authenticate against
when new systems are registered.
That's what we are hoping to implement, at least in some preliminary way, by
the end of the summer. This is pretty ambitious, but I'd be willing to hear
somebody try to talk me out of it beforehand :-)
College of William and Mary
Information Technology - Network Engineering Jones Hall (Room 18)
Williamsburg VA 23187
More information about the unisog