• Get NetReg from http://www.netreg.org
• Get the Nessus RPM from http://www.nessus.org
• yum install httpd for Apache.
• yum install mod_ssl for https communications.
• yum install dhcp for the DHCP server.
• yum install bind for the DNS server.
• yum install php to support PHP for my modifications.
• yum install php-pear for an easy way to obtain PHP packages.
• pear config-set http_proxy http://xxx.xxx.xxx.xxx:3128 for me, since I’m behind a firewall and using a proxy.
• pear install HTTP_Request to get a PHP class required by my code.
• rpm -i Nessus-3.0.5-fc6.i386.rpm to install the Nessus rpm.
• yum install gcc for the GNU C compiler to build Perl modules.
• yum install openssl-devel for SSL libraries required by some Perl modules.

Now you have everything you need to set up NetReg and Nessus. You can follow the NetReg install guide for the most part, changing only your approach to the Nessus section since you downloaded an rpm instead.

In place of the DNS configuration that allows certain names to be looked up for real, my situation warrants a completely bogus DNS. I have reused DNS configuration from older versions of Netreg, namely:

/var/named/chroot/etc/named.conf looks like this:

server 172.16.1.21 {
bogus yes;
};

options {
directory “/var/named”;
recursion no;
};

zone “.” in {
type master;
file “db.root”;
};

and /var/named/chroot/var/named/db.root looks like this:

. IN SOA netreg.someplace.org. root.netreg.someplace.org. (
1 10800 3600 604800 86400 )
IN NS netreg.someplace.org.
netreg 86400 IN A 172.16.1.21
*. 86400 IN A 172.16.1.21

Unfortunately, Nessus doesn’t make this very easy for us. They have tens of thousands of plugins that can be searched by category, name, etc. The problem is that they don’t easily tell you if the plugin employs a passive or active scan. By passive, I mean that they try to detect the particular vulnerability by crafting packets to expose the flaw. Active, on the other hand, means that they look through registry entries or use other methods requiring privileged access in order to determine if a particular hole is patched.

For a completely effective Nessus scan, you need to have some sort of access to the machine in question and it probably needs to be running certain services. This might be a workable scenario for lab machines where you control everything and maybe have some admin account set up on every one. But for the masses of students and faculty, this simply won’t work. So, you want to limit the list of plugins to only the ones that use passive scanning, but the only way to figure that out in most cases is to look at the code of the plugin to see what it does.

Here is a list of plugins that we use and what each one scans for. We aim for the big name vulnerabilities and simple version checks while trying to keep the list small so the user doesn’t wait too long for the scan to finish when they register. At the end is the line from Variables.pm that you can just copy and paste in order to use the same plugin list. I hope to keep this list updated as frequently as possible. For you Nessus people, give us a way to search for plugins that use passive scanning, please!

• 11808 – Microsoft RPC Interface Buffer Overrun (823980) – Windows
• 11835 – Microsoft RPC Interface Buffer Overrun (KB824146) (network check) – Windows
• 11890 – Buffer Overrun in Messenger Service (real test) – Windows
• 12054 – ASN.1 Parsing Vulnerabilities (NTLM check) – Windows
• 12204 – Microsoft Hotfix for KB835732 IIS SSL check – Windows
• 12209 – Microsoft Hotfix for KB835732 (SMB check) – Windows
• 18027 – Vulnerability in MSMQ Could Allow Code Execution (Network Check) – Windows
• 18028 – Vulnerabilities in TCP/IP Could Allow Remote Code Execution (network check) – Windows
• 18502 – Vulnerability in SMB Could Allow Remote Code Execution (896422) – Network Check - Windows
• 19407 – Vulnerability in Printer Spooler Service Could Allow Remote Code Execution (896423) – Network Check – Windows
• 19408 – Vulnerability in Plug and Play Service Could Allow Remote Code Execution (899588) – Network Check – Windows
• 20008 – Vulnerabilities in MSDTC Could Allow Remote Code Execution (902400) – Network check – Windows
• 21334 – Vulnerability in Microsoft Distributed Transaction Coordinator Could Allow Denial of Service (913580) – Network check – Windows
• 21696 – Vulnerability in Routing and Remote Access Could Allow Remote Code Execution (911280) – Network check – Windows
• 21783 – iTunes AAC File Integer Overflow Vulnerability (network check) – Gain a shell remotely

Make sure you paste this as one line!
$NESSUS_PLUGIN = "11808;11835;11890;12054;12204;12209;
18027;18028;18502;19407;19408;20008;21334;21696;21783";

Determining if a plugin is active or passive is not a clear cut exercise, at least not that I can tell. First, you can view the source of the plugin from the Nessus page for that plugin. If you see something that looks like data is being specifically crafted into a packet of some sort, that may indicate that the plugin is passive. For example, here’s a section from 12054:

ntlmssp = "NTLMSSP" + raw_string (0x00);
ntlmssp += raw_dword (d:1); # NTLMSSP_NEGOTIATE
ntlmssp += raw_dword (d:NTLMSSP_NEGOTIATE_UNICODE |
  NTLMSSP_REQUEST_TARGET | NTLMSSP_NEGOTIATE_NTLM |
  NTLMSSP_NEGOTIATE_NTLM2); # Flags
ntlmssp += ntlmssp_data (data:NULL,offset:0); # workstation domain NULL
ntlmssp += ntlmssp_data (data:NULL,offset:0); # workstation name NULL

It appears that this plugin is building a packet in a certain way in order to test for the vulnerability. Sometimes, the source will contain a comment about how it works, but I don’t see many of those.

You can also look for dependencies on other scripts that handle gaining access to a machine. Here is a bit from 21725:

script_dependencies("netbios_name_get.nasl", "smb_login.nasl",
  "smb_registry_full_access.nasl", "smb_enum_services.nasl");
script_require_keys("SMB/name", "SMB/login",
  "SMB/password", "SMB/registry_full_access",
  "SMB/transport");
script_require_ports(139, 445);

This one is pretty obviously going to look for an entry in the Windows registry to see if a particular item is installed.

Examining the Nessus scan logs can also help. If scripts require access, you will see errors indicating that a plugin doesn’t have what it needs in order to run. There is also some information on the Nessus site about network checks which indicates that if the plugin has that phrase in the name, it uses a passive method.

Maybe if I took the time to learn the Nessus plugin language, things would be more clear to me.

I added functionality to admin.cgi to allow multiple user name/MAC address combinations to be entered at once. Under the covers, this new function calls the manual registration URL over and over for each entry. This way, all the checks and file locking that are already in place for the single manual registration will still be used.

Additionally, these bulk entries are saved into a separate file. I also provide new functions to load the registrations from this file into NetReg and to clear them out. So, you can clear all registrations without having to enter the bulk registrations all over again. After you clear all registrations, you simply reload all of your previous bulk registrations from the special file with the push of one button.

Now, for the scary part. I wrote all of this new functionality using PHP. I don’t know Perl very well (in fact I find the syntax mind numbing), so I had to do some trickery to integrate the PHP scripts with the existing Perl. Yes, I am a bad person. I’m sure that Martin Fowler has written a book about my kind and made millions from it. But, if you are not horrified, read on!

I made changes to add new forms and buttons for these functions to the “Manual Registration” page (seemed easier than dealing with the image map of links). Between the submit button and print_footer() call of reg_form() in admin.cgi, here’s what is new:
admin.cgi.txt

These new PHP files are installed in the same directory with admin.cgi:
netreg.php
bulkregstart.php
bulkreg.php
reloadbulk.php
clearbulk.php
viewbulk.php
clearregs.php

The functions to support clearing all registrations are also included in these changes.

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.