• Login
• Become a member
• RSS
• Part of the TechTarget network

Let's face it; unless you have a 10-node test network, running a full network scan is a sure-fire recipe for crashing systems and dragging performance. I have seen a Nessus scan cause an entire QA subnet to grind to a halt due to open connections that exhausted server memory. You can avoid this scenario by dividing networks into small, manageable IP spaces and maintaining data in a spreadsheet. This approach allows for more intelligent scanning, even when using common off-the-shelf or open source tools that lack heavy enterprise management features.

Required Tools

You will need a spreadsheet program such as Microsoft Excel or OpenOffice (openoffice.org). For scanning tools you may use your commercial scanner, or download Nessus (nessus.org) and NMAP (insecure.org).

Step one: Collect inventory

Create a spreadsheet that lists all the systems you manage and the following columns:

Systems Managed

Internal IP Address

External Address

Host Name

FQDN

OS	Version	Purpose	Type	System Owner	Criticality

So it might have a record set like the following:

Systems Managed	Internal IP Address	External Address	Host Name	FQDN	OS	Version	Purpose	Type	System Owner	Criticality
(System)	192.168.1.23	65.214.43.37	web02	www.infosecmag.com	LINUX	2.4.2	Public Webserver	Server	MIS Group	High

Completing the initial inventory of your network will take some doing, and it may require an overnight scan to cover the entire network. However, once you have the inventory you won't need to resort to mega scans for a long time. If you have an inventory of your network already, then you can jump to step two.

For large networks it's best to start with an NMAP or Nessus scan to collect the host names and related information. The owners and purpose data will take some time to populate, but this data may be gathered over time. Once you unplug a highly vulnerable system on the network, the owner usually becomes apparent very quickly. At the very least, define the IP addresses, host name, FQDN if known and OS information on systems attached to the network. Import existing data to the spreadsheet or run a scan and dump the information out as comma separated values.

Step two: System classification

The next step is to categorize the host list in the spreadsheet by OS, logical and physical locations. Depending on what your network looks like and who uses it, this may vary. For example, I can divide my networks into Boston and New York locations. For Boston, I can subdivide the address space into /24 networks, and the servers on one floor can be separated from the rest of the workstations.

Generally, I recommend that you use the worksheet's sort function to organize the data by criticality, then by purpose. This way, production Web servers, less important desktops and R&D systems are separated even if they reside on the same /24 network. The next major classification would be the OS and version. Such a classification would have a breakdown of the production and QA Web servers, desktops and development systems by OS and version. This is beneficial when a security vulnerability targeting a specific OS and version is announced. You can quickly determine which systems are vulnerable, and the criticality of the system can drive your patching order.

You can organize the data anyway that meets your particular security needs. These are just some helpful choices I have seen work well in the real world. Also, by having your production systems called out, you can take the proper precautions in running your scans as to avoid outages. You may also extend the spreadsheet with other fields as you please.

Step three: Scanning

With your systems list broken down into manageable segments, the next step is to set up your scan jobs. In Nessus, I generally name new scan jobs with the same names used in the spreadsheet. For example, I may have a job named "Production Web servers" that contains the entire list of IP addresses from the relevant server grouping in the spreadsheet, or a job named "New York Desktops," again using the same labels used in the spreadsheet. This approach provides a simplified dashboard-like interface that makes it easier to target specific environments when setting up jobs.

Coordinating job names offers you the benefit of improved performance, because it minimizes the number of plugins used by the scanner to only those needed for a specific platform. In the above example, I have a list of production Web servers. If they all are Linux-based, then my plugin selection can be limited to a handful of platform-specific issues. There's no reason to waste network bandwidth scanning for the latest Windows vulnerability when you have a Linux Web server.

Most scanning tools will accept a list of session profiles as described above. If you are using a tool other than Nessus, check your product documentation for details on how to set up your particular scanner to accept profiles that define a scan session.

If you are using port scanners like Nessus, then it's best to break up your target files into simple tab-delimited text files. For example, I can cut and paste or export the Web servers list to a text file for use by NMAP. NMAP has a flag whereby an external file can be used to enumerate hosts for scanning. The following text is from the NMAP MAN page:

-iL <inputfilename>
Reads target specifications from the file specified RATHER than
from the command line. The file should contain a list of host
or network expressions separated by spaces, tabs, or newlines.
Use a hyphen (-) as inputfilename if you want nmap to read host
expressions from stdin..

It's useful to have both the NMAP and the full-blown scanner working side-by-side. The recent W32/NetSky-Z worm, for example, opened a backdoor listening on TCP port 665. If I only used my preset scan jobs I would need to scan all Windows subnets for the worm, but because I had my NMAP host files configured I was able to execute three commands and use the port flag to only scan for 665. The scans were done in less than 15 minutes.

Building a spreadsheet to divide your network into manageable IP spaces may take some time. However, the result is worth the initial investment when you find you have a powerful vulnerability management system at your fingertips.

NESSUS TECHNICAL GUIDE

  Introduction: What is Nessus?
  How to install and configure Nessus
  How to run a system scan
  Using Nessus Attack Scripting Language (NASL)
  Vulnerability scanning in the enterprise
  How to simplify security scans
  How to use Nessus with the SANS Top 20

ABOUT THE AUTHOR:

George Wrenn, CISSP, ISSEP, is a technical editor for Information Security magazine and a security director at a financial services firm. He's also a graduate fellow at the Massachusetts Institute of Technology.

Join the conversationComment

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.

All Rights Reserved,Copyright 2000 - 2013, TechTarget