Why System Administrators should not be given scanning privileges

Its an accountability and validation issue.   Start with the original concept that the primary motivation of System administrators is to keep hosts ‘up and running’ as opposed to a Security officer, whose primary objective is to keep systems secure.   These two objectives can come into conflict.Now, lets take an example, a system administrator has a server with Java on it.   The version of Java is outdated, and has a vulnerability.   They discover that if they apply the patch, it “breaks” an application on the server.  Thus they have no particular desire to fix the vulnerability.   (It generates additional work).   The Security Officer, on the other hand, does a risk assessment to determine whether the risk should be accepted, or whether the service should be disabled (through updating Java) while waiting for a patch. Now, lets talk about what could happen.   The system administrator updates Java, and runs a scan of the host.   Now that vulnerability appears as mitigated, and its off their plate.   The application is temporarily broken.  Then they roll back the patch.   Until the Security Officer runs a rescan, that vulnerability appears as mitigated.  If the system administrator is saavy, they repeat this process immediately after every scan by the Security Officer. This sounds like something that wouldn’t happen, but I’ve seen it before.  Its more common than you think. Other options exist as well, including shutting off a machine, scanning the IP, making the host “disappear” in your security data. I’m a firm believer that System Admins should not be accepting risk.  Acceptance of risk needs to be done at a management level where the decision maker realizes the impact of what they are doing (and honestly, system administrators have a biased view of whether or not to accept risk)

SecurityCenter – Asset list trap

The Trick of Dynamic asset lists, and avoiding the trap

So someone asked me what seemed to be a simple question:

“Can I create an asset list of hosts that have a port responding between 100 and 200.”   A perfectly reasonable question.   The “off the cuff” response would be:

“Sure with the following rules:

  • ALL
    • Port is greater than 100
    • Port is less than 200

On its face it looks like it should do the job,  but it doesn’t evaluate the way we’d think.

Take the following example, a host that has only port 80 and port 201 responding.  This host, based upon the original requirements would not be in this asset list.

Now lets look how its evaluated:

  1. Does the host have a port open greater than 100? (Answer=TRUE, port 201)
  2. Does the host have a port open that is less than 200? (Answer=TRUE, port 80)

1 AND 2 are true, therefore we have fulfilled both requirements of the ALL clause, and therefore the host is placed in the list.

It’s a very tricky trap, something to watch for.

Source: Nessus and SecurityCenter

Nessus Host Summary Report in SecurityCenter

This is available as a SecurityCenter report template.


While SecurityCenter has extensive reporting features, sometimes we just want to replicate a report type that we’d previously generate using Nessus™.

One of the useful report chapters that can be generated is the Host Summary.

This report chapter generates the following:

A table of vulnerability counts sorted by severity like this:

IP Address Informational Low Medium High Critical

Then a table for each host with the following:

Severity Plugin ID Name

Here’s how this type of report can be generated in SecurityCenter


NAME Host Summary (Nessus)



REPORT STYLE Tenable, Letter


COVER LOGO default









CHAPTER Host Summary

GROUP Host Summary

ITERATOR Host Summary

NAME Host Summary

LOCATION -Group Host Summary

STYLE Default

DATA TYPE Vulnerability

SOURCE Cumulative

QUERY (As needed)








NAME Host Summary


LOCATION -Iterator Host Summary

STYLE Default

DATA TYPE Vulnerability

SOURCE Cumulative

QUERY Tool: IP Summary





DISPLAY COLUMNS IP Address, Info, Low, Medium, High, Critical


NAME Vulnerability List


LOCATION -Iterator Host Summary

STYLE Default

DATA TYPE Vulnerability

SOURCE Cumulative

QUERY Tool: Vulnerability Summary





DISPLAY COLUMNS Severity, Plugin ID, Name

This report is very similar to the one provided in Nessus, however the latter table has Plugin ID first, then severity, as opposed to Nessus, which has severity first, and Plugin ID second.

You can download this template in zip format.


Source: Nessus and SecurityCenter

An interesting take on passwords on the Internet

I’m currently taking a course on Internet History at Coursera. We are currently discussing the very basics of encryption, and the instructor had an interesting idea.   He was talking about the fact that it seems like for every web site we have to create a user name and password.   Most users get to the point where they don’t create a unique password for every web site, they use a common one.   On top of that, it seems like every week there’s some web site that we’re using that has their password file hacked.   The result is we don’t just compromise our account on one web site, but on several.  Gawker was an excellent example of this, but there have been several.

Clearly two factor authentication is one solution to this problem, and Google, in their wisdom, has set up a reasonably easy to use two factor authentication API.   However, the instructor posed an alternative solution, that is quite elegant.

Whenever you go to log into the web site, you put in your user name, and a unique link is sent to your email address.   You go to your email, open up the link, and you’re logged in.   No passwords stored on a million servers, no worrying about keeping different passwords, it’s all done through a unique link system.

Now this does depend upon your email being secure, however, remember, most web sites have a “reset password” option that you can use where it emails you a link to reset your password, so if your email has been compromised, an intruder can reset your password on the web site you have an account on anyway,  so we haven’t really reduced security much.   There is an additional layer of annoyance, but it is an interesting approach to the question of passwords and security.


Source: Nessus and SecurityCenter

Using Nessus Professional Feed and c2a to monitor configuration files on Unix hosts

When you purchase Nessus Professionalfeed, one of the things you can download from the support portal is a utility called c2a.

Using this utility we can use Nessus scans to monitor files (and in particular configuration files) on hosts using the md5sum utility to determine whether or not the file has changed.

To do this we need to:

  1. Download c2a from the support portal and place it on the Unix host we wish to monitor for changes.
  2. Create a list of files we wish to monitor
  3. Use c2a to create a .audit file based upon this list
  4. Create a scan policy that uses this .audit file
  5. Create a scan that runs on a periodic basis that uses this new scan policy

Downloading c2a

C2a can be downloaded from the support portal in the Compliance area, under Compliance check tools.   After you’ve downloaded it, upload it to your Unix host (unless you’ve downloaded it directly to your unix host) and type:

tar -xvzf ./c2a-1.0.2.tar.gz

(This might change slightly if c2a gets updated)

then type:

cd /c2a

Creating a list of files to be monitored

The next step is to create a list of files to be monitored.   This file needs to be plain text, one file per line.   You can either create this file manually using vi, nano, or emacs, or alternatively, generate this file using a creative unix command.

Lets say we want to monitor all the files in /etc.   We could type:

find /etc > etcfiles.txt 

This is a quick and dirty way to generate a long list of files.

Creating the .audit file

Now that we’ve created the list of files to be monitored, we now need to generate the audit file.   Lets assume that we want to use the file we created above, etcfiles.txt.   We’d type:

./c2a.pl -md5 -f ./etcfiles.txt -o etcfilemonitor.audit

and sit back and wait.

After a few minutes, the file etc monitor.audit will be created.   It should look something like this:

# This file is auto-generated with c2a.pl script
# Copyright 2007 Tenable Network Security Inc.
<check_type : "Unix">
 #System : "Linux"
 type : FILE_CHECK
description : "Check MD5 for /etc/passwd"
 file : "/etc/passwd"
 md5 : "789f03cc6078e418b9b759c2d8434b12"

Obviously your .audit is likely to contain multiple items.

If you’re familiar with .audit, you can see that this creates an md5sum of each individual file, and then does a check based upon in.

Now we want to download this file (in this case  etcfilemonitor.audit) so we can put it in a scanning policy.

Creating a Scan Policy

Now that we have a .audit file we need to create a scan policy.   This scan policy, at a minimum, must have the following:

1. Administrative level credentials for the unix host to be monitored, or alternatively credentials with privilege elevation.










2. Plugin ID 21157, Unix Compliance Checks, must be enabled in the plugins section






3. The .audit file you just created must be uploaded to the Unix Compliance Checks area under preferences.







Once we’ve created this scan policy, we’re ready to create our scan!

Creating the Scan

We create a scan of this type just like we do with any other scan, we give it a name, a schedule, and a target list:







Once our scan has completed, if the md5 of the configuration file has not changed, it will come up as an Informational item in our report.  However, if the md5 of the configuration file has changed, it will come up as a high result.


Source: Nessus and SecurityCenter

Patch Management servers and Nessus

If you’ve followed the Nessus blog, you’re aware that Nessus, in addition to doing credentialed scans of a target can alternatively contact a patch management server (several are supported) and retrieve patch information for a target through the server that’s managing it.

Having talked to several people about this functionality, there’s been some confusion regarding it, so I thought a real world example might help:

Example 1

I have three hosts in my network:

  • – WSUS Server
  • – Windows 7 host being managed by
  • – Windows 2008 host being managed by

When I create my scanning policy, I put in the credentials for the WSUS server (not the operating system, but the WSUS server itself), but don’t include operating system credentials for and

In my target range in my scan I put:


When I run the scan, a network based scan is performed of all three targets.   It also discovers that is running a WSUS server, so it puts in the credentials for there, and retrieves patch information for and, since they are in my target range.

When I look at the results, it shows the missing patches on and even though I have not done a credentialed scan of those targets directly.  There Is also additional information in several plugins about the WSUS server itself.

Example 2

We have the same hosts as in example one.

When I create my scanning policy, I put in the credentials for the WSUS server (not the operating system, but the WSUS server itself), and I include operating system credentials for and in the credentials tab of the scan policy.

In my target range in my scan I put:


Now, when I run the scan, a network based scan is performed on, and credentialed scans a performed on and   It retrieves the missing patch information not from, but as a result of the credentialed scans.   There is also additional information in several plugins about the WSUS server itself.

Now, in a perfect world example 1 and example 2 would have an identical list of missing patches.   However, in the real world, patch management servers are not always accurate with respect to the hosts being scanned.   We can take the results of example 1 and example 2 and see if there are any missing patches in example 2 (the most accurate results) that are not in example 1.  We can also do the inverse, look and see if example 1 has any listed patches that appear to have been applied based upon information in example 2.

Source: Nessus and SecurityCenter