·:[ Jason On A Shtick ]:·
• • • • •

One feature missing from NetReg is the ability to clear all registrations in order to force network users to register again. Forcing everyone to register again gives another opportunity to scan their machines for vulnerabilities with the Nessus ScanLite plugin.

All that needs to be done to clear registrations is to empty the netreg.registered file contents. NetReg stores registrations in this file in the form of a dhcpd.conf host entry. The dhcpd.conf file includes this NetReg file in order to pick up the known hosts that have registered. Making any change to this file will trigger a dhcpd restart via the refresh-dhcpdconf script, then all hosts will be unknown again. However, the dhcpd server will remember the leases that it has given out, so these need to be cleared, as well.

I added a function to the admin.cgi script to clear all registrations by emptying out the netreg.registered file (this will be shown in a following post that covers other changes to admin.cgi). I made corresponding changes to the refresh-dhcpdconf script to look at the size of the netreg.registered file and if it is zero, also remove the dhcpd.leases files (see previous post with refresh-dhcpdconf).

The result is a button on the admin site to clear all registrations that empties the netreg.registered file, triggering the clearing of dhcpd leases and a dhcpd restart.

At the heart of NetReg is a script that examines the NetReg user registrations and restarts dhcpd to pick up any new entries. This script gets run by cron every minute, so during peak user registration periods (like after all registrations have been cleared during a holiday break) it may stop and start dhcpd many times in a row.

I changed this script for a few reasons.

1. I believe it contained a bug from much older versions of NetReg in the loop logic that checks a certain number of times to make sure dhcpd restarted correctly.
2. I wanted it to mail someone when something bad happened.
3. The original version would leave a bad registration file in place and not restart the dhcpd server. I wanted it to replace the last good copy and keep on chugging. Since file locking was introduced into NetReg, bad registration files have not really shown up. They were mostly a product of concurrent writes clobbering each other.
4. I wanted it to preserve a copy of the registrations and dhcpd lease logs when we choose to clear out everything. That way, we’d have something to go back and look at in case we needed to audit who had what IP when something caught our attention.
5. Most things in NetReg are laid out for installation on Fedora Core, but this script survived a long time without being changed to match.

Here is the entire script as I have changed it:
refresh-dhcpdconf

During really heavy registration times, we have seen the dhcpd server not restart. The only thing logged about it is the basic message "dhcpd: dhcpd startup failed". I have recently increased the sleep duration between stopping and starting dhcpd, thinking maybe the server or its listening socket didn’t have time to clean up before starting again, thus causing it some problem. However, the loop with the grep/awk that looks for the server to be running succeeds. We never get mail about the problem, just complaints that registrations are not working. Maybe we need to be checking the return from starting the service.

The NetReg configuration in Variables.pm only allows you to enter a base and uid that will be used to filter the authenticating users. For example:

$LDAP_BASE = "ou=xx,dc=xx";
$LDAP_AUTH_ATTR = "uid";

is all that you get in order to specify how to find a user’s entry in the LDAP tree. In register.cgi, these variables are used to build a filter to find the user:

my $filter = "($LDAP_AUTH_ATTR=$user)";
my $cmsg = $ldap->search(base   => $LDAP_BASE,
  scope  => 'sub',
  filter => $filter,
  attrs  => [$LDAP_AUTH_ATTR]);

The school has special user accounts for organizations, such as “tridelta”. When registering for network access, they want real user accounts to be used for authentication so that there is some record of who actually owns and is using the account. Unfortunately, these special accounts are not in any different sort of LDAP tree that would lend itself to filtering them out. To prevent these special accounts from registering, I made a change to register.cgi to look for a special entry in the “facsimileTelephoneNumber” field:

my $filter="(&($LDAP_AUTH_ATTR=$user)(!(facsimileTelephoneNumber=NETREG)))";

Where return codes from the search are examined, I changed the error message to indicate that you might be failing to authenticate because you are using an organization account:

} else {
  regerr( "Authentication failed!  You must register with your personal
   account, not an organization or special account.", %UINFO );
}

This change allows the facsimileTelephoneNumber field of an account to be set to the value “NETREG” in order to prevent the account from authenticating. They use this setting to mark organization accounts and other accounts that might be flagged in some way.

It would probably be cleaner and more flexible to define this filter in Variables.pm so that it could be easily modified.

The first and most basic customization I made to NetReg was to stick an index.html page in front of the registration.html file that is provided with the package. Easy stuff. We just wanted a disclaimer page with the university’s use policy up front before the login page.

While consulting for a small liberal arts college, I have made some customizations to their installation of NetReg. NetReg is an open source project that helps secure a DHCP enabled network. NetReg employs a bogus DNS server, some DHCP server configuration and some ugly Perl scripts to force network users to the NetReg website in order to authenticate themselves before they can gain access.

I will use this blog category to track my customizations so that others might benefit from them – and so that I don’t forget what I did! The version of NetReg being used is 1.5.1 on Fedora Core 5. There is another branch of NetReg known as NetReg2 which uses a database. Here, we are dealing with the vanilla NetReg that does everything in flat files. The vanilla version performs just fine for these folks with upwards of a thousand DHCP users.

We set up NetReg to use LDAP authentication against the school’s Novell NDS in order to authenticate users. The NetReg admin site is also secured this way using mod_authnz_ldap with directives like this:

AuthName "NetReg Admin"
AuthType Basic
AuthBasicProvider ldap
SSLRequireSSL
AuthLDAPURL ldap://xx.xx.xx.xx:389/o=xx
require ldap-user soandso1 soandso2 soandso3

As an added measure of network security, we enable the Nessus ScanLite Perl module. NetReg 1.5.1 can make use of this Perl module that interfaces with the Nessus security scanner in order to scan a user’s machine for vulnerabilities as they register with NetReg.