NetReg: An Automated DHCP Registration System

Peter Valian and Todd K. Watson

It's almost unfathomable how we ever lived without DHCP. We no longer need to visit each machine and assign it an available IP address, let alone deal with the roaming laptop users that hop around the network with an IP reserved for them on every subnet. DHCP took care of all of that -- machines want IP and network settings; the DHCP server wants to give IPs and network settings. It sounds almost too good to be true.

However, unless you don't care who connects to your network, it can be a virtual nightmare. The tradeoff of having IP addresses dynamically assigned is that you really don't know who is getting that IP. At least with static IPs you know who is connecting when you assign them the address. This goes against an important rule of systems administration -- never, ever trust your users. You ideally want to authenticate users before they get IP addresses. Unfortunately, DHCP does not have this level of built-in security. NetReg is a workaround for the shortcomings of DHCP -- a solution with which we at Southwestern University, as well as several other universities, have had great success.

The Concept

The idea was simple enough -- we needed to have a single source of information linking a Media Access Control (MAC) address or IP address to a specific user ID. We also needed a means of denying access to the network without proper credentials. In addition to functionality, we wanted a nice front-end administration interface that would not require the knowledge of command-line parameters or file names. The interface also needed to be cross-platform so users on UNIX, PC, and Macintosh platforms could access it. The administration interface needed to provide basic search capabilities (e.g., finding the user ID that registered a particular MAC address or finding out what MAC address is using a certain IP address). Most importantly, the user interface for the registration process had to be as simple as possible requiring no technical expertise other than running a Web browser.

The Platform

NetReg needs to run on a dedicated machine because of the unique way DNS is used. Because of our limited budget, we use RedHat Linux on a retired 200-MHz Pentium for 1000 nodes. (The load is negligible even during peak registration periods.) A basic installation of the operating system is needed -- no kernel hacks or windowing system, just basic networking with a static IP address. Almost any platform will work as long as you can build and run the required services. On our Cisco router, we specify the IP of the NetReg machine as the ip helper-address in each subnet declaration of our residential network.

The Services

Three services are needed to make NetReg work: DHCP, DNS/BIND, and HTTP. You must also have Perl installed and have a cron daemon. Again, our goal was to use reliable and low-cost software. We were pleased that we managed to use Open Source, well-known, heavily tested, and reliable servers. We use the Apache HTTP server and the DHCP and BIND servers from the Internet Software Consortium (ISC). All three are Open Source; commercial support, however, may be found through the ISC and other vendors.

Building the Server

DNS

The NetReg system also runs as a ‘‘fake root'' DNS server. Essentially, the DNS server is told not to communicate with any real DNS servers, but instead to resolve all queries against its own database file. Its database file has a very simple, one-line wildcard configuration that tells the server to resolve every address to the NetReg IP address. Use of this will become apparent shortly.

DHCP

The ISC's DHCP server version 3 is crucial to making NetReg possible because of its multiple pools per subnet capability. The first step was to define two IP address pools per subnet for each of our residential network subnets (see Figure 1).

One pool is small and only allows unknown clients to get a DHCP lease for a short amount of time (2 or 3 minutes), and the other pool is larger and grants leases to known clients for longer periods of time (24 hours). Known clients are those that have their MAC addresses defined in the server's configuration file. (More on how a client becomes ‘‘known'' is explained in the following sections.) An unknown client receives a temporary IP address and the NetReg machine IP as its DNS server. A known client receives an IP address and the true DNS server address. A variety of configurations can exist based on the network topology. The best method is to use temporary addresses that are not globally routable.

HTTP

One more server ties everything together -- the HTTP server. We use the Apache HTTP daemon for this server. A basic installation is necessary with little special configuration. The main index HTML page is a simple form with an input for a user ID and password. The only modification made to the configuration is to redirect errors to the main index URL. To do this, we simply add the following lines in Apache's httpd.conf file:

ErrorDocument 404 /
ErrorDocument 403 /

The Process

Figure 2 is a graphical flowchart of the following process. When a client connects to the network via DHCP, the router will forward the ‘‘DHCP Request'' packet to the DHCP server on the NetReg machine. The DHCP server on NetReg determines whether the client is ‘‘known'' or ‘‘unknown'' and grants it the appropriate IP and DNS server information. If the client is unknown (i.e., the DHCP server does not recognize the client's MAC address in its configuration file), then the DHCP server will assign the ‘‘fake root'' DNS (NetReg) server, which resolves everything to itself. So now, if an unknown client opens a Web browser and attempts to access any URL (e.g., http://www.sysadminmag.com/), the ‘‘fake root'' DNS server will resolve the server name to the IP of itself. The HTTP server on NetReg will serve that request with its index HTML file, which is the registration page.

If an unknown client requests a particular file or directory (e.g., http://www.sysadminmag.com/sub/), then the server part of the URL will resolve to the NetReg machine, but it will still want a particular page or directory that probably does not exist. This is where the error redirects apply. The 404 (Not Found) and 403 (Forbidden) errors get redirected to the main index HTML page, which is the registration page.

On the registration page (Figure 3), the user is prompted for his user ID and email password. He is also presented with the full text of the Acceptable Network Usage Policy. The page explains that by clicking the ‘‘Accept'' button, he agrees that he has read and understood the policy. If he does not wish to accept the policy, he cannot gain access to the network from his machine.

How It Works

When the user clicks ‘‘Accept'', the form data are sent to a Perl CGI script. The first thing the script does is authenticate the user against our POP server via the Mail::POP3Client Perl module. (All users on our network use this server for mail, so if they have email accounts, they are permitted to use our network.) There are also other authentication modules available with NetReg, such as ftp. Due to the modular code of NetReg, other modules may be written to support authentication schemes.

Once the user is authenticated, the script grabs the user's IP address from the environment variables sent along with the CGI data. The user's IP address is searched for in the DHCP server leases file in order to obtain the user's MAC address. The user's MAC address is then added to the DHCP server configuration file along with other information about that MAC address, such as user ID, browser type used to register, time of registration, and which subnet the user was connected to at time of registration.

A cron script checks every minute for any new registrations since the last time the DHCP server restarted. If there are any, the cron script kills the server and starts it again so it reads the newly written configuration file. (The DHCP server does not currently support HUP, but may support on-the-fly configuration reloads in the future.) During this time, the user is asked to reboot the system. Not only does this provide enough time for the DHCP server to reread its configuration, but also helps some clients with poor implementations of DHCP.

We have found that clients will sometimes not change their DNS server to the real DNS server when they try to renew their lease. Other times, we have found clients using both the fake and real DNS servers in a round-robin fashion. We opt to tell users to reboot rather than explain how to release and renew a DHCP lease for each platform, while it gives the delay needed by cron to reload the new dhcpd.conf file. (Cron will, at most, only execute scripts once every 60 seconds.) Once registered, our DHCP server configuration will allow users full access to our campus intranet, as well as to the Internet. Users may also roam to any student lab or residential subnet and have the same network privileges as they would from their room, without changing any network setting on their machines, and without having to re-register.

Administrative Interface

NetReg is a great registration system, though the real usefulness comes in the administrative interface, which allows a network administrator to view, search, and manage the collected data. A single Perl CGI program provides an initial view of all subnets (Figure 4) with a graphical representation of the number of clients registered on each subnet. From there, the administrator can view the individual registrations for a particular subnet, perform a search for an individual MAC address, user ID, or IP address (Figure 5), or check the current status of the services running on the NetReg system (Figure 6).

Although you can allow the administrative interface to be accessed through the same HTTP server as the registration page, we chose to set up a separate server to do this. For this server, we used the SSL patched version of Apache with OpenSSL.

There are some features that are built into the administrative interface. For example, if we search for a MAC address we will then be able to query the system for the user ID that registered that address. From there we can see all registered MAC addresses for that user ID, or we can perform a query for the identity of that user ID against our internal directory server. Simple scripts may be written to get statistics on other data, but a quick look can be done with the search function, which is very useful.

Finally, we have the ability to delete a registration entry via the administrative interface. By doing this, when the DHCP client requests a renewal of the current lease, it will be denied a renewal and offered a new temporary lease from the ‘‘unknown'' address pool and forced into the registration process again. If the case arises where an Ethernet card changes ownership, the computer with the card will be allowed access to the network until we force another registration. This can be done when we flush the registrations each semester, or if we discover the computer is roaming for an extended period from its original location.

These features put the power of managing the registrations into the hands of the people who need it, without having them edit configuration files by hand on a system to which they don't need administrative access. Of course, due to the obvious security issues, entry to the administrative interface is protected by a htaccess file.

Security

We designed NetReg with functionality, rather than high-level security in mind. We (and other institutions) have developed utilities to help find users who are attempting to bypass registration, but it is certainly not a system that an extremely security-conscience organization would want to implement without studying potential security issues.

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 modular format with hope that others will contribute modules and keep NetReg in an ever-developing state. A handful of universities have put NetReg into production on their networks. We hope that it works well for them, and also hope others will find it useful because our intent was to make it available to the public.

Availability

NetReg has been released under the GNU Public License (GPL), and is available at: http://www.netreg.org/. Information on discussion and announcement mailing lists is also available at the Web site.

About the Author

Peter Valian (valianp@southwestern.edu) is the System and Network Administrator at Southwestern University. Peter's interests are network administration, network security, and applications development in Perl. You can learn more about Peter at: http://www.southwestern.edu/~valianp/.

Todd K. Watson (>tkw@southwestern.edu) is the Senior System and Network Administrator at Southwestern University. He previously worked for a really cool institute (IITAP) at Iowa State University after abandoning graduate studies in Astronomy there. His interests are in Astronomy, programming, systems security, and UNIX/Linux advocacy. You can learn more about Todd at: http://www.southwestern.edu/~tkw>.