Using NetReg to Check for Viruses and Patch Deficiencies

Ronald Nutter

Using DHCP to handle IP addresses frees administrators from manually assigning the settings for every workstation or network device and reduces the chances of error. In today's environment, you need to know that every device is authorized to be on the network, is free from viruses, and is devoid of any serious patch deficiency. The trick to using this type of solution is to implement it so that users can't opt out of being checked before accessing the network.

In this situation, NetReg (an automated DHCP registration system) provides an option to consider. This package, which was written by Peter Valian and Todd K. Watson at Southwestern University in Georgetown, Texas, has potential beyond its first intent to help manage the assignment of IP address on just about any size network. To take advantage of NetReg, do a barebones installation of whatever Linux distribution you are using. Then, install the development tools options so that you can compile everything that you will be downloading but nothing extra, such as BIND, Apache, etc. If these are accidentally installed, uninstall them or reinstall the OS without these options selected.

The base package consists of DHCP and BIND from the Internet Systems Consortium (http://www.isc.org), Apache from the Apache Software Foundation (http://www.apache.org), and your choice of Linux distributions on which to run the package. DHCP gives out what can be a non-routable IP address that will initially allow the network device to talk to a limited number of devices on the network.

BIND is used to set up a bogus DNS service that will give out the same IP address regardless of which host and domain name is provided to it for resolution. The IP address that will be given out is the address of the NetReg server. As soon as the workstation opens up a Web browser, the user is "forced" to a registration Web site served up by the Apache server running on the computer that is running DNS and DHCP.

The user is prompted to review an accepted computer/network use policy, enter a username and password, and click on a submit button to finish the process. A CGI script then uses one of several potential sources of authentication -- POP3, FTP, IMAP, or LDAP, or AD (Active Directory) -- to verify that the supplied credentials are valid. When you get the latest available modules to implement NetReg, you should also be able to authenticate against an Active Directory configuration. Once this step is successfully completed, a new entry is made to a temporary DHCP leases file. At this point, users are presented with a Web page telling them that the registration process is complete and that they need to reboot. This buys some time for a background process to run.

Using a supplied script schedule with cron to run at one-minute intervals, a quick check is made against the temporary DHCP file to see whether the date and time are different from the main DHCP configuration file. If the time/date of the files disagrees, DHCP is temporarily shut down allowing the current DHCP configuration file to be copied to a backup file name, the temporary DHCP configuration file to be copied over the main configuration file, and the DHCP service to be restarted.

Once the workstation that completed the registration process has completed the reboot process and has issued a DHCP request for a workstation address, the DHCP service looks up the MAC address. If the device's address is found in the DHCP configuration file, it becomes a "known" device and is given an IP address and other information from a different pool from a subnet that is routable on your network. The workstation will now receive the IP address of the DNS servers used by other devices on your network.

As a part of the basic NetReg system, an additional CGI script is included that gives you "Admin" access on the information being collected. This admin script is placed in a separate directory that is password protected and requires an SSL connection to access. You can view the addresses assigned to each subnet, see the OS, browser, MAC address, and username associated with each registered workstation on the network. You can also delete a workstation and force it to be re-registered if necessary. Search options are also available from this same interface to allow you to search by IP address, MAC address, username, etc.

The setup I've described so far doesn't sound like it would check for patch vulnerability or the potential presence of viruses, and it doesn't. However, I wanted to paint the stage of the main building block so you can better understand the two options we will look at and how they can best work for you.

Putting It Together

Depending on your level of experience putting Linux solutions together, you can just do this yourself or consult one of two how-to PDFs (available from http://www.netreg.org/contrib/) to help you get things up and running as quickly as possible. The PDFs also can serve as checklists to make sure that you don't miss any steps along the way.

If you are comfortable putting together pieces and parts on your own, there is a newer version of the CIDR module that you can download from the NetReg Web site (http://www.netreg.org) that will not require that the DHCP service be temporarily shut down to put a new file in place. The use of this file isn't currently covered in the how-to PDFs available on the NetReg site so that is left as an exercise for the reader.

The how-to PDFs contain links to the different modules required to get the entire NetReg package to work, which is a very useful feature. You may occasionally find a link that no longer works because a newer module has come out. Note any differences because you may need to find the exact version to address a dependency in one of the other modules. When setting up my first NetReg system, I ran across a compatibility problem in one of the Perl modules that was fixed by downgrading a different module. When I put together another NetReg system a few weeks later, I didn't have any trouble because the problem module had been upgraded.

Before going to production with this first part of NetReg, take a few minutes to make sure you are ready for the next step. Apply the latest updates for the version of Linux that you are running. Then, go ahead and turn up iptables. You will want to allow ports 80, 443, and 53 (tcp and udp) to respond from all parts of your network. It would be a good idea to restrict SSH access to just the subnets from which you will need to access the console.

Add-Ons

Make sure that everything you have put together so far is running without any problems before implementing any add-ons to NetReg. This will make the troubleshooting process a lot easier. Depending on which add-ons to Netreg you put on your system, changes to the iptables list of allowed ports will probably be needed at the point you install them.

Once you are happy with how things are running, look at the Contrib section of the NetReg site (http://www.netreg.org/contrib/). You will see two add-ons that can enhance the operation of the system you have put together to help trap problems before they become a bigger headache. The "Reggie" add-on from Brown University offers some interesting possibilities. This add-on uses the Perl Nessus engine (Net::Nessus::ScanLite) to scan for vulnerabilities that can lead to viruses or the presence of actual viruses themselves.

Nessus

For the add-on from Brown University to work, the Nessus package will need to be installed. Nessus installation is as simple as downloading and running a .sh script. You are walked step-by-step through the installation process, which should only take a few minutes. Nessus, like anti-virus packages, is only as good as the latest set of signatures on which it is running.

A script is created during the Nessus installation that helps automate the process of downloading the latest scanning signatures. With a little keyboarding with crontab -e, you can have the update script run automatically on a daily basis. Because not all viruses can be tested for with Nessus, there is another possibility to consider -- testing to make sure that users actually have some type of anti-virus software installed on their computers. This would require that you get a little more under the workstation's hood to adjust how the tests are performed.

With Brown University's add-on to NetReg, you start running MySQL to keep track of the results of the scanning of the network. A side benefit to this particular add-on is that when a workstation is locked out of Internet access, the user in question is sent an email stating why they have been locked out, what tests their computer failed, and containing a customized set of instructions for fixing the problem that exists on their computer.

LDAP and MySQL

If you aren't using LDAP as a means of authentication on your network, you will need to re-evaluate that decision to get the full benefit out of Brown University's add-on to NetReg. The portion of the add-on that emails the user whose machine is having a problem needs to see an LDAP server so that it can access information about the user, such as his email address.

The Reggie Perl script handles the tasks you will use to accomplish everything that this NetReg add-on can do for you -- collecting information about all reachable machines in each subnet on your network; identifying the actual user associated with a machine; notifying the user that their machine has a problem and provide instructions on fixing it; rescanning the machines identified as having problems; removing the machine as necessary when identified problems have been resolved; and purging those entries that have been notified of a problem out of the dhcp database when they have not fixed the problem within 24 hours.

The setup for this add-on will be a little more involved than setting up the NetReg system. The information on setting up MySQL assumes you already have some knowledge of how to install/use MySQL. If you haven't used MySQL at this point, there are several good books available that can provide a good grounding before proceeding with MySQL part of this implementation. You will want to become familiar with backing up/restoring the data, performing integrity checks on the databases, etc. To make things easier, look at the MySQL Administrator currently under development and available from the MySQL.com Web site.

Another way to build upon your NetReg system comes from Saint Mary's College. They took a similar approach but ended up with a different result. The Saint Mary's version provides for categorized blocking -- virus, DMCA violations, missing Windows patch level, and a generic category that can be used for just about anything. There is a parameter in the comments field called "reason" that will let you specify the exact reason that the user is being blocked. Either of these options can help you identify machines infected with viruses or patch deficiencies. I recommend checking out both of these add-ons to see which will best fit your needs.

Ron is the Network Infrastructure and Security Manager for Georgetown College in Georgetown, Kentucky. He has been in the Networking field for 15 years working with a variety of platforms including NetWare, Microsoft, IBM AS/400, and 3090's.