Even though the development of NetReg went very fast and was fairly uneventful, we did learn a few lessons which we should share. It is not a great idea to be setting up "root-level" authoritative DNS servers on a whim on your network, but there are some safety tips for doing so. We used the "Bogus Name Server" feature of BIND [2] to tell our legitimate campus DNS servers to not communicate with our NetReg DNS server.

We hoped to not have to require the client to reboot for the new lease to be obtained. In actuality, we were able to get the clients to obtain their new lease without rebooting using the network control panels on the various OS's. This did not appeal to us since the instructions for this process varied greatly based on the platform, so we opted to use the simple process of rebooting. There was another reason too. NetReg checks for new registrations with cron each minute so there is a possibility that a client who registers at one second past the minute will have to wait as much as 59 seconds until their registration entry appears (or they will obtain another temporary "unknown client" lease). At first we planned to have the actual registration CGI program just restart the DHCP server with the new registered client in the configuration file, but this created security issues we did not want to address. The problem is that the CGI program runs as the non-privileged UID of the web server, whereas the DHCP server runs as 'root'. We therefore chose to just have cron check for the new registrations. Because cron has a lower limit of one minute on how often it will run, and because boot times are getting quicker and quicker, we may have to re-address this in the future. For now the solution is that if the client is rebooted before the server reloads [Note 13], they will be taken back to the registration page which will tell them they are already registered and should reboot their computer (again).

Another lesson we learned was about how browsers cache pages. Since the browser's default homepage gets redirected to the NetReg registration page the first time a client boots on the network, it caches the registration page for that address. Once the machine is registered and reboots, the browser reloads the cached version of registration page for the default homepage, which is not correct. Browsers should respond properly by using the "reload" button, however, our tests showed they didn't always do so. We remedied this problem by including two META tags in the header of the HTML of the registration page:

<META HTTP-EQUIV="Expires"
                      Content="0">
<META HTTP-EQUIV="Pragma"
               Content="no-cache">

One pitfall of our current configuration is that the NetReg system runs on a single system. This single point of failure could be disastrous for extremely large sites with very short lease times and high rate of registrations. We plan to eliminate the possibility of failure by implementing multiple servers when the ISC DHCP server supports multiple server configurations. Until then, we have our previous DHCP server configured for operation and only need to load a different configuration on our router to put it back into operation taking over for the NetReg system should a fatal error occur. Also, being a low-end Pentium system running a free OS, we can easily have a replacement up in a short time period.

Security

Since much of the intention of NetReg was to improve security (mostly the management of security-related data), we should mention a few security-related issues we have and have not addressed. One of the more recent hot discussion items in the security realm is "MAC Spoofing." This is a process where a user modifies the MAC address of their ethernet card. This type of change could lead to some interesting events, such as denial of registration for another machine with the same (but valid) MAC address, or denial of service attacks by being given a duplicate IP address by the DHCP server. Also, with this technique one could exhaust all available IP addresses from the server. These such instances could be quite troublesome for a network administrator to track down. These types of attacks could exist with nearly any DHCP system however. Unfortunately, there is currently no known method [Note 15] for the DHCP server to identify a conflict in MAC addresses (since theoretically they are supposed to be unique). It is even questionable whether this is something that servers should be able to test as opposed to the network routers and switches.

On a similar note, what happens if someone decides to not follow our rules and alters their computer's network configuration? For instance, we know it is not difficult to just enter an IP address. A relatively computer literate individual can learn your network topology and addressing scheme without too much difficulty and time. How do you deal with those individuals? We have a fairly crude way of handling this. We wrote a script that will find "rogue" addresses by regularly comparing the IP address leases of registered MAC addresses with MAC addresses that appear in our router's ARP table. We do this with SNMP and Perl in our script which we appropriately named findrogue.

Another thing a "belligerent" person may try in order to bypass NetReg would be to enter a valid DNS server (instead of our "fake-root" server). This can be deterred by using non-routable (or "internally routable" only) IP addresses for the temporary leases. Configured this way, the router will discard any packets not destined for the NetReg server.

There are undoubtedly numerous "tricks" that one can come up with to wreak havoc on our system; however, we designed it with functionality in mind more than being a highly secure system. We have developed utilities such as findrogue to help us find any users attempting to bypass it, but it is certainly not a system that an extremely security-conscience organization would want to implement without better studying the security issues.

Wish List

When we decided to create NetReg, we had only a couple of months of non-dedicated time to put toward developing the system. We had a set of features that had to be included, but in our opinion there is much left to be done. We hope NetReg will gain features as we, along with other users, explore the potential of this system.

The first things we'll mention are those which should come as a result of development on the servers which we utilize.

• Support for multiple DHCP servers for redundancy and load-balancing via the "DHCP Failover Protocol" [4]. This is a feature to be included in version 3.1 of ISC's server, but has not yet been implemented.
• Dynamic DNS integrated with DHCP. This is also expected soon with the ISC server [Note 16].
• Better/Smarter DHCP clients are sure to come. ISC is working on implementing authentication into their DHCP clients and server. That, along with general improvements on properly releasing and renewing leases, will help people in all areas using DHCP.

The remaining items are things which we may possibly implement or hope that others will contribute.

• We built NetReg's authentication methods around two common servers (POP or FTP), but we would like to add modules for other more secure and appropriate methods. Obvious alternatives would be to use a Network Authentication Server (NAS), such as Tacacs+ and Radius, or Kerberos.
• As our campus network becomes fully switched to the desktop, it could be beneficial to have the NetReg server use SNMP to make dynamic VLAN assignments to ports on switches based on the profile of an authenticated user.

Summary

As stated, we developed NetReg for our specific needs; however, we knew many others were looking for a solution similar to ours. It is our hope that NetReg will help those who are looking for simple DHCP management. We have done our best to keep portability in mind during development. The code was written in a very modular format with hope that others will contribute better modules and keep NetReg in an ever-developing state. A handful of other universities have put NetReg into production on their network. We hope that it works well for them, and also hope others will find it useful as that was our intent on making it available to the public.

Availability

NetReg has been released under the GNU Public License (GPL) and is available at: https://www. southwestern.edu/ITS/netreg/ . Also, discussion and announcement mailing lists have been created. Information about subscribing to them is available at the above mentioned URL.

Acknowledgements

We would like to thank Bob Paver for both funding and allowing us to pursue this project. Thanks to Rich Graves for pointing out the obvious! Thanks to Pat, Rich, Sharon, and Traci for putting up with us and the phone calls! We would also like to thank Bob Horick for his listening ear and suggestions from the first ideas of this project.

Peter would like to thank his advisor (and friend) Dr. Walter M. Potter...thanks for always believing in me.

Todd would like to especially thank Stephanie, Nathan, and Jacob for accepting his absence (physically and mentally).

Author Information

Peter Valian <valianp@southwestern.edu> is currently an undergraduate at Southwestern University majoring in Computer Science with graduation expected May 2000. When he's not studying or sleeping, he gets to play with cool networking toys and will hopefully develop a script or two to simplify the administration of those toys. Peter's interests are network administration, network security and making Perl do cool things. You can learn more about Peter at https://www.southwestern.edu/~valianp/.

Todd K. Watson <tkw@southwestern.edu> is the "Systems and Network Administrator" for Southwestern University since 1997. At Southwestern he has the privilege of working with some really talented people and faculty. Previously he was pursuing the life of a poor Astronomer. He also worked for a short period at a really cool place called the International Institute of Theoretical and Applied Physics located at Iowa State University. His interests are in Astronomy, programming, systems security, and Unix/Linux advocacy. He has successfully avoided running NT on any system that has any importance. His almost always out-dated homepage can be viewed at: https://www.southwestern.edu/~tkw/.

Bibliography