NeXpose Admin Guide

NeXpose
Administrator's
Guide
Enterprise Edition
Document version 1.0
Copyright © 2010 Rapid7 LLC. Boston, Massachusetts, USA. All rights reserved. Rapid7 and NeXpose are trademarks of
Rapid7, LLC. Other names appearing in this content may be trademarks of their respective owners.
Contents
Revision history ....................................................................................................................................................... 5

About this guide ...................................................................................................................................................... 6
Who should read this guide ................................................................................................................................................................. 6
Other documents and Help .................................................................................................................................................................. 6
Contacting Technical Support ............................................................................................................................................................. 7
Document conventions ......................................................................................................................................................................... 7
Configuring NeXpose for maximum performance in an enterprise environment ........................................... 8
Configuring and tuning the NeXpose Security Console host ................................................................................................... 8
Scan volume drives resource requirements ................................................................................................................................ 8
Selecting a console host for an enterprise deployment ......................................................................................................... 9
Linux expertise is essential ................................................................................................................................................................ 9
Configuring host memory for optimal performance ................................................................................................................... 9
Setting up an optimal RAID array ..................................................................................................................................................... 10
Maintaining and tuning the NeXpose database ......................................................................................................................... 10
Scan engine scaling............................................................................................................................................................................... 11
Disaster recovery considerations...................................................................................................................................................... 11
Planning a NeXpose deployment ........................................................................................................................ 12
Understand NeXpose key concepts................................................................................................................................................. 12
Understanding what NeXpose does ............................................................................................................................................ 12
Understanding NeXpose components ....................................................................................................................................... 12
Understanding sites and asset groups ........................................................................................................................................ 13
Understanding user roles and permissions in NeXpose ....................................................................................................... 14
Define your goals for NeXpose.......................................................................................................................................................... 14
Don't limit security to compliance................................................................................................................................................ 14
Know your business case to know your goals .......................................................................................................................... 15
Determine "how much NeXpose" you need ................................................................................................................................. 18
Ensuring complete coverage with the fixed-number IP address license ........................................................................ 18
See your network with hacker “eyes,” using scan engines................................................................................................... 18
Setting up NeXpose and getting started ....................................................................................................................................... 23
Understanding deployment options ........................................................................................................................................... 23
A deployment plan for Example, Inc. ........................................................................................................................................... 24
Your deployment checklist ............................................................................................................................................................. 25
Working with sites ................................................................................................................................................ 26
Using sites to your advantage ........................................................................................................................................................... 26
Choose a grouping principle .......................................................................................................................................................... 26
Choose a scan template ................................................................................................................................................................... 29
Create a scan schedule ..................................................................................................................................................................... 30
Setting up NeXpose scan engines ................................................................................................................................................ 30
Setting up sites and scans ............................................................................................................................................................... 32
NeXpose Administrator's Guide 1

Working with scan templates and tuning scan performance ........................................................................... 47
Define your goals for tuning .............................................................................................................................................................. 47
You need NeXpose to finish scanning more quickly .............................................................................................................. 47
You need to reduce consumption of network or system resources ................................................................................. 48
You need more accurate scan data .............................................................................................................................................. 48
Keep the "triangle" in mind when you tune .............................................................................................................................. 48
The primary tuning tool: the scan template ................................................................................................................................. 51
Templates are best practices .......................................................................................................................................................... 52
Understanding configurable phases of scanning ................................................................................................................... 52
Analyzing four sample templates for "tunable" features ...................................................................................................... 53
Do you need to alter templates or just alter-nate them?...................................................................................................... 59
Quick tuning: What can you turn off? .......................................................................................................................................... 60
Fine-tuning: What can you turn up or down? ........................................................................................................................... 60
Modifying and creating scan templates......................................................................................................................................... 63
Configuring general scan attributes ............................................................................................................................................ 63
Configuring device discovery......................................................................................................................................................... 63
Configuring service discovery ........................................................................................................................................................ 65
Configuring vulnerability check settings ................................................................................................................................... 67
Configuring NeXpose to search for files on target systems ................................................................................................. 69
Configuring Web spidering............................................................................................................................................................. 70
Configuring spam relaying settings ............................................................................................................................................. 72
Configuring NeXpose to test for Oracle policy compliance................................................................................................. 72
Configuring NeXpose to test for Lotus Domino policy compliance ................................................................................. 73
Configuring NeXpose to test for Windows Group Policy compliance.............................................................................. 73
Configuring NeXpose to test for CIFS/SMB account policy compliance ......................................................................... 73
Configuring NeXpose to test for AS/400 policy compliance ............................................................................................... 74
Configuring NeXpose to test for Unix policy compliance .................................................................................................... 74
Configuring NeXpose to scan database servers ...................................................................................................................... 74
Configuring NeXpose to scan Web servers ............................................................................................................................... 75
Configuring NeXpose to scan mail servers ................................................................................................................................ 75
Configuring NeXpose to scan CVS servers ................................................................................................................................. 75
Configuring NeXpose to scan DHCP servers ............................................................................................................................. 76
Configuring NeXpose to scan Telnet servers ............................................................................................................................ 76
Using default and customized credential checking ............................................................................................................... 76
Other tuning options ............................................................................................................................................................................ 77
Changing net.ipv4.neigh.default.gc_thresh3 setting ............................................................................................................ 77
Changing scan engine deployment ............................................................................................................................................. 78
Editing site configuration ................................................................................................................................................................ 78
Increasing NeXpose resources ....................................................................................................................................................... 78
Making your environment "scan-friendly" ................................................................................................................................. 78
Managing users and asset groups ....................................................................................................................... 79
Creating roles and defining roles and permissions .................................................................................................................... 79
Understanding roles in NeXpose .................................................................................................................................................. 79
Map roles to your organization ..................................................................................................................................................... 81
Paranoia can be time consuming ................................................................................................................................................. 81
Managing and creating user accounts ........................................................................................................................................ 82
Using asset groups to your advantage ....................................................................................................................................... 83
Managing and creating asset groups .......................................................................................................................................... 84
Managing and maintaining NeXpose ................................................................................................................. 85
Managing global settings ................................................................................................................................................................... 85

Selecting a model for calculating risk scores ............................................................................................................................ 85
Excluding specific devices from scans in all possible sites ................................................................................................... 86
Managing NeXpose Security Console settings ............................................................................................................................ 87
Viewing general configuration settings ..................................................................................................................................... 87
Changing the console Web server default settings ................................................................................................................ 87
Configuring auto-update settings ................................................................................................................................................ 88
Using external sources for user authentication ....................................................................................................................... 88
Viewing console database information ...................................................................................................................................... 90
Changing default settings for NeXpose logging ..................................................................................................................... 90
Changing default scan engine settings ...................................................................................................................................... 90
Entering a new product key or requesting a new key ........................................................................................................... 91
Backing up and restoring NeXpose .............................................................................................................................................. 92
Running NeXpose diagnostics ....................................................................................................................................................... 93
Running NeXpose in maintenance mode .................................................................................................................................. 94
Using the command prompt ............................................................................................................................................................. 95
Troubleshooting ................................................................................................................................................... 99
Addressing NeXpose failure during startup ................................................................................................................................. 99
Resetting account lockout .................................................................................................................................................................. 99
Long or hanging scans ...................................................................................................................................................................... 100
Scan memory issues ....................................................................................................................................................................... 100
Scan complexity ............................................................................................................................................................................... 100
Scan engine offline ......................................................................................................................................................................... 100
Scan stopped by a user.................................................................................................................................................................. 100
Long or hanging reports .................................................................................................................................................................. 101
Reporting memory issues ............................................................................................................................................................. 101
Stale scan data .................................................................................................................................................................................. 101
Out-of-memory issues ....................................................................................................................................................................... 101
Memory Protection ......................................................................................................................................................................... 101
java.lang.OutofMemoryError ....................................................................................................................................................... 101
Fixing memory problems.............................................................................................................................................................. 102
Update failures..................................................................................................................................................................................... 102
Corrupt update table...................................................................................................................................................................... 102
Interrupted update ......................................................................................................................................................................... 103
Corrupt File ........................................................................................................................................................................................ 103
Interrupted Update ......................................................................................................................................................................... 104

Appendix A: Using regular expressions ............................................................................................................105
General notes about creating a regex ......................................................................................................................................... 105
How the NeXpose file name search works with regex ........................................................................................................... 105
How NeXpose uses regular expressions when logging on to a Web site ........................................................................ 106
Appendix B: Using NeXpose Exploit Exposure .................................................................................................107
Why exploit your own vulnerabilities? ........................................................................................................................................ 107
Appendix C: SCAP compliance in NeXpose ......................................................................................................108
How NeXpose implements CPE ..................................................................................................................................................... 108
How NeXpose implements CVE ..................................................................................................................................................... 108
How NeXpose implements CVSS ................................................................................................................................................... 109
Where to find SCAP update information in NeXpose ............................................................................................................. 109
Index.....................................................................................................................................................................111

Revision history
The current document version is 1.0
Revision Date Version Description
June 15, 2010 1.0 Created document.

About this guide
This guide helps you to ensure that NeXpose works effectively and consistently in support of your organization's
security objectives. It provides instruction for doing key administrative tasks:
• configuring NeXpose host systems for maximum performance
• planning a NeXpose deployment, including determining how to distribute scan engines
• managing NeXpose users and roles
• tuning scan performance
• maintaining and troubleshooting NeXpose
Who should read this guide

You should read this guide you fit one or more of the following descriptions.
• It is your responsibility to plan how your organization will deploy NeXpose, whether you're the owner of a
small business, a one-person IT department, or a systems administrator for a medium-size or enterprise-
scale company.
• You have been assigned the global administrator role in NeXpose, which makes you responsible for
maintaining and troubleshooting NeXpose and managing other users.
Other documents and Help

Click the Help link on any page of the NeXpose Security Console Web interface to find information quickly.
You will also find the following documents useful. You can download them from the Support page in NeXpose Help.
NeXpose User's Guide helps you to gather and distribute information about your network assets and vulnerabilities
using NeXpose. It covers the following activities:
• logging onto the NeXpose Security Console and familiarizing yourself with the Web interface
• setting up sites and scans
• running scans manually
• viewing asset and vulnerability data
• creating remediation tickets
NeXpose Reporting Guide helps you to get the most useful information from NeXpose reports so that you can
prioritize remediation tasks and monitor your organization's security posture. It provides guidance for understanding
key reporting concepts:
• using preset and custom report templates
• using report formats
• reading and interpreting report data

NeXpose API guides help you integrate NeXpose features with your own internal systems.
Contacting Technical Support

To contact Technical Support, send an e-mail to support@rapid7.com.
For additional contact information and resources, click the Support link on the NeXpose Security Console Web
interface.
Document conventions
Words in bold typeface are names of hypertext links and controls.
Words in italics are document titles, chapter titles, and names of Web and GUI interface pages.
Procedural steps appear in a blue sans serif typeface.
Command examples appear in the Courier typeface in shaded boxes.
Generalized file names in command examples appear between box brackets. Example:
[installer_file_name]
Multiple options in commands appear between arrow brackets: Example: $ /etc/init.d/[daemon_name]
<start|stop|restart>
NOTES appear in shaded boxes.

Configuring NeXpose for maximum
performance in an enterprise
environment
This chapter provides system configuration tips and best practices to help ensure optimal performance of NeXpose in
an enterprise-scale deployment. The emphasis is on the system that hosts the NeXpose Security Console. Some
considerations are also included for NeXpose Scan engines.
Even if you are configuring NeXpose for a smaller environment, you may still find some of this information helpful,
particularly the sections maintaining and tuning the database, scan engine scaling, and disaster recovery
considerations.
Configuring and tuning the NeXpose Security Console host

The NeXpose Security Console is the base of operations in a NeXpose deployment. It manages NeXpose Scan
Engines and creates a repository of information about each scan, each discovered asset, and each discovered
vulnerability in its database. With each ensuing scan, the console updates the repository while maintaining all
historical data about scans, assets, and vulnerabilities. The console includes the server of the Web-based interface for
configuring and operating NeXpose, managing sites and scans, generating reports, and administering users.
The console is designed to meet the scaling demands of an enterprise-level deployment. One console can handle
hundreds of scan engines, thousands of users, and any number of reports as long as it is running on sufficient
hardware resources and is configured correctly.
Scan volume drives resource requirements

In an enterprise environment, the console's most resource-intensive activities are processing, storing, and displaying
scan data. To determine resource sizing requirements, consider these important factors:
• The number of IP addresses that NeXpose will scan: Every target generates a certain amount of data for the
console to store in its database. More targets mean more data.
• The frequency with which NeXpose will scan those assets: Scanning daily produces seven times more data
than scanning weekly.
• The depth of scanning. A Web scan typically requires more time and resources than a network scan.
• The amount of detailed, historical scan data that NeXpose will retain over time: To the extent that scan data
is retained in the NeXpose database, this factor acts as a multiplier of the other two. Each retained set of
scan data about a given target builds up storage overhead, especially with frequent scans.

Selecting a console host for an enterprise deployment
The NeXpose Security Console is available in a plug-and-play hardware Appliance and in Windows and Linux
software versions that can be installed on your organization's own hardware running 32-bit or 64-bit operating
systems. The Appliance is the most convenient solution and the easiest to maintain. Its resources are ample for
handling the overhead of smaller and most mid-level deployments.
The software version of the console is more appropriate for bigger deployments since you can scale its host system to
match the demands of an expanding target asset environment. At a certain level, the Linux offering is not only
recommended but required. NeXpose incorporates a PostgreSQL database engine. PostgreSQL is stable on both
Linux and Windows, but it is not designed to scale easily on Windows because its memory management and I/O
architecture are geared for UNIX operating systems.
Rapid7 recommends the following hardware configuration to host the console in an enterprise-level deployment. The
definition of "enterprise-level" can vary. But experience with past deployments indicates that 25,000 IP addresses or
more, scanned with any reasonable frequency, warrants this recommended configuration:
• vendor: preferably IBM or Hewlett-Packard (Rapid7 tests these products in its lab)
• processor: 2x Intel quad-core Xeon 55xx "Nehalem" CPUs (2 sockets, 8 cores, and 16 threads total)
• RAM: 48-96 GB with error-correction code (ECC) memory; some 2-socket LGA1366 motherboards can
support up to 144GB, with 8GB DDR3 modules
• storage: 8-12 x 7200RPM SATA/SAS hard drives, either 3.5" or 2.5" (if the chassis can only support that
many drives in this form factor); total capacity should be 1+TB
• network interface card (NIC): 2 x 1GbE (one for scans, and one for redundancy or for a private-
management subnet)
Examples of products that meet these specifications include the following:
• HP ProLiant DL380 G6
• IBM System x3650 M2Y
Your IT department or data center operations team may have preferred vendors. Or, your organization may build
"white box" servers from commodity parts.
Linux expertise is essential

If your requirements dictate that NeXpose run on a Linux-based host, consider the level of expertise in your
organization for maintaining a Linux server.
Note that Rapid7 tests and officially supports NeXpose on the following Linux distributions:
• Red Hat Enterprise Linux 5
• Ubuntu 8.04 LTS
NeXpose is also reported to work on a number of other distributions, although Rapid7 does not officially support
them. For more information about specific operating system support, please contact Rapid7 Sales or Support.
Configuring host memory for optimal performance

As indicated in the preceding section, 48 to 96 GB of RAM is recommended for enterprise deployments of the
NeXpose Security Console. Generally speaking, the console should have 8 GB of RAM for performing its various
functions. The remaining amount of RAM should be sufficient to cache the entire NeXpose database in memory and
so minimize disk access for read-only SQL queries.

To project how much the database will grow, note its current size based on current target count and scan frequency.
Then, factor in the projected maximum numbers for these parameters. See Scan volume drives resource requirements (on
page 8). Depending on these variables, a production database can grow at a rate of 5 to 10 GB per week.
Storing the entire database in RAM is a best practice that optimizes console performance. It minimizes the need for
NeXpose to query data stored on disk, which is much slower than RAM. Another endorsement for Linux is that its
multi-level buffer caching system efficiently manages data that is being cached in RAM, swapping in and out blocks
of data to optimize how the operating system fulfills requests from NeXpose.
More RAM means more speed. However, the cost of RAM starts to become prohibitive above 72 to 128 GB per
node, depending on the type of memory. If the database seems on track to grow beyond that size, consider trimming
old or unnecessary data.
The definition of "unnecessary" depends on your organization. It may be subject, for example, to compliance
requirements that data be retained for a certain amount of time. Or data retention for a certain time period may be a
matter of corporate policy. Otherwise, you can set retention criteria based simply on whether a given set of scan data
is still useful for any reason.
Setting up an optimal RAID array

It should also be noted that NeXpose cannot completely avoid querying data on disk. So, configuring a performance-
friendly RAID array is important, especially given the fact that disk requirements can range up to 1TB.
Rapid7 recommends arranging multiple disks in a configuration of striped mirrors, also known as a RAID 1+0 or
RAID 10 array, for better random disk I/O performance without sacrifice to redundancy. NeXpose and PostgreSQL
should be installed on this high-performing RAID 1+0 array. The PostgreSQL transaction log should be on
independent disks, preferably a 2-drive mirror array (RAID 1). The operating system, which should generate very
little disk I/O, may share this 2-drive mirror with the PostgreSQL transaction log.
A good purchasing approach will favor not expensive disks but more disks. Rapid7 recommends 8 to 12 disks.
NeXpose, the operating system, and PostgreSQL should each run on its own partition.
Maintaining and tuning the NeXpose database

Given the amount of data that an enterprise deployment will generate, regularly scheduled backups are important.
Rapid7 recommends nightly backups. When NeXpose backs up its database, it goes into a maintenance mode during
which it cannot run scans. So, planning a deployment involves coordinating backup periods with scan windows. The
time needed for backing up the database depends on the amount of data. Rapid7's Professional Services Organization
can provide scripts that automate this process.
A backup saves the following items:
• the NeXpose database
• configuration files (nsc.xml, nse.xml, userdb.xml, and consoles.xml)
• licenses
• keystores
• report images
• custom report templates
• custom scan templates

• generated reports
• scan logs
Rapid7 recommends performing the following database maintenance routines on a weekly basis:
• Clean up the database to remove leftover data that is associated with deleted objects, such as sites, assets, or
users.
• Compress database tables to free up unused table space.
• Rebuild database indexes that may have become fragmented or corrupted over time.
Additionally, a database optimization feature applies optional performance improvements, such as vulnerability data
loading faster in the NeXpose Security Console Web interface. Rapid7 recommends that you run this feature before
running a backup.
For information on performing database backups and maintenance, see Backing up and restoring NeXpose (on page
92).
PostgreSQL also has an auto-vacuum feature that works in the background. Make sure that it is enabled. Future
NeXpose versions will enable it by default.
Scan engine scaling

Like the console, the NeXpose Scan Engine is available as an Appliance or in Windows and Linux software versions.
The Appliance is easier to administer, since it is preinstalled, pretuned and preconfigured. Note that the Appliance is
a "black box," so access is not permitted. If you require or prefer system access to NeXpose, then the software-only
solution is the better option.
To determine how many engines you need, consider the number of target IP addresses, the required scan frequency,
and the number of available scan hours each day.
Empirical lab data indicates that one engine can completely scan 400 to 500 targets IP addresses in an hour. So, for
example, if you have 30,000 live IP addresses and an 8-hour scan window, you need 8 scan engines. This calculation
assumes no significant bandwidth limitations or scan window restrictions. Your results may vary based on your
production environment.
Generally speaking, each added engine provides an incremental, linear boost to scan performance.
For suggestions on where to place scan engines, see Distribute scan engines strategically (on page 20).
For suggestions on optimizing scans, see Working with scan templates and tuning scan performance (on page 47).
Disaster recovery considerations

As previously mentioned, one NeXpose Security Console is sufficient for handling all activities at the enterprise level.
However, an additional, standby console may be warranted for your organization's disaster recovery plan for critical
systems. If a disaster recovery plan goes into effect, this "cold standby" console would require one database-restore
routine in order to contain the most current data.
Disaster recovery may not warrant doubling the fleet of scan engines in the data center. Instead, a recovery plan could
indicate having a number of spares on hand to perform a minimal requirement of scans—for example, on a weekly
basis instead of daily—until production conditions return to normal. For example, if your organization has 10 scan
engines in the data center, an additional 5 may suffice as temporary backup. Having a number of additional engines is
also helpful for handling occasional scan spikes required by events such as monthly Microsoft patch verification.

Planning a NeXpose deployment
This chapter will help you deploy NeXpose strategically to meet your organization's security goals. If you have not yet
defined these goals, this guide will give you important questions to ask about your organization and network, so that
you can determine what exactly you want to achieve with NeXpose.
The deployment and configuration options in NeXpose address a wide variety of security issues, business models, and
technical complexities. With a clearly defined deployment strategy, you can use NeXpose in a focused way for
maximum efficiency.
Understand NeXpose key concepts

Understanding the fundamentals of NeXpose and how it works is key to determining how best to deploy it.
Understanding what NeXpose does

NeXpose is a unified vulnerability solution that scans networks to identify the devices running on them and to probe
these devices for vulnerabilities. It analyzes the scan data and processes it for reports. You can use these reports to
help you assess your network security at various levels of detail and remediate any vulnerabilities quickly.
The vulnerability checks in NeXpose identify security weaknesses in all layers of a network computing environment,
including operating systems, databases, applications, and files. NeXpose can detect malicious programs and worms,
identify areas in your infrastructure that may be at risk for an attack, and verify patch updates and security compliance
measures.
Understanding NeXpose components

NeXpose consists of two main components:
• NeXpose Scan Engines perform asset discovery and vulnerability detection operations. You can deploy scan
engines outside your firewall, within your secure network perimeter, or inside your DMZ to scan any
network asset.

DEFINITION: An asset is a device on your network that is identified by an IP address, such as a computer, router, or printer. Assets are what
NeXpose scans. In the NeXpose Security Console Web interface, the words "asset" and "device" are used interchangeably. In some of
NeXpose's report templates, assets are referred to as "nodes".
• The NeXpose Security Console communicates with NeXpose Scan Engines to start scans and retrieve scan
information. All exchanges between the console and scan engines occur via encrypted SSL sessions over a
dedicated TCP port that you can select. For better security and performance, scan engines do not
communicate with each other; they only communicate with the security console.
When NeXpose scans an asset for the first time, the console creates a repository of information about that
asset in its database. With each ensuing scan that includes that asset, the console updates the repository.
The console includes a Web-based interface for configuring and operating NeXpose. An authorized user can
log on to this interface securely, using HTTPS, to perform any NeXpose-related task that his or her role
permits. See the section titled Understanding user roles and permissions in NeXpose in the NeXpose
Administrator's Guide. The authentication database is stored in an encrypted format on the console server,
and passwords are never stored or transmitted in plain text.
Other console functions include generating user-configured reports and regularly downloading patches and
other critical updates from the Rapid7 central update system.
You can download software-only Linux or Windows versions for installation on your own in-house servers,
depending on your NeXpose license.
NeXpose components are also available in a dedicated hardware/software combination called an appliance. Another
option is to purchase remote scanning services from Rapid 7.
This guide is for installing the software-only version of NeXpose.
NeXpose is "agentless"
NeXpose performs all of its scanning operations over the network, using common Windows and UNIX protocols to
gain access to target assets. This architecture makes it unnecessary for you to install and manage software agents on
your target assets, which lowers the total cost of ownership (TCO) of NeXpose and eliminates security and stability
issues associated with agents.
Understanding sites and asset groups

The console interface enables you to plan scans effectively by organizing your network assets into sites and asset groups.
DEFINITION: A site is a physical group of assets assembled for a scan by a specific, dedicated scan engine. The grouping principle may be
something meaningful to you, such as a common geographic location or a range of IP addresses. Or, you may organize a site for a
specific type of scan.
When you create a site, you identify the assets to be scanned, and then define scan parameters, such as scheduling
and frequency. You assign a scan engine to that site, whether it's a dedicated appliance, NeXpose software installed
on a local host, or a scan engine that is run remotely by Rapid7. You can only assign one scan engine to a given site.
However, you can assign many sites to one scan engine.
NOTE: If you are using RFC1918 addressing (192.168.x.x or 10.0.x.x addresses) different assets may have the same IP address. You can use site
organization to enable separate scan engines located in different parts of the network to access assets with the same IP address.
You also define the type of scan you wish to run for that site. Each site is associated with a specific scan. NeXpose
supplies a variety of scan templates, which can expose different vulnerabilities at all network levels. Template
examples include Penetration Test, Microsoft Hotfix, Denial of Service Test, and Full Audit. You also can create
custom scan templates.

Another level of asset organization in NeXpose is an asset group. Like the site, this is a logical grouping of assets, but
it is not defined for scanning. An asset group typically is assigned to a nonadministrative user, who views scan reports
about that group in order to perform any necessary remediation. An asset must be included within a site before you
can add it to an asset group.
DEFINITION: An asset group is a logical collection of assets to which specified users have access in order to view data about these assets.
These users are typically in charge of monitoring these assets and reporting or remediating any vulnerabilties that NeXpose discovers
on them.
Only designated NeXpose global administrators are authorized to create sites and asset groups. For more details about
access permissions, see Understanding user roles and permissions in NeXpose (on page 14).
Asset groups can include assets listed in multiple sites. They may include assets assigned to multiple NeXpose Scan
Engines, whereas sites can only include assets assigned to the same scan engine. Therefore, if you wish to generate
reports about assets scanned with multiple scan engines, use the asset group arrangement. You also can configure
reports for combination of sites, asset groups, and assets.
Understanding user roles and permissions in NeXpose

User access to NeXpose Security Console functions is based on roles. You can assign default roles that include pre-
defined sets of permissions, or you can create custom roles with permission sets that are more practical for your
organization. See Managing and creating user accounts (on page 82). Once you give a role to a user, you restrict access
in the NeXpose Security Console to only those functions that are necessary for the user to perform that role.
Five default roles exist in NeXpose:
• Global administrator (on page 79)
• Security manager (on page 80)
• Site administrator (on page 80)
• System administrator (on page 81)
• Nonadministrative user (on page 81)
Define your goals for NeXpose

Knowing in advance what security-related goals you want to fulfill will help you design the most efficient and
effective NeXpose deployment for your organization.
Don't limit security to compliance

Many organizations have a cut-and-dry reason for acquiring a product like NeXpose: They have to comply with a
specific set of security requirements imposed by the government or by a private-sector entity that regulates their
industry.
• Health care providers must protect the confidentiality of patient data as required by the Health Insurance
Portability and Accountability Act (HIPAA).
• Many companies, especially those in the financial sector, are subject to security criteria specified in the
Sarbanese-Oxley Act (SOX).
• Merchants, who perform credit and debit card transactions, must ensure that their networks comply with
Payment Card Industry (PCI) security standards.

Compliance goals may help you to define your deployment strategy, but it's important to think beyond compliance
alone to ensure security. For example, protecting a core set of network assets, such as credit card data servers in the
case of PCI compliance, is important; but it may not be enough to keep your network secure—not even secure
enough to pass a PCI audit!
Hackers will use any convenient point of entry to attack networks. A hacker may exploit an Internet Explorer
vulnerability that makes it possible to install a malicious program on an employee's computer when that employee
surfs the Web. The malware may be a remote execution program with which the hacker can access more sensitive
network assets, including those defined as being critical for compliance.
According to a paper published by Carnegie Mellon University's Software Research Institute, viruses, worms, and
other malicious code account for 74 percent of all "e-crimes1". Excluding "non-sensitive" assets from the scope of
your security strategy can expose your network to considerable risks.
A security plan that focuses only on the perimeter also has limitations. Another interesting statistic in the Carnegie
Mellon paper is that company "insiders" account for 34 percent of network security threats. An insider could be a
careless end user or a disgruntled IT employee with access to sensitive servers.
Compliance, in and of itself, is not synonymous with security. On the other hand, a well implemented,
comprehensive security plan will include among its benefits a greater likelihood of compliance.
1
2007 E-Crime Watch Survey, published by Software Research Institute of Carnegie Mellon University
Know your business case to know your goals

If you have not yet defined your goals for your NeXpose deployment, or if you are having difficulty doing so, start by
looking at your business model and your technical environment to identify your security needs.
Consider factors such as network topology, technical resources (hardware and bandwidth), human resources (security
team members and other stake holders), time, and budget.
How big is your enterprise?

How many networks, subnetworks, and assets does your enterprise encompass?
The size of your enterprise is a major factor in determining how many scan engines you deploy. See Distribute scan
engines strategically (on page 20).
What is the geography of your enterprise?

In how many physical locations is your network deployed? Where are these locations? Are they thousands or tens of
thousands of miles away from each other, or across town from each other, or right next to each other? Where are
firewalls and DMZs located?
These factors will affect how and where you deploy scan engines and how you configure your sites.
How is your network segmented?

What is the range of IP addresses and subnets within your enterprise?
Network segmentation is a factor in scan engine deployment and site planning. See Distribute scan engines strategically
(on page 20).

What is your asset inventory?
What kinds of assets are you using? What are their functions? What operating systems, applications, and services are
running on them? Where are these different assets located relative to firewalls and DMZs? What are your hidden
network components that support other assets, such as VPN servers, LDAP servers, routers, switches, proxy servers,
and firewalls? Does your asset inventory change infrequently? Or will today's spreadsheet listing all of your assets be
out of date in a month?
Answering these questions will help you determine not only the scope of your NeXpose license but also the type of
license you acquire. See the section titled Determine "how much NeXpose" you need (on page 18). Additionally, asset
inventory influences site planning and scan template selection.
Does your asset inventory include laptops that employees take home? Laptops open up a whole new set of security
issues that render firewalls useless. With laptops, your organization is essentially accepting external devices within
your security perimeter. Network administrators sometimes unwittingly create backdoors into the network by
enabling users to connect laptops or home systems to a virtual private network (VPN).
Additionally, laptop users working remotely can innocently create vulnerabilities in many different ways, such as by
surfing the Web without company-imposed controls or plugging in personal USB storage devices.
An asset inventory that includes laptops may require you to create a special site that you scan during business hours,
when laptops are connected to your local network.
One possible environment: "Example, Inc."

As you answer the preceding questions, you may find it helpful to create a table. The following table lists network
and asset information for a company called "Example, Inc."
Network segment Address space # of assets Location Asset functions
New York Sales 10.1.0.0/22 254 Building 1: Work stations

Floors 1-3
New York IT/Administration 10.1.10.0/23 50 Building 2: Work stations

Floor 2 Servers
New York printers 10.1.20.0/24 56 Buildings 1 & 2 Printers
New York DMZ 172.16.0.0/22 30 Co-location facility Web server

Mail server
Madrid sales 10.2.0.0/22 65 Building 3: Work stations

Floor 1
Madrid development 10.2.10.0/23 130 Building 3: Work stations

Floors 2 & 3 Servers
Madrid printers 10.2.20.0/24 35 Building 3: Printers

Floors 1-3
Madrid DMZ 172.16.10.0/24 15 Building 3: File server

dark room

What are the "hot spots" in your enterprise?
What assets contain sensitive data? What assets are on the perimeter of your network? Do you have Web, e-mail, or
proxy servers running outside of firewalls?
Areas of specific concern may warrant scan engine placement. Also, you may use certain scan templates for certain
types of high-risk assets. For example, a Web Audit scan template is most appropriate for Web servers.
What are your resources?

How much local-area network (LAN) and wide-area network (WAN) bandwidth do you have? What is your
security budget? How much time do you have to run scans, and when can you run these scans without disrupting
business activity?
These considerations will affect which scan templates you use, how you tune your scans, and when you schedule scans
to run. See Setting up sites and scans (on page 32).
What exactly are the security risks to your organization?

How easy is it for hackers to penetrate your network remotely? Are there multiple logon challenges in place to slow
them down? How difficult is it for hackers to exploit vulnerabilities in your enterprise? What are the risks to data
confidentiality? To data integrity? To data availability?
The triad of confidentiality, integrity, and availability (CIA) is a good metric by which to quantify and categorize
risks in your organization.
Confidentiality is the prevention of data disclosure to unauthorized individuals or systems. What happens if an
attacker steals customer credit card data? What if a trojan provides hacker access to your company's confidential
product specifications, business plans, and other intellectual property?
Integrity is the assurance that data is authentic and complete. It is the prevention of unauthorized data modification.
What happens when a virus wipes out records in your payroll database?
Availability refers to data or services being accessible when needed. How will a denial-of-service hack of your Web
server affect your ability to market your products or services? What happens if a network attack takes down your
phones? Will it cripple your sales team?
If your organization has not attempted to quantify or categorize risks, you can use NeXpose reports to provide some
guidelines. The NeXpose algorithm that produces a risk score for each scanned asset calculates the score based on
CIA factors.
Other risks have direct business or legal implications. What dangers does an attack pose to your organization's
reputation? Will a breach drive away customers? Is there a possibility of getting sued or fined?
Knowing how your enterprise is at risk can help you set priorities for deploying scan engines, creating sites, and
scheduling scans.
Who is your security team?

Are you a one-person company or IT department? Are you the head of a team of 20 people, each with specific
security-related tasks? Who in your organization needs to see asset/security data, and at what level of technical detail?
Who's in charge of remediating vulnerabilities? What are the security considerations that affect who will see what
information? For example, is it necessary to prevent a security analyst in your Chicago branch from seeing data that
pertains to your Singapore branch?
These considerations will dictate how you set up asset groups, define roles and permissions, assign remediation
tickets, and distribute reports. See Managing users and asset groups (on page 79).

Determine "how much NeXpose" you need
The scope of your NeXpose investment includes the type of license and the number of scan engines your purchase. In
considering "how much NeXpose" you need, it's important to keep in mind your security goals.
Ensuring complete coverage with the fixed-number IP address license

Your NeXpose license specifies a fixed, finite range of IP addresses. For example, you can purchase a license for 1,000
or 5,000 IP addresses.
Make sure your organization has a reliable, dynamic asset inventory system in place to ensure that your license
provides adequate coverage. It may not be unusual for the total number of your organization's assets to fluctuate on a
fairly regular basis. As staff numbers grow and recede, so does the number of workstations. Servers go on line and out
of commission. Employees who are travelling or working from home plug into the network at various times using
virtual private networks (VPNs).
This fluidity underscores the importance of having a dynamic asset database. Relying on a manually maintained
spreadsheet is risky. There will be always be assets on the network that are not on the list. And, if they're not on the
list, they're not being managed. Result: added risk.
According to a paper by the technology research and advisory company, Gartner, Inc., an asset database is as essential
to vulnerability management as the scanning technology itself. In fact, the two must work in tandem:
"The network discovery process is continuous, while the vulnerability assessment scanning cycles through the
environment during a period of weeks2."
The paper further states that an asset database is a "foundation that enables other vulnerability technologies" and with
which "remediation becomes a targeted exercise."
The best way to keep your asset database up to date is to perform discovery scans on a regular basis.
2
"A Vulnerability Management Success Story" published by Gartner, Inc.
See your network with hacker “eyes,” using scan engines

Any NeXpose deployment includes a NeXpose Security Console and one or more NeXpose Scan Engines to detect
assets on your network, collect information about them, and test these assets for vulnerabilities. Scan engines test
vulnerabilities in several ways. One method is to check software version numbers, flagging out-of-date versions.
Another method is a "safe exploit" by which NeXpose probes target systems for conditions that render them
vulnerable to attack. The logic built into vulnerability tests mirrors the steps that sophisticated attackers would take in
attempting to penetrate your network.
NOTE: NeXpose is designed to exploit vulnerabilities without causing service disruptions. NeXpose does not actually attack target systems.
One way to think of scan engines is that they provide strategic views of your network from a hacker's perspective. In
deciding how and where to deploy scan engines, consider how you would like to "see" your network.
View your network inside-out: hosted vs. distributed engines

Two types of NeXpose Scan Engine options are available—hosted and distributed. You can choose to use only one
option, or you can use both in a complementary way. It is important to understand how the options differ in order to
deploy scan engines efficiently. Note that the hosted and distributed scan engines are not built differently. They
merely have different locations relative to your network. They provide different views of your network.

Hosted scan engines allow you to see your network as an external attacker with no access permissions would see it.
They scan everything on the periphery of your network, outside the firewall. These are assets that, by necessity,
provide unconditional public access, such as Web sites and e-mail servers.
Rapid7 hosts and maintains these scan engines, which entails several benefits. You don't have to have to install or
manage them. The engines reside in continuously monitored data centers, ensuring high standards for availability and
security.
NOTE: If your organization uses outbound port filtering, you would need to modify your firewall rules to allow hosted scan engines to
connect to your network assets.
With these advantages, it might be tempting to deploy hosted scan engines exclusively. However, hosted engines
have limitations in certain use cases that warrant deploying distributed scan engines.

NOTE: As a critical security measure, NeXpose Scan Engines do not store scan data. Instead, they immediately send the data to the NeXpose
Security Console.
Unlike hosted engines, distributed scan engines allow you to inspect your network from the inside. They are ideal for
core servers and workstations. You can deploy distributed scan engines anywhere on your network to obtain multiple
views. This flexibility is especially valuable when it comes to scanning a network with multiple subnetworks, firewalls,
and other forms of segmentation.
But, how many scan engines do you need? The question to ask first is, where you should you put them?
Distribute scan engines strategically

In determining where to put scan engines, it's helpful to look at your network topology. What are the areas of
separation? And where are the connecting points? If you can answer these questions, you have a pretty good idea of
where to put scan engines.
NOTE: It is possible to operate a scan engine on the same host computer as the NeXpose Security Console. While this configuration may be
convenient for product evaluation or small-scale production scenarios, it is not appropriate for larger production environments,
especially if the engine is scanning many assets. Scanning is a RAM-intensive process, which can drain resources away from the
security console.
Following are examples of situations that could call for the placement of a scan engine.

Firewalls, IDS, IPS, and NAT devices
You may have a firewall separating two subnetworks. If you have a scan engine deployed on one side of this firewall,
you will not be able to scan the other subnetwork without opening the firewall. Doing so may violate corporate
security policies.
An application-layer firewall may have to inspect every packet before consenting to route it. The firewall has to track
state entry for every connection. A typical scan can generate thousands of connection attempts in a short period,
which can overload the firewalls state table or state tracking mechanism.
Scanning through an Intrusion Detection System (IDS) or Intrusion Prevention System (IPS) can overload the
device or generate an excessive number of alerts. Making an IDS or IPS aware that NeXpose is running a
vulnerability scan defeats the purpose of the scan because it looks like an attack. Also, an IPS can compromise scan
data quality by dropping packets, blocking ports but making them "appear" open, and performing other actions to
protect assets. It may be desirable to disable an IDS or IPS for network traffic generated by scan engines.
Having a scan engine send packets through a network address transition (NAT) device may cause the scan to slow
down, since the device may only be able to handle a limited number of packets per second.
DEFINITION: Latency is the delay interval between the time when a computer sends data over a network and another computer receives it.
Low latency means short delays.
In each of these cases, a viable solution would be to place a scan engine on either side of the intervening device to
maximize bandwidth and minimize latency.
VPNs
Scanning across virtual private networks (VPNs) can also slow things down, regardless of bandwidth. The problem is
the workload associated with connection attempts, which turns VPNs into bottlenecks. As a scan engine transmits
packets within a local VPN endpoint, this VPN has to intercept and decrypt each packet. Then, the remote VPN
endpoint has to decrypt each packet. Placing a scan engine on either side of the VPN tunnel eliminates these types of
bottlenecks, especially for VPNs with many assets.
Subnetworks
The division of a network into subnetworks is often a matter of security. Communication between subnetworks may
be severely restricted, resulting in slower scans. Scanning across subnetworks can be frustrating because they are often
separated by firewalls or have access control lists (ACLs) that limit which entities can contact internal assets. For
both security and performance reasons, assigning a scan engine to each subnetwork is a best practice
Perimeter networks (DMZs)

Perimeter networks, which typically include Web servers, e-mail servers, and proxy servers, are "out in the open,"
which makes them especially attractive to hackers. Because there are so many possible points of attack, it is a good
idea to dedicate as many as three scan engines to a perimeter network. A hosted engine can provide a view from the
outside looking in. A local engine can scan vulnerabilities related to outbound data traffic, since hacked DMZ assets
could transmit viruses across the Internet. Another local engine can provide an interior view of the DMZ.
ACLs
Access Control Lists (ACLs) can create divisions within a network by restricting the availability of certain network
assets. Within a certain address space, such as 192.168.1.1/254, NeXpose may only be able to communicate with 10
assets because the other assets are restricted ay an ACL. If modifying the ACL is not an option, it may be a good
idea to assign a scan engine to ACL-protected assets.

WANs and remote asset locations
Sometimes an asset inventory is distributed over a few hundred or thousand miles. Attempting to scan geographically
distant assets across a Wide Area Network (WAN) can tax limited bandwidth. An engine deployed near remote
assets can more easily collect scan data and transfer that data to more centrally located database. It is less taxing on
network resources to perform scans locally. Physical location can be a good principle for creating a site. See Working
with sites (on page 26). This is relevant because each site is assigned to one scan engine.
Other factors that might warrant scan engine placement include routers, portals, third-party-hosted assets,
outsourced e-mail, and virtual local-area networks.
Understanding scan engine-omics

Another way to project how many scan engines you need is by tallying the total number of assets that you intend to
scan and how quickly you need to scan them. The following calculation will give you a general idea. Keep in mind
that average numbers for simultaneous scans and total scan hours will vary depending on the types of assets you are
scanning and the scan template you are using.
NOTE: The assumption in this scenario is that you are running NeXpose on a 32-bit operating system with 4 GB of RAM.
In this example, you may wish to scan a range of 300 IP addresses within 24 hours. A scan engine can run
approximately three simultaneous scans. Each scan of a live asset can take up to five hours or more, depending on
conditions mentioned in the preceding paragraph. If you multiply 300 assets by five hours of scanning for each asset,
the result is 1500 total scan engine hours.
NeXpose can scan up to three sites simultaneously. Most NeXpose scan templates, by default, are configured for 10
scan threads, or 10 assets scanned simultaneously. This means that NeXpose can scan 30 assets simultaneously. If you
divide 1500 total engine hours by 30, which is the number of supported simultaneous scans, the result is 50 engine
hours. If you divide this number by 24, which is the number of hours in which you wish to complete all scanning, the
result rounds up to three scan engines.
You may wish to add a few more engines for redundancy and load balancing. A comfortable number of engines for
this situation would be approximately 10.
Having more engines potentially means faster scanning. However, certain constraints may affect how quickly you can
expect to complete a scan job, even with a healthy fleet of engines. Bandwidth often is the biggest issue. Faster
scanning requires more bandwidth. If you have limited bandwidth, then you will have to allow for wider scan
windows.
Fault tolerance is an argument for deploying multiple scan engines to a location, especially when scan data for critical
assets is time sensitive.
Factor in 64 bits
A scan engine running on a 64-bit operating system can use more RAM than a scan engine operating on a 32-bit
system. The vertical scalability of 64-bit scan engines significantly increases the potential number simultaneous scans
that NeXpose can run, which, in turn, may have a bearing on how many total scan engines you will need.
NOTE: The 64-bit configuration is recommended for enterprise-scale deployments. For smaller deployments, the 32-bit configuration may be
sufficient.
Keep in mind that best practices for scan engine placement still apply. See Distribute scan engines strategically (on page
20). Bandwidth is also important to consider.
Deciding how many NeXpose Scan Engines to implement and where to put them requires a great deal of careful
consideration. It's one of the most important aspects your deployment plan. If you do it properly, you will have an
excellent foundation for planning your sites, which is discussed in the following chapter, Setting up NeXpose and
getting started.

Setting up NeXpose and getting started
Once you've mapped out your scan engine deployment, you're more than halfway to planning your NeXpose
installation. The next step is to decide how you want to install the main components—the NeXpose Security Console
and NeXpose Scan Engines.
Understanding deployment options

NeXpose components are available in two versions. The hardware/software appliance is a plug-and-play device that
contains the components of a security console and a scan engine. When you purchase an appliance, Rapid7 can
configure it to run as just a scan engine or as a security console and a scan engine.
In some ways, an appliance is a simpler solution than the software-only version of the product, which requires you to
allocate your own resources to meet NeXpose system requirements. When you install NeXpose software on a given
host, your options—as with the appliance—include running the application as a just a scan engine or as a security
console and scan engine.
Installation scenarios—which one are you?

The different ways to install NeXpose address different business scenarios and production environments. You may
find one of these to be similar to yours.
Small business, internal network

The owner of a single, small retail store has a network of 50 or 60 work stations and needs to ensure that they are
PCI compliant. The assets include registers, computers for performing merchandise look-ups, and file and data
servers. They are all located in the same building. A software-only console/scan engine on a single server is sufficient
for this scenario.
Mid-size company with some remote locations

A company has a central office and two remote locations. The headquarters and one of the other locations have only
a handful of assets between them. The other remote location has 300 assets. Network bandwidth is mediocre, but
adequate. It definitely makes sense to dedicate a scan engine to the 300-asset location. The rest of the environment
can be supported by a console and engine on the same host. Due to bandwidth limitations, it is advisable to scan this
network during off-hours.
Global enterprise with multiple, large remote locations

A company headquartered in the United States has locations all over the world. Each location has a large number of
assets. Each remote location has one or more dedicated scan engines. One bank of scan engines at the U.S. office
covers local scanning and provides emergency backup for the remote engines. In this situation, it is advisable not to
use the scan engine that shares the host with the console, since the console has to manage numerous engines and a
great deal of data.
Where to put the security console

Unlike scan engines, the security console is not restricted in its performance by its location on the network. Consoles
initiate outbound connections with scan engines to initiate scans. When a console sends packets through an opening
in a firewall, the packets originate from "inside" the firewall and travel to scan engines "outside." You can install the
console wherever it is convenient for you.

NOTE: Configuring a NeXpose environment involves pairing each installed scan engine with a security console. To say that multiple consoles
can share a scan engine means that a scan engine can be paired with multiple security consoles. For information on pairing consoles
and engines, see Setting up NeXpose scan engines (on page 30).
One NeXpose Security Console is typically sufficient to support an entire enterprise, assuming that the console is not
sharing host resources with a scan engine. If you notice that the console's performance is slower than usual, and if this
change coincides with a dramatic increase in scan volume, you may want to consider adding a second console.
A deployment plan for Example, Inc.

Let's return to the environment table for Example, Inc.
Network segment Address space # of assets Location Asset functions
New York Sales 10.1.0.0/22 254 Building 1: Work stations

Floors 1-3
New York IT/Administration 10.1.10.0/23 50 Building 2: Work stations

Floor 2 Servers
New York printers 10.1.20.0/24 56 Buildings 1 & 2 Printers
New York DMZ 172.16.0.0/22 30 Co-location facility Web server

Mail server
Madrid sales 10.2.0.0/22 65 Building 3: Work stations

Floor 1
Madrid development 10.2.10.0/23 130 Building 3: Work stations

Floors 2 & 3 Servers
Madrid printers 10.2.20.0/24 35 Building 3: Printers

Floors 1-3
Madrid DMZ 172.16.10.0/24 15 Building 3: File server

dark room
A best-practices deployment plan might look like this:

The eight groups collectively contain a total of 635 assets. Example, Inc., could purchase a fixed-number license for
635 licenses, but it would be wiser to purchase a discovery for the total address space. It is always a best practice to
scan all assets in an environment according to standards such as PCI, ISO 27002, or ISO 27001. This practice
reflects the hacker approach of viewing any asset as a possible attack point.
Example, Inc., should distribute NeXpose components throughout its four physical locations:
• Building 1
• Building 2
• Building 3
• Co-Location facility

The IT or security team should evaluate each of the LAN/WAN connections between these locations for quality and
bandwidth availability. The team also should audit these pipes for devices that may prevent successful scanning, such
as firewalls, ACLs, IPS, or IDS.
Finally the team must address any logical separations, like firewalls and ACLs, which may prevent access.
The best place for the NeXpose Security Console is in New York because the bulk of the assets are there, not to
mention IT and administration groups.
Assuming acceptable service quality between the New York buildings, the only additional infrastructure would be a
NeXpose Scan Engine (NSE) inside the Co-Location facility.
Example, Inc., should install at least one scan engine in the Madrid location, since latency and bandwidth utilization
are concerns over a WAN link.
Finally, it's not a bad idea to add one more engine for the Madrid DMZ to bypass any firewall issues.
The following table reflects this plan.
Asset Location
NeXpose Security Console New York: Building 2
NeXpose Scan Engine #1 New York: Co-Location Facility
NeXpose Scan Engine #2 Madrid: Building 3
NeXpose Scan Engine #3 Madrid: dark room
Your deployment checklist

When you are ready to install, configure, and run NeXpose, it's a good idea follow a general sequence. Certain tasks
are dependent on others being completed. You will find yourself repeating some of these steps.
• Install NeXpose components.
• Log onto the Network Security Console Web interface.
• Configure scan engines, and pair them with the security console,
• Create one or more sites.
• Assign a scan engine and scan template to each site.
• Schedule scans.
• Create user accounts, and assign site-related roles and permissions to these accounts.
• Run scans.
• Configure and run reports.
• Create asset groups to view reports and asset data.
• Create user accounts, and assign asset-group-related roles and permissions to these accounts.
• Assign remediation tickets to users.
• Re-run scans to verify remediation.

Working with sites
Collecting useful security data is easier to do with thoughtful site creation. This chapter provides best practices and
instructions for configuring sites and scans.
Using sites to your advantage

The actual process of creating a site is a straightforward, wizard-based sequence of tasks. There is some thought
required, though. You have to make several important, interrelated decisions.
• Choose a grouping principle.
• Select a scan template.
• Create a scan schedule.
Choose a grouping principle

There are many ways to divide network assets into sites. The most obvious grouping principal is physical location. A
company with assets in Philadelphia, Honolulu, Osaka, and Madrid could have four sites, one for each of these cities.
Grouping assets in this manner makes sense, especially if each physical location has its own dedicated scan engine.
Remember, each site is assigned to a specific scan engine.
With that in mind, you may find it practical simply to base site creation on scan engine placement. Scan engines are
most effective when they are deployed in areas of separation and connection within your network. See Distribute scan
engines strategically (on page 20). So, for example, you could create sites based on subnetworks.
Other useful grouping principles include common asset configurations or functions. You may want have separate sites
for all of your workstations and your database servers. Or you may wish to group all your Windows 2008 Servers in
one site and all your Debian machines in another. Similar assets are likely to have similar vulnerabilities, or they are
likely to present identical logon challenges.
Be flexible with your site creation. You can include an asset in more than one site. For example, you may wish to run
a monthly scan of all your Windows Vista workstations with the Microsoft hotfix scan template to verify that these
assets have the proper Microsoft patches installed. But if your organization is a medical office, some of the assets in
your "Windows Vista" site might also be part of your "Patient support" site, which you may have to scan annually
with the HIPAA compliance template.
Another thing to keep in mind is that you combine assets into sites for scanning, but you can arrange them
differently for asset groups. You may have fairly broad criteria for creating a site. But once you run a scan, you can
parse the asset data into many different "views" using different report templates. You can then assign different asset
group members to read these reports for various purposes. See Managing users and asset groups (on page 79).
Avoid getting too granular with your site creation. The more sites you have, the more scans you will be compelled to
run, which can inflate overhead in time and bandwidth.

Grouping options for Example, Inc.
Your grouping scheme can be fairly broad or more granular.
The following table shows a serviceable high-level site grouping for Example, Inc. The scheme provides a very basic
guide for scanning and makes use of the entire network infrastructure.
Site Name Address space # of assets Component
10.1.0.0/22 NeXpose Security

Console
New York 10.1.10.0/23 360
10.1.20.0/24
New York DMZ 172.16.0.0/22 30 NeXpose Scan Engine

#1
10.2.0.0/22
Madrid 10.2.10.0/23 233 NeXpose Scan Engine
#1
10.2.20.0/24
Madrid DMZ 172.16.10.0/24 15 NeXpose Scan Engine

#1
A potential problem with this grouping is that managing scan data in large chunks is time consuming and difficult. A
better configuration groups the elements into smaller scan sites for more refined reporting and asset ownership.
In the following configuration, Example, Inc., introduces asset function as a grouping principle. The New York site
from the preceding configuration is subdivided into Sales, IT, Administration, Printers, and DMZ. Madrid is
subdivided by these criteria as well. Adding more sites reduces scan time and promotes more focused reporting.

Site name Address space # of assets Component
New York Sales 10.1.0.0/22 254 NeXpose Security

Console
New York IT 10.1.10.0/24 25 NeXpose Security

Console
New York Administration 10.1.10.1/24 25 NeXpose Security

Console
New York Printers 10.1.20.0/24 56 NeXpose Security

Console
New York DMZ 172.16.0.0/22 30 NeXpose Scan

Engine 1
Madrid Sales 10.2.0.0/22 65 NeXpose Scan

Engine 2
Madrid Development 10.2.10.0/23 130 NeXpose Scan

Engine 2
Madrid Printers 10.2.20.0/24 35 NeXpose Scan

Engine2
Madrid DMZ 172.16.10.0/24 15 NeXpose Scan

Engine 3
An optimal configuration, seen in the following table, incorporates the principal of physical separation. Scan times
will be even shorter, and reporting will be even more focused.

Site name Address Space # of assets Component

1st floor Console

2nd floor Console

3rd floor Console
New York IT 10.1.10.0/25 25 NeXpose Security

Console
New York Administration 10.1.10.128/25 25 NeXpose Security

Console
New York Printers Building 1 10.1.20.0/25 28 NeXpose Security

Console
New York Printers Building 2 10.1.20.128/25 28 NeXpose Security

Console
New York DMZ 172.16.0.0/22 30 NeXpose Scan Engine 1
Madrid Sales Office 1 10.2.1.0/24 31 NeXpose Scan Engine 2
Madrid Development Floor 2 10.2.10.0/24 65 NeXpose Scan Engine 2
Madrid Development Floor 3 10.2.11.0/24 65 NeXpose Scan Engine 2
Madrid Printers Building 3 10.2.20.0/24 35 NeXpose Scan Engine 2
Madrid DMZ 172.16.10.0/24 15 NeXpose Scan Engine 3
Choose a scan template

The NeXpose Manual provides detailed descriptions about the preset scan templates that are included in the product.
In choosing a template for each site, you may find it helpful to read these descriptions. Reading the section on
customizing scan templates is also beneficial, even if you don't intend to customize your own templates. This section
provides a granular look at the components of a scan template and how they are related to various scan events, such as
port discovery, and vulnerability checking.
As with all other NeXpose deployment options, scan templates map directly to your security goals and priorities. If
you need to become HIPAA compliant, use the HIPAA Compliance template. If you need to protect your
perimeter, use the Internet DMZ audit or Web Audit template.

Alternating templates is a good idea, as you may want to look at your assets from different perspectives. The first
time you ever scan a site, you might just do a discovery scan to find out exactly what is running on your network.
Then, you could run a vulnerability scan using the Full Audit template, which includes a broad and comprehensive
range of checks. It's like giving a complete physical to a patient who hasn't visited a doctor in a long time.
If you have assets that are about to go into production, it might be a good time to scan them with a Denial-of-Service
template. Exposing them to unsafe checks is a good way to test their stability without affecting workflow in your
business environment.
"Tuning" your scans by customizing a template is, of course, an option. However, keep in mind that the preset
templates are, themselves, best practices. The design of these templates is intended to balance three critical
performance factors: time, accuracy, and resources. If you customize a template to scan more quickly by adding
threads, for example, you may pay a price in bandwidth.
Create a scan schedule

Depending on your security policies and routines, you may schedule certain scans to run on a monthly basis—such as
patch verification checks— or on an annual basis, such as certain compliance checks. It's a good practice to run
discovery scans and vulnerability checks more often—perhaps every week or two weeks, or even several times a week,
depending on the importance or risk level of these assets.
Scheduling scans can be tricky. Generally, it's a good idea to scan during off-hours, when more bandwidth is free and
work disruption is less likely. On the other hand, your workstations may automatically power down at night, or
employees may take laptops home. In this case, you may be compelled to scan those assets during office hours. Make
sure to alert staff of an imminent scan, as it may tax network bandwidth or appear as an attack.
If you plan to run scans at night, find out if backup jobs are running, as these can eat up a lot of bandwidth.
Your primary consideration in scheduling a scan is the scan window: How long will the scan take? The calculation of
scan times in the preceding chapter can helpful here. See Understanding scan engine-omics (on page 22). As noted
there, many factors can affect scan times:
NOTE: Monitor scan time closely. If a scan is taking an extraordinarily long time, stop the scan, and contact Rapid7 Technical Support. A
"hung-up" scan can indicate problems with NeXpose or with your network.
• A scan with an Exhaustive template will take longer than one with a Full Audit template for the same
number of assets. An Exhaustive template includes more ports in the scope of a scan.
• A scan with a high number of services to be discovered will take additional time.
• Checking for patch verification or policy compliance is time-intensive because of logon challenges on the
target assets.
• A site with a high number of assets will take longer to scan.
• A site with more live assets will take longer to scan than a site with fewer live assets.
• Network latency and loading can lengthen scan times.
• Scanning Web sites presents a whole subset of variables. A big, complex directory structure or a high
number of pages can take a lot of time.
Setting up NeXpose scan engines

As the deployment checklist indicates, having a scan engine configured and paired with the console should precede
creating a site. See Your deployment checklist (on page 25). This is because each site must be associated with a scan
engine in order for scanning to be possible.

Configuring general information for a new scan engine
Start the remote scan engine. You cannot add a new scan engine if it is not running.
Click the Administration tab. Then, click the Create link to the right of NeXpose Scan Engines.
The console displays the General page of the NeXpose Scan Engine Configuration wizard. Type the information
about the new engine in the displayed fields.
For the engine name, you can use any text string that makes it easy to identify. The Engine Address and Port
fields refer the remote computer on which the scan engine has been installed.
The Engine Priority feature is not currently not supported.
NOTE: If you have already created sites, you can assign the new scan engine to sites by going to the Sites page of this wizard. If you have not
yet created sites, you can perform this step during site creation.
To save the new scan engine information, click the Save button, which appears on every page of the wizard.
To determine whether the scan engines are online, go the NeXpose Scan Engines page, which you can access
by clicking the manage link for NeXpose Scan Engines on the Administration page.
The console contacts the newly added remote scan engine at the IP address specified. Until it establishes the
connection, the console indicates an unknown state for the listed scan engine. Once the connection is
established, the state changes to Pending Authorization.
On this page, you can perform other tasks:
• You can edit the properties of any listed scan engine by clicking the Edit icon for that engine. To delete a
scan engine, click the Delete icon for that engine.
• You can manually apply an available NeXpose update to the a scan engine by clicking the Update icon for
that engine. To perform this task using the command prompt, see Using the command prompt (on page 95).
You can configure certain performance settings for all scan engines on the Scan Engines page of the NeXpose Security
Console configuration wizard. For more information, see Changing default scan engine settings (on page 90).
Enabling the console to use the scan engine

The instructions in this section apply to software-only installations. To perform this procedure on an appliance,
consult the NSE Hardware Setup Guide.
You must enable the console to work with each newly added scan engine to prevent unauthorized use of the scan
engine. You perform this step manually using the command prompt interface on the scan engine's host computer.
Find the ID number of the NeXpose Security Console that you want to pair the engine with by typing the following
command:
show consoles
This command lists all of the consoles associated with the scan engine. The host IP address of the console on which
you added the scan engine appears in the list with an ID number assigned by the scan engine, and an enabled
parameter set to "0," indicating that the console has not been enabled yet.
To enable the console, type the following command:
enable console
<ID number assigned by scan engine>
A message indicates that the console has been enabled, and the enabled parameter for the console changes to "1". At
this point, the newly added scan engine appears as "Active" on the console interface, and you can run scans with it.
See Setting up sites and scans (on page 32).

NOTE: If you ever change the name of the scan engine in the scan engine configuration wizard, for example because you have changed its
location or target assets, you will have to pair it with the console again. The engine name is critical to the pairing process.
Reassigning existing sites to the new scan engine

If you have not yet set up sites, see Setting up sites and scans (on page 32) before performing the following
task.
Go to the Sites page of the NeXpose Scan Engine Configuration wizard and click the Select Sites… button.
The console displays a box listing all the sites in your network. Click the check boxes for sites you wish to
assign to the new scan engine and click the Save button. The sites appear on the Sites page of the NeXpose
Scan Engine Configuration wizard.
To save the new scan engine information, click the Save button, which appears on every page of the wizard.
Setting up sites and scans

You must set up at least one site containing at least one asset in order to run scans in NeXpose. Doing so involves the
following steps:
• Specifying general site information (on page 32)
• Specifying assets to scan (on page 32)
• Specifying scan settings (on page 33)
• Setting up alerts (on page 42)
• Establishing scan credentials (on page 43)
Specifying general site information

To begin setting up a site, click the New Site button on the Home page
OR
Click the Assets tab. When the console displays the Assets page, click the View link next to sites. When the
console displays the Sites page, click New Site.
On the Site Configuration – General page, type a name for your site. You may wish to associate the name with
the type of scan that you will perform on the site, such as Full Audit, or Denial of Service.
Type a brief description for the site, and select a level of importance from the dropdown list. The importance
level corresponds to a risk factor that NeXpose uses to calculate a risk index for each site. The Very Low setting
reduces a risk index to 1/3 of its initial value. The Low setting reduces the risk index to 2/3 of its initial value.
High and Very High settings increase the risk index to 2x and 3x times its initial value, respectively. A Normal
setting does not change the risk index.
Specifying assets to scan

Go to the Devices page to list assets for your new site. You can manually enter addresses and host names in
the text box labeled Devices to scan. You also can import a comma- or new-line-delimited ASCII-text file that
lists IP address and host names of assets you want to scan.

To import an asset list, click the Browse button in the Included Devices area, and select the appropriate .txt
file from the local computer or shared network drive for which read access is permitted. Each address in the
file should appear on its own line. Addresses may incorporate any valid NeXpose convention, including CIDR
notation, host name, fully qualified domain name, and range of devices. See the box labeled More
Information.
If you are a global administrator, you may edit or delete addresses already listed in the site detail page.
To prevent assets within an IP address range from being scanned, manually enter addresses and host names
in the text box labeled Devices to Exclude from scanning; or import a comma- or new-line-delimited ASCII-text
file that lists addresses and host names that you don't want to scan. To do so, click Browse button in the
Excluded Devices area, and select the appropriate .txt file from the local computer or shared network drive for
which read access is permitted. Each address in the file should appear on its own line. Addresses may
incorporate any valid NeXpose convention, including CIDR notation, host name, fully qualified domain name,
and range of devices.
NOTE: If you specify a host name for exclusion, NeXpose will attempt to resolve it to an IP address prior to a scan. If it is initially unable to do
so, it will perform one or more phases of a scan on the specified asset, such as pinging or port discovery. In the process, NeXpose may
be able to determine that the asset has been excluded from the scope of the scan, and it will discontinue scanning it. However, if
NeXpose is unable to make that determination, it will continue scanning the asset.
You also can exclude specific assets from scans in all sites throughout your deployment on the global Device Exclusion
page. See Managing global settings (on page 85) in the NeXpose Administrator's Guide.
Specifying scan settings

Go to the Scan Setup page to select a scan template and/or scan engine other than the default settings. You
also can enable scans to run on a specified schedule.
A scan template is a predefined set of scan attributes that you can select quickly rather than manually define
properties, such as target assets, services, and vulnerabilities.
A global administrator can customize scan templates for your organization's specific needs. When you
modify a template, all sites that use that scan template will use the modified settings. See Modifying and
creating scan templates (on page 63) in the NeXpose Administrator's Guide for more information.
Select an existing scan template from the dropdown list. The boxes that follow list descriptions and attributes
for each default template. You also can create a custom scan template. See Modifying and creating scan
templates (on page 63) in the NeXpose Administrator's Guide for more information.

Denial of service
Description: This basic audit of all network assets uses both safe and unsafe (denial-of-service) checks. This scan does not include in-depth
patch/hotfix checking, policy compliance checking, or application-layer auditing.
Why use this template: You can run a denial of service scan in a preproduction environments to test the resistance of assets to denial-of-
service conditions.
Device/vulnerability scan: Y/Y
Maximum # scan threads: 10
ICMP (Ping hosts): Y
TCP ports used for device discovery: 80
UDP ports used for device discovery: None
Device discovery performance: 5 ms send delay, 4 retries, 1000 ms block timeout
TCP port scan method: Stealth scan (SYN)
TCP optimizer ports: None
TCP ports to scan: Well known numbers + 1-1040
TCP port scan performance: 0 ms send delay, 10 blocks, 10 ms block delay, 5 retries
UDP ports to scan: Well-known numbers
Simultaneous port scans: 5
Specific vulnerability checks enabled (which disables all other checks): None
Specific vulnerability checks disabled: Local, patch, policy check types
Discovery scan
Description: This scan locates live assets on the network and identifies their host names and operating systems. NeXpose does not perform
enumeration, policy, or vulnerability scanning with this template.
Why use this template: You can run a discovery scan to compile a complete list of all network assets. Afterward, you can target subsets of
these assets for intensive vulnerability scans, such as with the Exhaustive scan template.
Device/vulnerability scan: Y/N
TCP ports used for device discovery: 21, 22, 23, 25, 80, 88, 110, 111, 135, 139, 143, 220, 264, 389, 443, 445, 449, 524, 585, 636, 993, 995, 1433,
1521, 1723, 3389, 8080, 9100
UDP ports used for device discovery: 53,67,111,135,137,161,500,1701
TCP ports to scan: 21, 22, 23, 25, 80, 110, 139, 143,220, 264, 443, 445, 449, 524, 585, 993, 995, 1433, 1521, 1723, 8080, 9100
UDP ports to scan: 161, 500
Specific vulnerability checks disabled: None

Discovery scan (aggressive)
Description: This fast, cursory scan locates live assets on high-speed networks and identifies their host names and operating systems.
NeXpose sends packets at a very high rate, which may trigger IPS/IDS sensors, SYN flood protection, and exhaust states on stateful
firewalls. NeXpose does not perform enumeration, policy, or vulnerability scanning with this template.
Why use this template: This template is identical in scope to the discovery scan, except that it uses more threads and is, therefore, much
faster. The tradeoff is that scans run with this template may not be as thorough as with the Discovery scan template.
Device/vulnerability scan: Y/N
TCP ports used for device discovery: 21, 22, 23, 25, 80, 88, 110, 111, 135, 139, 143, 220, 264, 389, 443, 445, 449, 524, 585, 636, 993, 995, 1433,
1521, 1723, 3389, 8080, 9100
UDP ports used for device discovery: 53, 67, 111, 135, 137, 161, 500, 1701
TCP ports to scan: 21, 22, 23, 25, 80, 110, 139, 143, 220, 264, 443, 445, 449, 524, 585, 993, 995, 1433, 1521, 1723, 8080, 9100
UDP ports to scan: 161, 500
Exhaustive
Description: This thorough network scan of all systems and services uses only safe checks, including patch/hotfix inspections, policy
compliance assessments, and application-layer auditing. This scan could take several hours, or even days, to complete, depending on
the number of target assets.
Why use this template: Scans run with this template are thorough, but slow. Use this template to run intensive scans targeting a low number
of assets.
TCP port scan method: NeXpose determines optimal method
TCP optimizer ports: 21, 23, 25, 80, 110, 111, 135, 139, 443, 445, 449, 8080
TCP ports to scan: All possible (1-65535)

Full audit
Description: This full network audit of all systems uses only safe checks, including network-based vulnerabilities, patch/hotfix checking, and
application-layer auditing. NeXpose scans only default ports and disables policy checking, which makes scans faster than with the
Exhaustive scan. Also, NeXpose does not check for potential vulnerabilities with this template.
Why use this template: This is the default NeXpose scan template. Use it to run a fast, thorough vulnerability scan right "out of the box."
Specific vulnerability checks disabled: Policy check type
HIPAA compliance
Description: NeXpose uses safe checks in this audit of compliance with HIPAA section 164.312 ("Technical Safeguards"). The scan will flag any
conditions resulting in inadequate access control, inadequate auditing, loss of integrity, inadequate authentication, or inadequate
transmission security (encryption) .
Why use this template: Use this template to scan assets in a HIPAA-regulated environment, as part of a HIPAA compliance program.
TCP ports to scan: Well known numbers +
1-1040

Internet DMZ audit
Description: This penetration test covers all common Internet services, such as Web, FTP, mail (SMTP/POP/IMAP/Lotus Notes), DNS,
database, Telnet, SSH, and VPN. NeXpose does not perform in-depth patch/hotfix checking and policy compliance audits will not be
performed.
Why use this template: Use this template to scan assets in your DMZ.
ICMP (Ping hosts): N
TCP ports used for device discovery: None
TCP ports to scan: Well-known numbers
UDP ports to scan: None
Specific vulnerability checks enabled (which disables all other checks): DNS, database, FTP, Lotus Notes/Domino, Mail, SSH, TFTP, Telnet,
VPN, Web check categories
Linux RPMs
Description: This scan verifies proper installation of RPM patches on Linux systems. For optimum success, use administrative credentials.
Why use this template: Use this template to scan assets running the Linux operating system.
TCP ports used for device discovery: 22, 23
TCP ports to scan: 22, 23
Specific vulnerability checks enabled (which disables all other checks): RPM check type

Microsoft hotfix
Description: This scan verifies proper installation of hotfixes and service packs on Microsoft Windows systems. For optimum success, use
administrative credentials.
Why use this template: Use this template to verify that assets running Windows have hotfix patches installed on them.
TCP ports used for device discovery: 135, 139, 445, 1433, 2400
TCP ports to scan: 135, 139, 445, 1433, 2433
Specific vulnerability checks enabled (which disables all other checks): Microsoft hotfix check type
Payment Card Industry (PCI) audit
Description: This audit of Payment Card Industry (PCI) compliance uses only safe checks, including network-based vulnerabilities,
patch/hotfix verification, and application-layer testing. NeXpose scans all TCP ports and well-known UDP ports. NeXpose does not
perform policy checks.
Why use this template: Use this template to scan assets as part of a PCI compliance program.
TCP ports used for device discovery: 22, 23, 25, 80, 443
TCP ports to scan: All possible (1-65535)
Specific vulnerability checks disabled: Policy check types

Penetration test
Description: This in-depth scan of all systems uses only safe checks. Host-discovery and network penetration features allow NeXpose to
dynamically detect assets that might not otherwise be detected. NeXpose does not perform in-depth patch/hotfix checking, policy
compliance checking, or application-layer auditing .
Why use this template: With this template, you may discover assets that are out of your initial scan scope. Also, running a scan with this
template is helpful as a precursor to conducting formal penetration test procedures.
TCP ports used for device discovery: 21, 22, 23, 25, 80, 443, 8080
Penetration test
Description: This in-depth scan of all systems uses only safe checks. Host-discovery and network penetration features allow NeXpose to
dynamically detect assets that might not otherwise be detected. NeXpose does not perform in-depth patch/hotfix checking, policy
compliance checking, or application-layer auditing .
Why use this template: With this template, you may discover assets that are out of your initial scan scope. Also, running a scan with this
template is helpful as a precursor to conducting formal penetration test procedures.
TCP ports used for device discovery: 21, 22, 23, 25, 80, 443, 8080

Safe network audit
Description: This non-intrusive scan of all network assets uses only safe checks. NeXpose does not perform in-depth patch/hotfix checking,
policy compliance checking, or application-layer auditing.
Why use this template: This template is useful for a quick , general scan of your network.
Sarbanes-Oxley (SOX) compliance
Description: This is a safe-check

Sarbanes-Oxley (SOX) audit of all systems. It detects threats to digital data integrity, data access auditing, accountability, and
availability, as mandated in Section 302 ("Corporate Responsibility for Fiscal Reports"), Section 404 ("Management Assessment of
Internal Controls"), and Section 409 ("Real Time Issuer Disclosures") respectively.
Why use this template: Use this template to scan assets as part of a SOX compliance program.

SCADA audit
Description: This is a "polite," or less aggressive, network audit of sensitive Supervisory Control And Data Acquisition (SCADA) systems, using
only safe checks. Packet block delays have been increased; time between sent packets has been increased; protocol handshaking has
been disabled; and simultaneous network access to assets has been restricted.
Why use this template: Use this template to scan SCADA systems.
Specific vulnerability checks disabled: Policy check typeTCP port scan performance: 0 ms send delay, 10 blocks, 10 ms block delay, 5
retries

Web audit
Description: This audit of all Web servers and Web applications is suitable public-facing and internal assets, including application servers,
ASP's, and CGI scripts. NeXpose does not perform patch checking or policy compliance audits . Nor does it scan FTP servers, mail
servers, or database servers, as is the case with the DMZ Audit scan template.
Why use this template: Use this template to scan public-facing Web assets.
ICMP (Ping hosts): N
TCP ports to scan: Well-known numbers
Specific vulnerability checks enabled (which disables all other checks): Web category check
Choose a scan engine from the drop-down list.

If you wish to schedule a scan to run automatically, click the check box labeled Enable schedule. The console
displays options for a start date and time, maximum scan duration in minutes, and frequency of repetition.
If the scheduled scan runs and exceeds the maximum specified duration, it will pause for an interval that you
specify in the option labeled Repeat every.
Select an option for what you want the scan to do after the pause interval.
If you select the option to continue where the scan left off, the paused scan will continue at the next
scheduled start time.
If you select the option to restart the paused scan from the beginning, the paused scan will stop and then
start from the beginning at the next scheduled start time.
To save the site configuration, click the Save button on any page of the wizard.
The newly scheduled scan will appear in the Next Scan column of the Site Summary pane of the page for the
site that you are creating.
All scheduled scans appear on the Calendar page, which you can view by clicking the Monthly calendar link
on the Administration page.
Setting up alerts
You can set up alerts for certain scan events:
• a scan starting
• a scan stopping
• a scan failing to conclude successfully

• a scan discovering a vulnerability that matches specified criteria
Go to the Alerting page and click the New Alert button.
The console displays a New Alert dialog box. Click the Enable alert check box to ensure that NeXpose
generates this type of alert. You can click the box again at any time to disable the alert if you prefer not to
receive that alert temporarily without having to delete it.
Type a name for the alert.
Type a value in the Send at most field if you wish to limit the number of this type of alert that you receive
during the scan.
Select the check boxes for types of events that you wish to generate alerts for. For example, if you select
Paused and Resumed, NeXpose generates an alert every time it pauses or resumes a scan.
Select a severity level for vulnerabilities that you wish to generate alerts for. For information about severity
levels, see Viewing active vulnerabilities in the the NeXpose User's Guide.
Select the Confirmed, Unconfirmed, and/or Potential check boxes to receive only those alerts. You can
filter alerts for vulnerabilities based on the level of certainty that those vulnerabilities exist.
When NeXpose scans an asset, it performs a sequence of discoveries, verifying the existence of an asset, port,
service, and variety of service (for example, an Apache Web server or an IIS Web server). Then, NeXpose
attempts to test the asset for vulnerabilities known to be associated with that asset, based on the information
gathered in the discovery phase.
If NeXpose is able to verify a vulnerability, it reports a "confirmed" vulnerability. If NeXpose is unable to verify
a vulnerability known to be associated with that asset, it reports an "unconfirmed" or "potential" vulnerability.
The difference between these latter two classifications is the level of probability. Unconfirmed vulnerabilities
are more likely to exist than potential ones, based on the asset's profile.
Select a notification method from the dropdown box. NeXpose can send alerts via SMTP e-mail, SNMP
message, or Syslog message. Your selection will control which additional fields appear below this box.
If you select the e-mail method, enter the addresses of your intended recipients. If your network restricts
outbound SMTP traffic, specify a mail relay server for sending the alert e-mails.
If you select the option to send SNMP alerts, type the name of the SNMP community and the address of the
SNMP server to which NeXpose will send alerts.
If you select the option to send a Syslog message, type the address of the Syslog server to which NeXpose
will send messages.
Click the Limit alert text check box to send the alert without a description of the alert or its solution. Limited-
text alerts only include the name and severity. This is a security option for alerts sent over the Internet or as
text messages to mobile devices.
Click the Save button. The new alert appears on the Alerting page.
Establishing scan credentials

Establishing logon credentials for your scan engine enables it to perform deep checks, inspecting assets for a wider
range of vulnerabilities, such as policy violations, adware, or spyware. Additionally, credentialed scans can check for
software applications and packages such as Hotfix.
NOTE: NeXpose protects all credentials with RSA encryption and triple DES encryption before storing them in its database.
Go to the Credentials page, and click New Login. The console displays a New Login box.

Select the desired type of credentials from the dropdown list labeled Service. This selection determines the
other fields that appear in the form. However, all forms include fields for entering some kind of user name
and/or password. Additionally, all forms contain two fields, Restrict to Device and Restrict to Port.
Typing in the name or IP address of an asset in the Restrict to Device field enables you to test your
credentials on that asset to ensure that the credentials will be accepted in the site. After filling that field, click
the Test login button to make sure that the credentials work.
Upon completing the test, make sure to remove the asset name or address from the Restrict to Device field, or
NeXpose will use the credentials to scan that specified asset only!
Specifying a port in the Restrict to Port field allows you to limit your range of scanned ports in certain
situations. For example, if you wish to run a scan of Web servers, you would use the HTTP credentials. To
avoid scanning all Web services within a site, you can specify only those assets with a specific port.
Click the Save button. The new credentials appear on the Credentials page.
NOTE: If you save your credentials with the Restrict to Device field filled, NeXpose will use the credentials to scan the specified asset only. And
you cannot edit credentials after saving them; you can only delete them. Therefore, delete the information that you typed in the
Restrict to Device field after testing the credentials unless you are intending to only use the credentials on the specified device.
After you finish configuring your site, click the Save button that appears on every page of the wizard.
Using HTML forms and HTTP headers to authenticate NeXpose on Web sites
NOTE: For HTTP servers that challenge users with Basic authentication or Integrated Windows authentication (NTLM), use the method called
Web Site HTTP Authentication in the Login type dropdown list.
Scanning Web sites at a granular level of detail is especially important, since publicly accessible Internet hosts are
attractive targets for attack. With authentication, NeXpose can scan Web assets for critical vulnerabilities such as
SQL injection and cross-site scripting.
Two authentication methods are available:
• Web site form authentication: NeXpose enters credentials into an HTML authentication form, as a human
user would. Many Web authentication applications challenge would-be users with forms. With this method,
NeXpose retrieves a form from the Web application and allows you to specify credentials that the
application will accept. Then, when NeXpose is about to scan the Web site, it presents these credentials to
the application.
In some cases, NeXpose may not be able to use a form to become authenticated by a Web application. For
example, a form may use a CAPTCHA test or a similar challenge that is designed to prevent logons by
computer programs. Or, a form may use Javascript, which NeXpose does not execute for security reasons. If
these circumstances apply to your Web application, you may be able to authenticate NeXpose with the
following method.
• Web site session authentication: NeXpose sends the target Web server an authentication request that includes
an HTTP header—usually the session cookie header—from the logon page.
The authentication method you use depends on the Web server and authentication application you are using. It may
involve some trial and error to determine which method works better. It is advisable to consult the developer of the
Web site before using this feature.

Creating a logon for Web site form authentication
NOTE: Instructions for setting up a logon using HTTP headers appears in the section titled Creating a logon for Web site session authentication
with HTTP headers (on page 46).
To create an HTML form logon, go the Credentials page of the configuration wizard for the site that you are
creating or editing.
Click New Login. The console displays a New Login dialog box.
From the Login type drop-down list, select Web Site Form Authentication.
NeXpose displays two text fields for the site in which the logon form is located. Enter the required
information for each field.
The Base URL text box is for the main address from which all paths in the target site begin. The credentials
you enter for logging on to the site will apply to any page on the site, starting with the base URL. You must
include the protocol with the address. Examples: http://example.com or https://example.com
The Login page URL text box is for the actual page in which users log on to the site. NeXpose will attempt to
retrieve the form from this page. You must include the base URL when you enter this URL. Example:
http://example.com/login. In some cases, the base URL and the base of the login URL may be different.
Click Next.
NeXpose contacts the Web server to retrieve any available forms. If NeXpose fails to make contact or retrieve
any forms, it displays a failure notification that lists the reason for the failure.
If NeXpose successfully retrieves one or more forms, it displays the Form Selection and Customization box.
From the drop-down list, select the form with which NeXpose will log on to the application.
Based on your selection, NeXpose displays a table of fields for that particular form. Click the Edit icon for any
field value that you wish to edit.
NeXpose displays a dialog box for editing the field value. If the value was provided by the Web server, you
must select the option button to specify a new value. Only change the value to match what what the server
will accept from NeXpose when NeXpose logs on to the site. If you are not certain of what value to use,
contact your Web administrator.
After changing the value, click Save. NeXpose now displays the Form Selection and Customization page with
with the field value changed. Repeat the editing step for any other values that you want to change.
When the table displays the form field data as desired, click Next.
NeXpose displays the Regular Expression and Login Test page.
If you wish to use a regular expression (regex) that is different from the default value, change the value in the
Regular expression text box. The default value works in most logon cases. If you are unsure of what regular
expression to use, consult the Web administrator. For more information, see Appendix A: Using regular
expressions (on page 105) in the NeXpose Administrator's Guide.
When the regular expression appears in the text box appears as desired, click the Test login button to make
sure that NeXpose can successfully log on to the Web application. If NeXpose displays a success notification,
save the HTML form information and proceed with any other site configuration tasks.
If NeXpose displays a failure notification, return to the Form Selection and Customization page to change any
field data. If NeXpose continues to fail to log on to the Web application, consult your Web administrator.
NOTE: If the test logon fails repeatedly, one reason by be that NeXpose simply does not support the form or Web authentication application.

Creating a logon for Web site session authentication with HTTP headers
NOTE: When using HTTP headers to authenticate NeXpose, make sure that the session ID header is valid between the time you save this ID for
the site and when you start the scan. For more information about the session ID header, consult your Web administrator.
To create an HTTP header logon, go the Credentials page of the configuration wizard for the site that you
are creating or editing.
Click New Login. The console displays a New Login dialog box.
From the Login type drop-down list, select Web Site Session Authentication.
NeXpose displays a text field for the base URL, which is the main address from which all paths in the target
site begin. You must include the protocol with the address.
Examples: http://example.com or https://example.com
Click Next.
NeXpose displays a box for specifying an HTTP header. Click Add.
NeXpose displays a dialog box for entering an HTTP header. Every header is consists of two elements, which
are referred to jointly as a name/value pair.
"Name" corresponds to a specific data type, such as the Web host name, Web server type, session identifier,
or supported languages.
"Value" corresponds to the actual value string that NeXpose sends to the server for that data type. For
example, the value for a session ID (SID) might be a uniform resource identifier (URI).
If you are not sure what header to use, consult your Web administrator.
After entering a name/value pair, click Save.
NeXpose displays the name/value pair in the dialog box for specifying a header.
Click Next.
NeXpose displays the Regular Expression and Login Test page.
If you wish to use a regular expression (regex) that is different from the default value, change the value in the
Regular expression text box. The default value works in most logon cases. If you are unsure of what regular
expression to use, consult the Web administrator. For more information, see Appendix A: Using regular
expressions (on page 105) in the NeXpose Administrator's Guide.
When the regular expression appears in the text box appears as desired, click the Test login button to make
sure that NeXpose can successfully log on to the Web application. If NeXpose displays a success notification,
save the HTML form information and proceed with any other site configuration tasks.
If NeXpose displays a failure notification, return to the Form Selection and Customization page to change any
field data. If NeXpose continues to fail to log on to the Web application, consult your Web administrator.

Working with scan templates and
tuning scan performance
Tuning scans is a sensitive process. If you change one setting to attain a certain performance boost, you may find
another aspect of performance diminished. Before you tweak any scan templates, it's important for you to know two
things:
1. What your goals or priorities for tuning scans?
2. What aspects of scan performance are you willing to compromise on?
Identify your goals and how they're related to the performance "triangle." See Keep the "triangle" in mind when you tune
(on page 48). Doing so will help you look at scan template configuration in the more meaningful context of your
environment. Make sure to familiarize yourself with scan template elements before changing any settings.
Also, keep in mind that tuning scan performance requires experimentation, finesse, and familiarity with how
NeXpose works. Most importantly, you need to understand your unique network environment.
This chapter provides best practices for scan tuning and instructions for working with scan templates.
Define your goals for tuning

Before you tune NeXpose, make sure you know why you're doing it. What do you want to change about NeXpose
scan performance? What do you need NeXpose to do better? Do you need scans to run more quickly? Do you need
scans to be more accurate? Do you want to reduce resource overhead?
The following sections address these questions in detail.
You need NeXpose to finish scanning more quickly

Your goal may be to increase overall scan speed, as in the following scenarios:
• Actual scan-time windows are widening and conflicting with your scan blackout periods. Your organization
may schedule scans for non-business hours, but scans may still be in progress when employees in your
organization need to use workstations, servers, or other network resources.
• A particular type of scan, such as for a site with 300 Windows workstations, is taking an especially long time
with no end in sight. This could be a "scan hang" issue rather than simply a slow scan.
NOTE: If a scan is taking an extraordinarily long time to finish, terminate the scan and contact Rapid7 Technical Support.
• You need to able to schedule more scans within the same time window.
• Policy or compliance rules have become more stringent for your organization, requiring you to perform
"deeper" credentialed scans, but you don't have additional time to do this.

• You have to scan more assets in the same amount of time.
• You have to scan the same number of assets in less time.
• You have to scan more assets in less time.
You need to reduce consumption of network or system resources

Your goal may be to lower the hit on resources, as in the following scenarios:
• Your scans are taking up too much bandwidth and interfering with network performance for other
important business processes.
• The computers that host your scan engines are maxing out their memory if they scan a certain number of
ports.
• The security console runs out of memory if you perform too many simultaneous scans.
You need more accurate scan data

NeXpose may not giving you enough information, as in the following scenarios:
DEFINITION: A false positive is an instance in which NeXpose flags a vulnerability that doesn't exist. A false negative is an instance in which
NeXpose fails to flag a vulnerability that does exist.
• Scans are missing assets.

• Scans are missing services.
• NeXpose is reporting too many false positives or false negatives.
• Vulnerability checks are not occurring at a sufficient depth.
DEFINITION: Depth and breadth indicate how thorough or comprehensive a scan will be. Depth refers to level to which NeXpose will probe
an individual asset for system information and vulnerabilities. Breadth refers to the total number of assets within the scope of a scan.
Keep the "triangle" in mind when you tune

Any tuning adjustment that you make to scan settings will affect one or more main performance categories. These
categories reflect the general goals for tuning discussed in the preceding section:
• accuracy
• resources
• time

Since these three performance categories are interdependent, it is helpful to visualize them as a triangle.
If you lengthen one side of the triangle—that is, if you favor one performance category—you will shorten at least one
of the other two sides. It is unrealistic to expect a tuning adjustment to lengthen all three sides of the triangle.
However, you often can lengthen two of the three sides.
Increasing time availability

Providing more time to run scans typically means making scans run faster.
One use case is that of a company that holds auctions in various locations around the world. Its asset inventory is
slightly over 1,000. This company cannot run scans while auctions are in progress because time-sensitive data must
traverse the network at these times without interruptions. The fact that the company holds auctions in various time
zones complicates scan scheduling. Scan windows are extremely tight. The company's best solution is to use a lot of
bandwidth so that scan can finish as quickly as possible.
In this case it's possible to reduce scan time without sacrificing accuracy. However, a high workload may tap
resources to the point that the scanning mechanisms could become unstable. In this case, it may be necessary to
reduce the level of accuracy by, for example, turning off credentialed scanning.
There are many various ways to increase scan speeds, including the following:
• Increase the number of assets that NeXpose scans simultaneously. Be aware that this will tax RAM on
NeXpose Scan Engines and the NeXpose Security Console.
• Allocate more scan threads. Doing so will impact network bandwidth.
• Use a less exhaustive scan template. Again, this will diminish the accuracy of the scan.
NOTE: Deploying additional scan engines may lower bandwidth availability.
• Add scan engines, or position them in the network strategically. If you have one hour to scan 200 assets over
low bandwidth, placing a scan engine on the same side of the firewall as those assets can speed up the
process. When deploying a scan engine relative to target assets, choose a location that maximizes bandwidth
and minimizes latency. For more information on scan engine placement, see Distribute scan engines
strategically (on page 20).
DEFINITION: Latency is the delay interval between points in time when a computer sends data over a network and another computer
receives it. Low latency means short delays.

How long does scanning take?
It is helpful to know how the volume of target IP addresses and assets can affect scan times. The following table lists
scan times for varying numbers of target addresses and assets assuming a common host environment and identical
settings. The thread setting is higher than for most scan templates. See the section titled Maximum scan thread use (on
page 53).
• Scan engine processor: Dual 2.8 Ghz Xeon
• Scan engine RAM: 4 GB
• Bandwidth: Gigabit Ethernet
• Template: Customized, based on full audit template
• 25 scan threads (an aggressive setting, since the default setting for a full audit template is 10 threads)
Scan times
IP space Active assets Vulnerabilities Average scan time
256 IP addresses 15 252 9 minutes
256 IP addresses 100 1,202 19 minutes
1,000 IP addresses 350 1,834 32 minutes
5,000 IP addresses 1,250 5,342 2 hours, 17 minutes
1
These times will vary according to the host environment, scan template, and other conditions.
Increasing accuracy
Making scans more accurate means finding more security-related information. There are many ways to this, each
with its own "cost" according to the performance triangle:
• Increase the number of discovered assets, services, or vulnerability checks. This will take more time.
• "Deepen" scans with checks for policy compliance and hotfixes. These types of checks require credentials for
NeXpose, and can take considerably more time.
• Scan assets more frequently. For example, peripheral network assets, such as Web servers or Virtual Private
Network (VPN) concentrators, are more susceptible to attack because they are exposed to the Internet. It's
advisable to scan them often. Doing so will either require more bandwidth or more time. The time issue
especially applies to Web sites, which can have deep file structures.
• Be aware of license limits when scanning network services. When NeXpose attempts to connect to a service,
it appears to that service as another "client," or user. The service may have a defined limit for how many
simultaneous client connections it can support. If service has reached that client capacity when NeXpose
attempts a connection, the service will reject the attempt. This is often the case with telnet-based services. If
NeXpose cannot connect to a service to scan it, that service won't be included in the scan data, which means
lower scan accuracy.

Increasing resource availability
Making more resources available primarily means reducing how much bandwidth a scan consumes. It can also involve
lowering RAM use, especially on 32-bit operating systems.
Consider bandwidth availability in four major areas of your environment. Any one of or more of these can become
bottlenecks:
• The computer that hosts NeXpose can get bogged down processing responses from target assets.
• The network infrastructure on which NeXpose runs, including firewalls and routers, can get bogged down
with traffic.
• The network on which target assets run, including firewalls and routers, can get bogged down with traffic.
• The target assets can get bogged down processing requests from NeXpose.
Of particular concern is the network on which target assets run, simply because some portion of total bandwidth is
always in use for business purposes. This is especially true if you schedule scans to run during business hours, when
workstations are running and laptops are plugged into the network. But bandwidth sharing also can be an issue
during off hours, when backup processes typically are in progress.
Two related bandwidth metrics to keep an eye on are the number of data packets exchanged during the scan, and the
correlating firewall states. If NeXpose sends too many packets per second (pps), especially during the service
discovery and vulnerability check phases of a scan, it can exceed a firewall's capacity to track connection states. The
danger here is that the firewall will start dropping NeXpose request packets, or the response packets from target
assets, resulting in false negatives. So, taxing bandwidth can trigger a drop in accuracy.
There is no formula to determine how much bandwidth NeXpose should use. You have to know how much
bandwidth your enterprise uses on average, as well as the maximum amount of bandwidth it can handle. You also
have to monitor how much bandwidth NeXpose consumes and then adjust the level accordingly.
For example, if your network can handle a maximum of 10,000 pps without service disruptions, and your normal
business processes average about 3,000 pps at any given time, your goal is to have NeXpose work within a window of
7,000 pps.
The primary NeXpose scan template settings for controlling bandwidth are scan threads and maximum simultaneous
ports scanned.
The cost of conserving bandwidth typically is time.
For example, a company operates full-service truck stops in one region of the United States. Its security team scans
multiple remote locations from a central office. Bandwidth is considerably low due to the types of network
connections. Because the number of assets in each location is lower than 25, adding remote scan engines is not a very
efficient solution. A viable solution in this situation is to reduce the number of scan threads to between two and five,
which is well below the default value of 10.
There are various other ways to increase resource availability, including the following:
• Reduce the number of target assets, services, or vulnerability checks. The cost is accuracy.
• Reduce the number of assets that NeXpose scans simultaneously. The cost is time.
• Perform less exhaustive scans. Doing so primarily reduces scan times, but it also frees up threads.
The primary tuning tool: the scan template

Scan templates contain a variety of parameters for defining how NeXpose scans assets. Most tuning procedures
involve editing scan template settings.

The 15 preset scan templates in the NeXpose software package are designed for different use cases, such as PCI
compliance, Microsoft Hotfix patch verification, Supervisory Control And Data Acquisition (SCADA) equipment
audits, and Web site scans. You can find detailed information about scan templates in the section titled "Specifying
scan settings" in the NeXpose Manual or Help site. This section includes use cases and settings for each scan template.
Templates are best practices

You can use preset templates without altering them, or create custom templates based on preset templates. You also
can create new custom templates. If you opt for customization, keep in mind that preset scan templates are
themselves best practices. Not only do preset templates address specific use cases, but they also reflect the delicate
balance of factors in the performance triangle: time, resources, and accuracy.
You will notice that if you select the NeXpose option to create a new template, many basic configuration settings
have preset values. It is recommended that you do not change these values unless you have a thorough working
knowledge of what they are for. Use particular caution when changing any of these preset values.
NOTE: Until you are familiar with technical concepts related to scanning, such as port discovery and packet delays, it is recommended that
you use preset templates.
If you customize a template based on a preset template, you may not need to change every single scan setting. You
may, for example, only need to change a thread number or a range of ports and leave all other settings untouched.
For these reasons, it's a good idea to perform any customizations based on preset templates. Start by familiarizing
yourself with preset scan templates and understanding what they have in common and how they differ. The following
section is a comparison of four sample templates.
Understanding configurable phases of scanning

Understanding the phases of scanning is helpful in understanding how scan templates are structured.
Each NeXpose scan occurs in three phases:
• device discovery
• service discovery
• vulnerability checks
During the device discovery phase, a NeXpose Scan Engine sends out simple packets at high speed to target IP
addresses in order to verify the existence of network assets. You can configure timing intervals for these
communication attempts, as well as other parameters, on the Device Discovery page of the Scan Template
Configuration wizard.
Upon locating the asset, the scan engine begins the service discovery phase, attempting to connect to various ports and
to verify services for establishing valid connections. Because NeXpose scans Web applications, databases, operating
systems and network hardware, it has many opportunities for attempting access. You can configure attributes related
to this phase on the Service Discovery page of the Scan Template Configuration wizard.
During the third phase, known as the vulnerability check phase, NeXpose attempts to confirm vulnerabilities listed in
the scan template. You can select which vulnerabilities to scan for in Vulnerability Checking page of the Scan Template
Configuration wizard.
Other configuration options include limiting the types of services that are scanned and searching for specific
vulnerabilities, and adjusting network bandwidth usage.

In every phase of scanning, NeXpose identifies as many details about the asset as possible through a set of methods
called fingerprinting. By inspecting properties such as the specific bit settings in reserved areas of a buffer, the timing
of a response, or a unique acknowledgement interchange, NeXpose can identify indicators about the asset's hardware,
operating system, and, perhaps, applications running under the system. A well-protected asset can mask its existence,
its identity, and its components from a network scanner.
Analyzing four sample templates for "tunable" features

In this section, you can compare four NeXpose preset scan templates. You will note that some settings vary widely
among these templates, and some settings are identical, reflecting performance benchmarks that have proven to be
useful.
Full audit
This template provides a fairly comprehensive network inspection, but it is not as thorough or time-consuming as the
Exhaustive template. If you're running a vulnerability scan for the first time and are not sure what template to use,
this is a good one to start with. It includes only safe checks, so it is unlikely to cause disruptions in your network.
Checks include network-based vulnerabilities, patch/hotfix verification, and application-layer auditing. The two main
components that the full audit does not include are policy checks, which require credentials, and checks for potential
vulnerabilities.
Exhaustive
This template is much more detailed than the full audit, so scans will take longer to complete. Depending on the
number of target assets, an exhaustive scan can run for several days. It includes all possible vulnerability checks,
including potential checks, but excluding unsafe checks. Port discovery is also more thorough. If granular accuracy is
important, and if time is an issue, it is a best practice to only use this template on a lower number of assets.
DEFINITION: An unsafe check is a test for a vulnerability that can cause a denial of service on a target system. Be aware that the check itself
can cause a denial of service, as well. It is recommended that you only perform unsafe checks on test systems that are not in
production.
Payment Card Industry (PCI) audit

Approved Scanning Vendors (ASVs) scan networks with this template to verify compliance with Payment Card
Industry (PCI) standards. It is similar to the full audit template, except that it includes all possible TCP ports and
scans for potential vulnerabilities. It's a good idea to run scans with this template if you are preparing for a PCI audit.
Note that only certified ASVs can set up and run PCI scans and generate PCI-sanctioned compliance reports that are
recognized as valid by the PCI Security Standards Council.
Web audit
The Web audit is a good example of a template that is designed for specific types of assets: Web servers. Use it to
scan Web applications, Web application servers, Active Server Pages (ASPs), and Common Gateway Interface
(CGI) scripts. The template does not include FTP servers, mail servers, or database servers, as is the case with the
DMZ Audit scan template.
Maximum scan thread use

The maximum number of threads has a bearing on how fast a scan will run. The value corresponds to the number of
threads that NeXpose generates internally per scan per site. For example, if NeXpose scans two sites simultaneously,
and maximum thread use is set to 10, NeXpose uses a maximum of 20 threads.

Scan templates: maximum thread use
Template Maximum thread use
Full audit 10
Exhaustive 10
PCI audit 10
Web audit 10
Almost all preset NeXpose scan templates include 10 threads. The exception is the aggressive discovery template,
which includes 25. Thread use has a significant effect on system resources, especially RAM. See Fine-tuning thread
use (on page 60).
Asset discovery methods

During the asset discovery phase of a scan, NeXpose can send connection requests to target assets to verify that they
are alive and available for scanning. NeXpose uses any of three methods to contact these assets:
• ICMP echo requests (also known as "pings")
• TCP packets
• UDP packets
If a firewall is on the network, it may block the requests, either because it is configured to block network access for
any packets that meet certain criteria, or because it regards any scan as a potential hack. In either case, NeXpose
reports the asset to be "dead." This can reduce the overall accuracy of your scans. Be mindful of where you deploy
scan engines and how scan engines interact with firewalls. See Making your environment "scan-friendly" (on page 78) .
See also Distribute scan engines strategically (on page 20).
Scan templates: Asset discovery methods
Template ICMP TCP UDP
Full audit Yes Yes No
Exhaustive Yes Yes No
PCI audit Yes Yes No
Web audit No No No
Using more than one discovery method promotes more accurate results. If NeXpose cannot verify that an asset is
alive with one method, it will revert to another.
Note that the Web audit template does not include any of these discovery methods. Nor for that matter does a
similar template, the Internet DMZ audit. Peripheral networks usually have very aggressive firewall rules in place,
which blunts the effectiveness of asset discovery. So for these types of scans, it's more efficient to have NeXpose
"assume" that a target asset is live and proceed to the next phase of a scan, service discovery. This method costs time,
because NeXpose check ports on all target assets, whether or not they are live. The benefit is accuracy, since NeXpose
is checking all possible targets.

None of the four templates include the sending of UDP packets. UDP is a less reliable protocol for asset discovery
since it doesn't incorporate TCP's handshake method for guaranteeing data integrity and ordering. Unlike TCP/IP,
if a UDP port doesn't respond to a communication attempt, NeXpose usually regards it as being open. For this
reason, UDP is not used for asset discovery in most templates.
Asset discovery performance

Several settings affect how NeXpose sends packet requests:
• The send delay is the number of milliseconds (ms) that NeXpose waits between sending packets to one host
and then sending packets to another.
• The number of retries indicates how many times NeXpose attempts contact unresponsive hosts.
• The block timeout is the number of milliseconds that NeXpose waits between these retries.
In the asset discovery process, NeXpose will send one packet for one of the protocol methods defined in the scan
template. For example, if ICMP is one of the defined methods, it will send one ICMP packet. Then, NeXpose will
wait 5 ms for a response. It does not receive a response, it will a second packet, and then more until either it receives a
response from the target asset, or it exhausts the number of retries defined in the template.
If NeXpose receives a response within the defined number of retries, it will proceed with the next phase of scanning,
service discovery.
If NeXpose does not receive a response within the defined number of retries, it will pause for the interval defined in
block timeout setting. Then, if another discovery method is defined in the template, such as TCP, NeXpose will
revert to that method, repeating the delay/retry procedure.
If NeXpose does not receive a response after exhausting all discovery methods defined in the template, it reports the
asset as being "dead."
Scan templates: asset discovery performance
Template Send delay Retries Block timeout
Full audit 5 ms 4 1000 ms
Exhaustive 5 ms 4 1000 ms
PCI audit 5 ms 4 1000 ms
Web audit 5 ms 4 1000 ms
These settings are identical for the four sample templates. They reflect careful balancing of performance factors.
REMEMBER: Scan templates are best practices.
The SCADA audit, which targets more delicate systems, is much less aggressive, with a longer send delay, a longer
block timeout, and fewer retries. The two discovery scan templates, on the other hand, are more aggressive in order to
speed up the process of discovery. Be aware that more aggressive discovery settings work well on local networks, but
not over the Internet.
Ports that NeXpose uses for asset discovery

If NeXpose uses TCP or UDP methods for asset discovery, it sends request packets to specific ports. If NeXpose
contacts a port and receives a response that the port is open, it reports the host to be "live" and proceeds to scan it.

Scan templates: ports used for asset discovery
Template TCP ports used for service discovery UDP ports used for service discovery
Full audit 80 None
Exhaustive 80 None
PCI audit 22, 23, 25, 80, 443 None
Web audit None None
The PCI audit template includes extra TCP ports for discovery. With PCI scans, it's critical not to miss any live
assets.
IP Fingerprinting
NeXpose identifies as many details about discovered assets as possible through a set of methods called IP
fingerprinting. By scanning an asset's IP stack, NeXpose can identify indicators about the asset's hardware, operating
system, and, perhaps, applications running on the system. Settings for IP fingerprinting affect the accuracy side of the
performance triangle.
The retries setting defines how many times NeXpose will repeat the attempt to fingerprint the IP stack. The default
retry value is 0. IP fingerprinting takes up to a minute per asset. If NeXpose can't fingerprint the IP stack the first
time, it may not be worth additional time make a second attempt. However, you can set NeXpose to retry IP
fingerprinting any number of times.
If you decide to disable IP fingerprinting, know that NeXpose uses other fingerprinting methods, such as analyzing
service data from port scans. For example, by discovering Internet Information Services (IIS) on a target asset,
NeXpose can determine that the asset is a Windows Web server.
The certainty value, which ranges between 0.0 and 1.0 reflects the degree of certainty with which NeXpose
fingerprints an asset. If a particular fingerprint is below the minimum certainty value, NeXpose discards the IP
fingerprinting information for that asset.
Scan templates: IP fingerprinting
Template IP fingerprinting Retries? Minimum

enabled? certainty?
Full audit Yes 0 0.16
Exhaustive Yes 0 0.16
PCI audit Yes 0 0.16
Web audit Yes 0 0.16
As with the performance settings related to asset discovery, these settings were carefully defined with best practices in
mind, which is why they are identical.
Ports that NeXpose scans to discover services

Once NeXpose verifies that a host is "live," or running, it begins to scan ports to collect information about services
running computer. The target range for service discovery can include TCP and UDP ports.

Various types of port scans methods are available in NeXpose as custom options. Most preset scan template
incorporate the Stealth (SYN) method, in which the port scanner process sends TCP packets with the SYN
(synchronize) flag. This is the most reliable method. It's also fast. In fact, a SYN port scan is approximately 20 times
faster than a scan with the full-connect method, which is one of the other options for TCP port scan method.
The exhaustive template and penetration tests are exceptions in that they allow NeXpose to determine the optimal
scan method. This option makes it possible for NeXpose to scan through firewalls in some cases. However, it is
somewhat less reliable.
The "TCP optimizer ports" setting is only relevant when a template indicates that NeXpose should determine the
optimal method for scanning ports. One of the configurable settings in every scan template is the port scanning
method. If the template calls for NeXpose to determine the method, Nexpose will use the ports listed as optimizer
ports to help it make that determination.
You should select optimizer ports from a list of ports that are known to be either open or closed. Do not select ports
that are known to be protected by a firewall.
Scan templates: ports scanned
Template TCP port scan method TCP ports scanned TCP optimizer ports UDP ports scanned
scanned
Full audit Stealth scan (SYN) Well known numbers + 1- None Well-known numbers
1040
Exhaustive NeXpose determines optimal All possible (1-65535) 21, 23, 25, 80, 110, 111, Well-known numbers
method 135, 139, 443, 445, 449,
8080
PCI audit Stealth scan (SYN) All possible (1-65535) None Well-known numbers
Web audit Stealth scan (SYN) Well-known numbers None None
Although most templates include UDP ports in the scope of a scan, they limit UDP ports to well-known numbers.
Services that run on UDP ports include DNS, TFTP, and DHCP. If you want to be absolutely thorough in your
scanning, you can include more UDP ports, but doing so will increase scan time.
Service discovery performance

Many of the settings in the TCP port scanning performance table are identical because they reflect common best
practices.

Scan templates: TCP port scanning performance
Template TCP port scan send TCP port scan TCP port scan TCP port TCP connect
delay block size block delay scan retries scan timeout
Full audit 0 ms 10 10 5 3,000 ms
Exhaustive 0 ms 10 10 5 3,000 ms
PCI audit 0 ms 10 10 5 3,000 ms
Web audit 0 ms 10 10 5 3,000 ms
The "raw sockets" feature in the UDP scanning performance table allows NeXpose to use slightly fewer system
resources when scanning UDP ports. Raw sockets in a network's transport layer pass on packets without performing
certain processing steps.
Scan templates: UDP port scanning performance
Template UDP port scan UDP port scan retries Use raw sockets for
send delay UDP port scans?
Full audit 0 ms 5 No
Exhaustive 0 ms 5 No
PCI audit 0 ms 5 No
Web audit 0 ms 5 No
The phrase "port scan" refers to an assigned set of ports that NeXpose scans on each target asset. You select these
ports in the scan template. See Ports that NeXpose scans to discover services (on page 56). The value for "simultaneous
port scans" in the following table corresponds to the number of port scans that NeXpose performs concurrently per
site. In other words, if NeXpose scans two sites at the same time, and the simultaneous port scans setting is 5,
NeXpose scans 10 ports simultaneously.
Simultaneous port scans can eat up bandwidth. You can get results with the value set as high as 10 (100 total
simultaneous port scans) on a local network, assuming that other settings such as send delay and retries aren't pushed
to more aggressive levels. Over a slow Internet connection, a lower value is advisable. Also, keep in mind the capacity
of the system that is hosting NeXpose. If you are running the 32-bit version of NeXpose on a single, 1 Ghz CPU, be
cautious about increasing these settings, as they can tax system RAM.
Scan templates: simultaneous port scans
Template Simultaneous port scans
Full audit 5
Exhaustive 5
PCI audit 5
Web audit 5

Vulnerability checks
A scan template may specify certain vulnerability checks to be enabled, which means that NeXpose will scan only for
those those vulnerability check types or categories with that template. If you do not specifically enable any
vulnerability checks, then you are essentially enabling all of them, except for those that you specifically disable.
A scan template may specify certain checks as being disabled, which means that NeXpose will scan for all
vulnerabilties except for those vulnerability check types or categories with that template. In other words, if no checks
are disabled, NeXpose will scan for all vulnerabilities.
Scan templates: vulnerability checks
Template Specific vulnerability checks Specific vulnerability checks

enabled disabled
Full audit None Policy check type
Exhaustive None None
PCI audit None Policy check type
Web audit Web category check None
While the exhaustive template includes all possible vulnerability checks, the full audit and PCI audit templates
exclude policy checks, which are more time consuming. The Web audit template appropriately only scans for Web-
related vulnerabilities.
Other template settings

Preset and custom scan templates include a number of other settings.
• Whois lookups
• Trusted MAC address Web spidering and Web server checks
• Spam relaying and mail server checks
• Database server checks
• CVS server checks
• DHCP server checks
• Telnet server checks
• Policy compliance testing for Oracle, Lotus Domino, Windows Group Policy, CIFS/SMB accounts,
AS/400, and Unix
Some of these settings are especially relevant to performance. See the section titled Fine-tuning: What can you turn up
or down? (on page 60).
Do you need to alter templates or just alter-nate them?

When you become familiar with the NeXpose preset scan templates, you may find that they meet different
performance needs at different times.

REMINDER: Use your variety of report templates to parse your scan results in many different, useful ways. A NeXpose scan is a time and
resource investment, especially a "deeper" scan, such one that is run with the exhaustive template. Reports help you to reap the
biggest possible returns from that investment.
You could, for example, schedule a Web audit to run on a weekly basis, or even more frequently, to monitor your
Internet-facing assets. This is a faster scan and less of a drain on resources. You could also schedule a Microsoft
hotfix scan on a monthly basis for patch verification. This scan requires credentials, so it takes longer. But the
tradeoff is that it doesn't have to occur as frequently. Finally, you could schedule an exhaustive scan on a quarterly
basis do get a detailed, all-encompassing view of your environment. It will take time and bandwidth but, again, it's a
less frequent scan that you can plan for in advance.
NOTE: If you change templates regularly, you will sacrifice the conveniences of scheduling scans to run at automatic intervals with the same
template.
Another way to maximize time and resources without compromising on accuracy is to alternate target assets. For
example, instead of scanning all your workstations on a nightly basis, scan a third of them and then scan the other
two thirds over the next 48 hours. Or, you could alternate target ports in a similar fashion.
Quick tuning: What can you turn off?

Sometimes, tuning scan performance is a simple matter of turning off one or two settings in a template. The fewer
things you give NeXpose to check for, the less time or bandwidth you'll need to complete a scan. However, your scan
will be less comprehensive, and so, less accurate.
If the scope of your scan does not include Web assets, turn off Web spidering, and disable Web-related vulnerability
checks. If you don't have to verify hotfix patches, disable any hotfix checks. Turn off credentialed checks if you are
not interested in running them. If you do run credentialed checks, make sure you are only running necessary ones.
NOTE: Credentialed checks are critical for accuracy, as they make it possible for NeXpose to perform "deep" system scans. Be absolutely
certain that you don't need credentialed checks before you turn them off.
An important note here is that you need to know exactly what's running on your network in order to know what to
turn off. This is where discovery scans become so valuable. They provide you with a reliable, dynamic asset inventory.
For example, if you learn, from a discovery scan, that you have no servers running Lotus Notes/Domino, you can
exclude those policy checks from the scan.
Fine-tuning: What can you turn up or down?

Configuring templates to fine-tune scan performance will likely involve trial and error, including unexpected—and
undesirable—results. You can prevent some of these by knowing your network topology, your asset inventory, and
your organization's schedule and business practices. And always keep the triangle in mind. For example, don't
increase thread allocation dramatically if you know that backup operations are in progress. Your bandwidth may not
be able to take the usage spike.
Read the following topics for suggestions on how you can change template settings to boost performance. As
mentioned earlier in this chapter, familiarize yourself with preset NeXpose scan templates and how they work before
changing any settings or customizing templates from scratch.
Fine-tuning thread use

You can increase the maximum number of scan threads to speed up scans, but make sure you have sufficient network
bandwidth to absorb the spike, especially if you have to run scans during periods of high network traffic.
Bumping up scan threads can tax the RAM and CPU of a NeXpose host system. If you plan to scan with
significantly more threads than 10, monitor how the change affects the performance of the host.

Every thread that you add will multiply the number of simultaneous port scans, so check your setting for
simultaneous port scans first. See Service discovery performance (on page 57). As a rule of thumb, it is advisable not to
run more than 100 simultaneous port scans on a local-area network (LAN) to avoid making the NeXpose host
system unstable.
If it is critical to use a higher number of threads, you may want to consider running the 64-bit version of NeXpose.
Fine-tuning asset discovery

Make good use of asset discovery, as it can be a give you an efficient accuracy boost. Also, disabling asset discovery
can actually bump up scan times. NeXpose only scans an asset if it verifies that the asset is live. Otherwise, it moves
on.
For example, if NeXpose can first verify that 50 hosts are live on a sparse class C network, it can eliminate
unnecessary port scans.
It is a good idea to enable ICMP and to configure intervening firewalls to permit the exchange of ICMP echo
requests and reply packets between NeXpose and the target network.
Make sure that TCP is also enabled for asset discovery, especially if you have strict firewall rules in your internal
networks. Enabling UDP may be excessive, given the dependability issues of UDP ports. To make the judgment call
with UDP ports, weigh the value of thoroughness (accuracy) against that of time.
Changing packet-related settings can also affect the triangle. Shortening send-delay intervals theoretically increases
scan speeds, but it also can lead to network congestion, depending on bandwidth. Lengthening send-delay intervals
increases accuracy. Also, longer delays may be necessary to avoid blacklisting by firewalls or IDS devices.
Fine-tuning service discovery

Service discovery is the most resource-sensitive phase of scanning. NeXpose sends out hundreds of thousands of
packets to scan ports on a mere handful of assets.
Also, the more ports you scan, the longer the scan will take. And scanning the maximum number of ports is not
necessarily more accurate. It's a best practice select target ports based on discovery data. If you simply are not sure of
which ports to scan, use well known numbers. Be aware, though, that hackers may avoid these ports on purpose or
probe additional ports for service attack opportunities.
If you want to be a little more thorough, use the target list of TCP ports from more aggressive templates, such as the
exhaustive or penetration test template.
NOTE: NeXpose relies on network devices to return "ICMP port unreachable" packets for closed UDP ports.
Be especially judicious in your selection of UDP ports. Aside from the reliability issues discussed earlier in this
chapter, scanning UDP ports can take a lot of time. By default, NeXpose will only send two UDP packets per second
to avoid triggering the ICMP rate-limiting mechanisms that are built into TCP/IP stacks for most network devices.
Sending more packets could result in packet loss. A full UDP port scan can take up to nine hours, depending on
bandwidth and the number of target assets.
Lowering the number of retries for sending TCP packets is a good accuracy adjustment in a network with high-
traffic or strict firewall rules. In an environment like this, it's easier to lose packets. Consider setting the retry value at
3. Note that the scan will take longer.
As mentioned in the Asset Discovery topic, increasing the delay interval for sending TCP packets will prevent
NeXpose from overloading routers, triggering firewalls, or becoming blacklisted by Intrusion Detection Systems
(IDS). For information about IDS devices and how they affect scanning, see Distribute scan engines strategically (on
page 20). Increasing the delay interval for sending packets is another measure that increases accuracy at the expense of
time.

Fine-tuning vulnerability checks
The fewer vulnerabilities that NeXpose has to test for, the faster it will complete a scan. That said, it is difficult to
gauge how long exploit test actually take. Certain vulnerability checks may require more time than others. Following
are a few examples:
• The Microsoft IIS directory traversal check tests 500 URL combinations. This can take several minutes
against a busy Web server.
• Unsafe, denial-of-service checks take a particularly long time, since they involve large amounts of data or
multiple requests to target systems.
• Cross-site scripting (CSS/XSS) tests may take a long time on Web applications with many forms.
Be careful not to sacrifice accuracy by disabling too many checks—or essential checks. Choose vulnerability checks in
a focused way whenever possible. If you are only scanning Web assets, enable Web-related vulnerability checks. If
you are performing a patch verification scan, enable hotfix checks.
NeXpose is designed to minimize scan times by grouping related checks in one scan pass. This limits the number of
open connections and time interval that connections remain open. For checks relying solely on software version
numbers, NeXpose requires no further communication with the target system once it extracts the version
information.
Fine-tuning Web spidering

The NeXpose spider crawls Web servers to determine the complete layout of Web sites. It is a thorough process,
which makes it valuable for protecting Web sites. Most Web application vulnerability tests are dependent on Web
spidering.
NeXpose uses spider data evaluate custom Web applications for common problems such as SQL injection, cross-site
scripting (CSS/XSS), backup script files, readable CGI scripts, insecure use of passwords, and many other issues
resulting from custom software defects or incorrect configurations.
By default, the Web spider crawls a site using three threads and a per-request delay of 20 ms. The amount of traffic
that this generates depends on the amount of discovered, linked site content. If you're running NeXpose on a
multiple-processor system, increase the number of spider threads to three per processor.
On an under-utilized network, you can safely increase the scan speed by lowering the delay to 0. Don't change the
default delay setting on high-traffic networks.
A complete Web spider scan will take slightly less than 90 seconds against a responsive server hosting 500 pages,
assuming the target asset can serve one page on average per 150 ms with a default delay of 20ms per request. With no
delay the spidering would take 75 seconds. A scan against the same server hosting 10,000 pages would take
approximately 28 minutes, or 25 minutes with no delay.
When you configure a scan template for Web spidering, enter the maximum number of directories, or depth, as well
as the maximum number of pages to crawl per Web site. These values can limit the amount of time that Web
spidering takes. By default, the spider ignores cross-site links and stays only on the end point it is scanning.
If your asset inventory doesn't include Web sites, be sure to turn this feature off. It can be very time consuming.
Fine-tuning Web site scanning

Adaptive HTTP fingerprinting can be useful method for gathering security-related information about a Web server.
NeXpose identifies the type of server targeted by how the server behaves if its header information is missing or
inaccurate. Note that this process can be slow, and has been known to crash poorly developed HTTP servers. You
should disable this option if Web servers in your environment return reliable server banners.

Modifying and creating scan templates
To begin modifying a default template, go to the Administration page, and then click the manage link for
Scan Templates. The console displays the Scan Templates pages. You cannot directly edit a default NeXpose
template. Instead, you can make a copy of the template and edit that copy. When you click the Copy icon for
any default template listed on the page, the console displays the Scan Template Configuration wizard.
To begin creating a custom scan template from scratch, go to the Administration page, and then click the
create link for Scan Templates. The console displays the Scan Template Configuration wizard. All attribute
fields are blank.
NOTE: The PCI-related scanning and reporting templates are packaged with NeXpose, but they require purchase of a license in order to be
visible and available for use.
Configuring general scan attributes

On the Scan Template Configuration—General page, click either the radio button for Device and vulnerability
discovery or Device discovery only.
You may wish to reduce the number of threads during port scans, which can tax network resources heavily.
To do so, set a lower value for the Simultaneous port scans parameter on the Service Discovery page of the
wizard. This setting will override the maximum thread setting whenever NeXpose is scanning ports. See
Configuring service discovery (on page 65).
Type a name and description for the new template.
Type the maximum number of scan threads. This setting refers to the maximum number of IP addresses that
NeXpose will scan in parallel.
If you select device and vulnerability discovery, the full range of scan template settings will be accessible.
If you select device discovery only, NeXpose will run the scan only to identify asset host names or addresses, their
operating systems, and services. This selection renders it unnecessary to configure any vulnerability discovery
attributes. Therefore, if you click the Device discovery only radio button, all additional configuration pages disappear
from the wizard, except for Device Discovery and Service Discovery.
To save the new scan template, click the Save button, which appears on every page of the wizard.
Configuring device discovery

Go to the Scan Template Configuration—Device Discovery page.
Click a check box for one or more of the displayed protocols to locate live hosts. If you select TCP and/or UDP,
type one or more ports for each selection.
By default the NeXpose Scan Engine uses ICMP protocol, sending pings to seek out an asset during device
discovery. A firewall may discard the pings, either because it is configured to block network access for any
packets that meet certain criteria, or because it regards any scan as a potential hack. In either case, NeXpose
infers that the device is not present, and reports it to be "DEAD".
You can select TCP and/or UDP as additional, or alternate, options for locating lives hosts. With these
protocols, NeXpose attempts to verify the presence of assets online by opening port sessions. Firewalls are
often configured to allow traffic on port 80, since it is the default HTTP port, which supports Web services. If
nothing is registered on port 80, the target asset will send a "port closed" response to the scan engine. Doing
so at least establishes that the asset is, indeed, online and that further port scans can occur. In this case,
NeXpose reports the asset to be "ALIVE."

If you select TCP or UDP for device discovery, make sure to designate ports in addition to 80, depending on
the services and operating systems running on the target assets. You can view TCP and UDP port settings on
NeXpose default scan templates, such as Discovery scan and Discovery scan (aggressive) to get an idea of
commonly used port numbers.
TCP is more reliable than UDP for obtaining responses from target assets. It is also used by more services
than UDP. You may wish to use UDP as a supplemental protocol, as target devices are also more likely to
block the more common TCP and ICMP packets.
NOTE: Selecting both TCP and UDP for device discovery causes NeXpose to send out more packets than with one protocol, which uses up
more network bandwidth.
If you want the scan to include network discovery, enable the check box for that option. Network discovery is
the process by which NeXpose queries DNS and WINS servers to find other network assets that may be
scanned.
DNS servers resolve network names to reachable IP addresses. Learn more about DNS at:
http://www.dns.net/dnsrd/docs/whatis.html (http://www.dns.net/dnsrd/docs/whatis.html)
Microsoft developed Windows Internet Name Service (WINS) for name resolution in the LAN Manager
environment of NT 3.5. NeXpose can interrogate this broadcast protocol to locate the names of Windows
workstations and servers. WINS usually is not required. It was developed originally as a system database
application to support conversion of NETBIOS names to IP addresses.
If you enable network discovery, NeXpose will discover and interrogate DNS and WINS servers for the IP
addresses of all supported assets. It will include those assets in the list of scanned systems.
If you want the scan to include Whois lookups, click the check box for that option.
Whois is an Internet service that obtains information about IP addresses, such as the name of the entity that
owns it. You can improve scan engine performance by not requiring NeXpose to interrogate a Whois server
for every discovered asset if a whois server is unavailable in the network.
NOTE: Whois does not work with internal RFC1918 addresses.
If you want NeXpose to report unauthorized MAC addresses as vulnerabilities in the network type the name
of a file listing trusted MAC addresses in the appropriate field.
The Media Access Control (MAC) address is a hardware address that uniquely identifies each node in a
network. In IEEE 802 networks, the Data Link Control (DLC) layer of the OSI Reference Model is divided into
two sub layers: the Logical Link Control (LLC) layer and the Media Access Control (MAC) layer.
The MAC layer interfaces directly with the network media. Consequently, each different type of network
media requires a different MAC layer. On networks that do not conform to the IEEE 802 standards but do
conform to the OSI Reference Model, the node address is called the Data Link Control (DLC) address.
In secure environments it may be necessary to ensure that only certain machines can connect to the network.
NeXpose must have a list of authorized MAC address against which to check the set of assets located during a
scan. Also, certain conditions must be present for the successful detection of unauthorized MAC addresses:
The NSE performing the scan must reside on the same segment as the systems being scanned.
SNMP must be enabled on the router or switch managing the segment.
You must take the following steps to implement the trusted MAC address check.
Using notepad or similar text editor, create a file listing trusted MAC addresses. NeXpose will not report these
addresses as violators of the trusted MAC address vulnerability. You can give the file any valid name.
Save the file in the NeXpose directory on the host computer for the console.
The default path in a Windows installation is:

C:Program Files\acme\nexpose\plugins\java\1\NetWorkScanners\1\
<filename>
The default location under Linux is
/opt/rapid7/nexpose/plugins/java/1/NetworkScanners/1/<filename>
On the Home page of the console interface, click the Edit icon of the site for which you are creating the new
scan template.
The console displays the Site Configuration wizard for that site. Go to the Credentials page and click New
Login. The console displays a New Login box. Add appropriate logon information for the SNMP service for the
router or switch that is controlling the appropriate network segment. This will allow NeXpose to retrieve the
MAC addresses from the router using ARP requests. Click the Save button.
The new logon information appears on the Credentials page. Click the Save tab.
With the trusted MAC file in place and the scanner value set, NeXpose will perform trusted MAC vulnerability
testing. To do this NeXpose first makes a direct ARP request to the target asset to pick up its MAC address.
NeXpose also retrieves the ARP table from the router or switch controlling the segment. Then, NeXpose uses
SNMP to retrieve the MAC address from the asset and interrogates the asset using its NetBIOS name to retrieve its
MAC address.
Configuring service discovery

Go to the Scan Template Configuration—Service Discovery page.
Select a TCP port scan method from the dropdown list.
You can achieve the most "stealthy" scan by running a vulnerability test with port scanning disabled.
However, if you do so, NeXpose will be unable to discover services, which will hamper fingerprinting and
vulnerability discovery.
If you selected Determine optimal method for TCP Port Scan method, you can change values for TCP
optimizer ports. To do so, type the values into the appropriate text box.
Select which TCP ports you wish to scan from the dropdown list. If you select the Custom setting, type the
desired range in the Additional TCP Ports to Scan type text box.
Port addresses in TCP (RFC 793) are the endpoints of logical connections through which networked
computers carry on "conversations."
By default, NeXpose scans Well Known Ports, as assigned by Internet Assigned Numbers Authority (IANA). On
most systems, Well Known Ports can only be used by system (or root) processes or by programs executed by
privileged users. Well Known Ports are also known as service contact ports. These ports make services on a
computer available to unknown entities.
To the extent possible, these same port assignments are used with the UDP [RFC768].
For a list of port ranges managed by IANA, go to their Web site: http://www.iana.org/assignments/port-
numbers (http://www.iana.org/assignments/port-numbers)
The range for Well Known Ports, as those assigned by the IANA, is 0-1023.

NeXpose may extend the range of ports that it examines dynamically beyond Well Known Port range. Each
NeXpose vulnerability test may add a set of ports to be scanned. Various backdoors, Trojan horse viruses, and
other worms create ports after they have installed themselves on computers. Rogue programs and hackers
use these ports to access the compromised computers. These ports are not predefined, and they may change
over time. NeXpose output reports will show which ports were scanned during vulnerability testing,
including maliciously created ports.
Scanning all possible ports takes a lot of time. If the scan occurs through a firewall, and the firewall has been
setup to drop packets sent to non-authorized devices, than a full-port scan may span several hours to several
days. If you configure NeXpose to scan all ports, it may be necessary to change additional parameters.
In the following explanation of how ports are scanned, the numbers indicated are default settings and can be
changed. NeXpose sends a block of 10 packets to a target port, waits 10 ms, sends another 10 packets, and
continues this process throughout each port in the range. At the end of the scan, NeXpose sends another
round of packets and waits 10 ms for each block of packets that have not received a response. NeXpose
repeats these attempts for each port 5 times.
When the target asset is on a local system segment, that is, not behind a firewall, the scan occurs more
rapidly because the asset will respond that ports are closed. The difficulty occurs when the device is behind a
firewall, which consumes packets so that they do not return to the scan engine. In this case NeXpose will wait
the maximum time between port scans. TCP port scanning can exceed 5 hours, especially if it includes full-
port scans of 65K ports.
Try to scan the asset on the local segment inside the firewall. Try not to perform full TCP port scans outside a
device that will drop the packets like a firewall unless necessary.
To change TCP Port Scan Performance default settings, type new numbers over the default values. You may be able
speed up the scanning process by adjusting these settings:
• Reduce the retry count from the default of 4.
• Reduce the block to 200 or 300 ms.
• Reduce the number of TCP retries to 2 or 3.
NOTE: Reducing these settings may cause scan results to become inaccurate.
To change the TCP scan timeout settings, type a new number in the text box.
Select which UDP ports you wish to scan from the dropdown list. If you select the Custom setting, type the
desired range in the Additional UDP Ports to Scan type text box.
To reduce scanning time, do not run full UDP port scans unless it is necessary. UDP port scanning takes
longer, in general, than TCP port scanning because UDP is a "connectionless" protocol. In a UDP scan,
NeXpose interprets non-response from the asset as an indication that a port is open, not closed, which slows
the process. When configured to perform UDP scanning, NeXpose matches the packet exchange pace of the
target asset. Sun Solaris only responds to 2 UDP packet failures per second as a rate limiting feature (!) so this
scanning in this environment can be very slow in some cases.
To change UDP Port Scan Performance default settings, type new numbers over the default values.
The default number of UDP retries in NeXpose is 5, which is high for a scan through a firewall. If UDP scanning
is taking longer than it should, try reducing the retry value to 2 or 3.
NOTE: You can increase the accuracy of port scans by slowing them down with 10- to 25-millisecond delays.
If you wish to use raw sockets for UDP, click the appropriate check box.
To change the number of simultaneous port scans, type a new number over the default value.

NeXpose runs as a multithreading application. Within each thread, a variable number of scans may occur
simultaneously. More threads mean higher scanning speed. You can configure the number of threads on the
General page of the Scan Template Configuration wizard. See Configuring general scan attributes (on page 63).
You also can override this setting with a lower number of threads during port scans, which can tax network
resources heavily and increase network congestion. As congestion increases, more packets are likely to be
dropped. In turn, state-aware firewalls and routers will regard NeXpose port scans as malicious, increasing
the likelihood of incorrect scan results.
Type a file name for default service names in the text box. NeXpose consults this file for default service names
if it cannot discover them on targeted assets due to problems with the TCP handshake.
NOTE: Consult Rapid7 Technical Support to change the default service file setting. Rapid7 provides the default service file.
By knowing your network bandwidth and traffic patterns, you can optimize scanning performance. The default
attributes in the wizard have worked best in the networks tested by Rapid7. It is recommended that you do not
change them unless you have a specific reason.
Configuring vulnerability check settings

When NeXpose fingerprints an asset during the discovery phases of a scan, it automatically determines which
vulnerability checks to perform, based on the fingerprint. On the Vulnerability Checks page, you can manually
configure NeXpose to include more checks than those indicated by the fingerprint. You also can remove
slated checks.
Go to the Vulnerability Checks page. Note the order of precedence for modifying vulnerability check settings,
which is described at the top of the page.
If you wish to have NeXpose perform unsafe checks, click the appropriate check box.
A safe vulnerability check will not alter data, crash a system, or cause a system outage during its validation
routines.
Unsafe checks include buffer overflow tests against applications like IIS, Apache, services like FTP and SSH.
Others include protocol errors in some database clients that trigger system failures. Unsafe scans may crash a
system or leave a system in an indeterminate state, even though it appears to be operating normally.
NeXpose will most likely not do any permanent damage to the target system. However, if processes running
in the system might cause data corruption in the event of a system failure, unintended side effects may
occur.
The benefit of unsafe checks is that they can verify vulnerabilities that threaten denial of service attacks,
which render a system unavailable by crashing it, terminating a service, or consuming services to such an
extent that the system using them cannot do any work.
You should run scheduled unsafe checks against target assets outside of business hours and then restart
those assets after scanning. It is also a good idea to run unsafe checks in a pre-production environment to
test the resistance of assets to denial-of-service conditions.
If you wish to perform checks for potential vulnerabilities, click the appropriate check box.
You can manually add and subtract vulnerability checks in various ways. You can configure NeXpose to check
categories of vulnerabilities. In this case categories refer to types of services, such as Apache or DNS. You can
configure NeXpose to perform certain types of checks, such as a policy or version check. You can configure
NeXpose to perform specific vulnerability checks.

NOTE: If you enable any specific vulnerability categories, you are implicitly disabling all other categories. Therefore, by not enabling specific
categories, you are enabling all categories.
Click the Enable vulnerability categories... button.

The console displays a box listing vulnerability categories. Click the check boxes for those categories you
wish to scan for, and click the Save button. The console lists the selected categories on the Vulnerability
Checks page.
To prevent NeXpose from scanning for vulnerability categories listed on the Vulnerability Checks page, click
the Disable vulnerability categories...button. Click the check boxes for those categories you wish to
exclude from the scan, and click the Save button. The console displays Vulnerability Checks page with those
categories removed.
The following table lists current vulnerability categories and the number of vulnerabilities in each category
that NeXpose checks. The list is subject to change, but it is current at the time of this guide's publication.
Category # Vulns Category # Vulns Category # Vulns
Apache 228 Lotus Notes/Domino 254 Samba 120
Apache Tomcat 38 Mac OS X 5 SNMP 124
Apple 50 Mail 474 Solaris 2440
AS/400 9 Malware 118 Spyware 33
Bind 99 Microsoft 1305 SSH 104
BSD 6 Microsoft Exchange 31 Sun Microsystems 3952
Cisco 85 Microsoft IIS 107 SuSE 4042
ColdFusion 7 Microsoft Networking 24 Sybase 10
CVS 43 Microsoft SQL Server 50 Telnet 70
Database 985 Misc 17 TFTP 25
DB2 31 MySQL 149 Unix® 9792
Debian 2 NetBSD 1 Virus/Worm/Trojan 85
DHCP 41 Netware 40 VPN 54
DNS 73 NFS 39 Web 986
Finger 32 OpenBSD 2 Windows 1117
FreeBSD 3 Oracle 578 Windows 2000 12
FTP 158 PHP 277 Windows 95 2
J2EE 41 PostgreSQL 137 Windows NT 12
LDAP 111 Red Hat 1724 Windows XP 7
Linux 5793 RPC 154
To select vulnerability types for scanning...

Click the Enable vulnerability types...button.
The console displays a box listing vulnerability types. Click the check boxes for those categories you wish to scan for,
and click the Save button. The console lists the selected types on Vulnerability Checks page.
To prevent NeXpose from scanning for vulnerability types listed on the Vulnerability Checks page, click types listed on
the Vulnerability Checks page, click the Disable vulnerability types...button. Click the check boxes for those categories
you wish to exclude from the scan, and click the Save button. The console displays Vulnerability Checks page with
those types removed.
The following table lists current vulnerability types and the number of vulnerability checks that are performed for
each type. The list is subject to change, but it is current at the time of this guide's publication.
Vulnerability types Checks Vulnerability types Checks
Default account 648 Safe 36405
Local 36511 Sun patch 2515
Microsoft hotfix 3556 Unsafe 173
Patch 33757 Version 821
Policy 10 Windows registry 512
RPM 27686
To select specific vulnerability checks...

Click the Enable vulnerability checks...button.
The console displays a box where you can search for specific vulnerabilities in the database. Type a
vulnerability name, or a part of it, in the search box. Click check boxes to modify search settings as desired.
Click the Search button.
NOTE: NeXpose only checks vulnerabilities relevant to the systems that it scans. It will not perform a check against a non-compatible system
even if you specifically selected that check.
The box displays a table of vulnerability names that match your search criteria. Click the check boxes for
vulnerabilities that you wish to include in the scan, and click the Save button. The selected vulnerabilities
appear on the Vulnerability Checks page.
To exclude specific vulnerabilities from the scan, click the Disable vulnerability checks...button. Search for
the names of vulnerabilities you wish to exclude. When the console displays the search results, Click the
check boxes for vulnerabilities that you wish to exclude from the scan, and click the Save button. The
selected vulnerabilities appear on the Vulnerability Checks page.
A specific vulnerability check may be included in more than one type. If you enable two vulnerability types
that include the same check, NeXpose will only run that check once.
Configuring NeXpose to search for files on target systems

If NeXpose gains access to an asset's file system by performing an exploit or a credentialed scan, it can search for the
names of files in that system.

File name searching is useful for finding software programs that are not detected by fingerprinting. It also is a good
way to verify compliance with policies in corporate environments that don't permit storage of certain types of files on
workstation drives:
• copyrighted content
• confidential information, such as patient file data in the case of HIPAA compliance
• unauthorized software
NeXpose does read the contents of these files, and it does not retrieve them. You can view the names of scanned file
names in the File and Directory Listing pane of a scan results page.
NOTE: File searching can take a considerable amount of time, since the NeXpose Scan Engine may have to read the entire file system of an
asset to determine whether a file is present. This feature is most useful in support of penetration testing on specific target assets. It is
not recommended for routine scanning.
Go to the File Searching page.

Click the New File Search button.
The console displays a box for setting up file search criteria. Click the check box labeled Enable Search. If you
ever wish to run your new scan template without file searches, you can disable this feature without losing the
search criteria.
Type a short search description.
Select a search pattern type from the dropdown list.
The DOS wildcard pattern, which is used by Windows file systems, includes a text string and an asterisk that
acts as a variable. For example, the pattern * patient data matches any file name that includes the words
patient data preceded by any string, such as the name of a patient.
The GNU regular expression pattern is used by Unix systems. For more information, go to Appendix A: Using
regular expressions (on page 105).
Type the text string that you want search results to match.
NOTE: A high number of files may increase scan times.
Click the Save button. The console displays the new search criteria on the File Searching page.
Configuring Web spidering

You can use a Web spider, available in NeXpose, to discover Web pages and find broken links, inaccessible links,
default directories, and all vulnerabilities associate with Web application servers. The spider also finds script error
vulnerabilities by using proprietary decompiling technology to inspect JavaScript application scripts.
Some NeXpose default scan templates use the spider:
• Web audit
• HIPAA compliance
• Internet DMZ audit
• Payment Card Industry (PCI)audit
• Full audit
Go to the Web Spidering page.
Click the check box to enable Web spidering.

If you wish to include query strings when spidering, click the appropriate check box. The spider examines
links within each Web page to determine which pages have been scanned. In many Web sites, pages that are
yet to be scanned will show a base URL, followed by a parameter directed-link, in the address bar. For
example, in the address www.rapid7.com/index.html?id=6, the ?id=6 parameter probably refers to
the content that should be delivered to the browser. If you enable the setting to include query strings, the
spider will check the full string www.rapid7.com/index.html?id=6 against all URL pages already
retrieved to see whether this page has been analyzed. If you do not enable the setting, the spider will only
check the base URL without the ?id=6 parameter.
NOTE: Including query strings with Web spidering check box causes the spider to make many more requests to the Web server. This will
increase overall scan time and possibly affect the Web server's performance for legitimate users.
If you want the spider to test for persistent cross-site scripting during a single scan, select the check box for
that option. This test helps to reduce the risk of dangerous attacks via malicious code stored on Web servers.
Enabling it may increase Web spider scan times.
Type a maximum number of foreign hosts to resolve, or leave the default value of 100. This option sets the
maximum number of unique host names that the spider may resolve. This function adds substantial time to
the spidering process, especially with large Web sites, because of frequent cross-link checking involved. The
acceptable host range is 1 to 500.
Do not fill in the Spider file regex field. The associated functionality is no longer available.
To delay the spider's requests to Web servers, type a number of milliseconds in the appropriate field. Web
servers with sensitive firewalls may require a delay before fulfilling spider requests.
To set a directory depth limit for Web spidering, type a number in the field labeled Maximum directory levels
to spider. Limiting directory depth can save significant time, especially with large sites. For unlimited
directory traversal, type -1 in the field.
To limit the number of pages that the spider requests, type a number in the appropriate field. Again, this is a
time-saving measure for large sites.
To have the spider resolve DNS names, click the appropriate check box. Doing so may increase the length of
time for spidering.
To instruct the spider to adhere to standards set forth in the robots.txt protocol, click the appropriate check
box. Robots.txt is a convention that prevents spiders and other Web robots from accessing all or part of Web
site that are otherwise publicly viewable.
Type the maximum number of spider threads that NeXpose will deploy per Web server in the appropriate
field.
Type the names of any HTTP daemons that you would like the spider to bypass. Separate each name with a
comma (,).
To set a maximum link depth, type a number in the appropriate field, or leave the default value of 6. This is a
time-saving measure.
Type a regular expression for sensitive data field names, or leave the default string. NeXpose reports field
names that are designated to be sensitive as vulnerabilities. Any matches to the regular expression will be
considered sensitive data field names. NeXpose reports the vulnerability as "Form action submits sensitive
data in the clear."
Type a regular expression for sensitive content. NeXpose reports strings that are designated to be sensitive as
vulnerabilities.
If you want the scan to include base URL paths for applications that are not linked to from the main Web site,
type those URLs in the Bootstrap paths field. Example: /myapp. Separate multiple entries with commas.

If you want the scan to exclude any base URL paths, type those URLs in the Excluded paths field. If you
specify excluded paths, NeXpose will never attempt to spider those URLs or discovery any vulnerabilities or
files associated with them. Separate multiple entries with commas.
If you want to change the default value for Browser ID (User-Agent), enter a new value in the appropriate
field. The default User-Agent string represents NeXpose to the target Web site as Internet Explorer 7, which is
a highly popular browser. If you are unsure of what to enter for the User-Agent string, consult your Web site
developer.
NOTE: Changing the default user agent setting may alter the content that NeXpose receives from the Web site.
About the user-agent setting: In order to gain access to a Web site for scanning, NeXpose makes itself appear to the
Web server application as a popular Web browser. NeXpose does this by sending the server a Web page request, as a
browser would. The request includes pieces of information called headers. One of the headers, called User-Agent,
defines the characteristics of a user's browser, such as its version number and the Web application technologies it
supports. User-Agent represents NeXpose to the Web site as a specific browser, because some Web sites will refuse
HTTP requests from browsers that they do not support.
Configuring spam relaying settings

Mail relay is a feature that allows SMTP servers to act as open gateways through which mail applications can send e-
mail. Commercial operators, who send millions of unwanted spam e-mails, often target mail relay for exploitation.
Most organization now restrict mail relay services to specific domain users.
Go to the Spam Relaying page.
Type an e-mail address in the appropriate text field. This e-mail address should be external to your
organization, such as a Yahoo! or Hotmail address. NeXpose will attempt to send e-mail from this account to
itself using any mail services and mail scripts that it discovers during the scan. If NeXpose receives the e-mail,
this indicates that the servers are vulnerable.
Type a URL in the HTTP_REFERRER to use field. This is typically a Web form that spammers might use to
generate Spam e-mails.
Configuring NeXpose to test for Oracle policy compliance

Edit the default NeXpose XML policy template for Oracle (oracle.xml), which is located in
nexpose/plugins/java/1/OraclePolicyScanner/1.
To do so, copy the default template to a new file name, and edit the policy elements within the XML tags.
Then, move the new template file back into the
nexpose/plugins/java/1/OraclePolicyScanner/1 directory.
To add credentials for Oracle Database policy compliance scanning, go to the Credentials page for the site
that will incorporate the new scan template. Select Oracle as the login service domain. In the appropriate text
fields, type a user name and password for an Oracle account with DBA access. See Establishing scan
credentials (on page 43).

Configuring NeXpose to test for Lotus Domino policy compliance
Edit the default NeXpose XML policy template for Lotus Domino (domino.xml), which is located
nexpose/plugins/java/1/NotesPolicyScanner/1. To do so, copy the default template to a new
file name, and edit the policy elements within the XML tags. Then, move the new template file back into the
nexpose/plugins/java/1/NotesPolicyScanner/1 directory.
Go to the Lotus Domino Policy page and type the new policy file name in the text field.
To add credentials for Lotus Domino policy compliance scanning, go to the Credentials page for the site that
will incorporate the new scan template. Select Lotus Notes/Domino as the login service domain. In the
appropriate text field, type a Notes ID password. See Establishing scan credentials (on page 43).
For Lotus Notes/Domino policy compliance scanning, you must install a Notes client on the same host
computer that is running the NeXpose Security Console.
Configuring NeXpose to test for Windows Group Policy compliance

You can configure NeXpose to verify whether assets running with Windows operating systems are compliant with
Microsoft security standards. The NeXpose installation package includes three different policy templates that list
security criteria against which NeXpose can check settings on assets. These templates are the same as those associated
with Windows Policy Editor and Active Directory Group Policy. Each template contains all of the policy elements
for one of the three types of Windows target assets: workstation, general server, and domain controller.
A target asset must meet all the criteria listed in the respective template for NeXpose to regard it as compliant with
Windows Group Policy. To view the results of a policy scan, create a NeXpose report based on the Audit or Policy
Evaluation report template. Or, you can create a custom report template that includes the Policy Evaluation section.
See Fine-tuning information with custom report templates in the NeXpose Reporting Guide.
The templates are .inf files located in the plugins/java/1/WindowsPolicyScanner/1 path relative to the NeXpose base
installation directory:
• The basicwk.inf template is for workstations.
• The basicsv.inf template is for general servers.
• The basicdc.inf template is for domain controllers.
You also can import template files using the Security Templates Snap-In in the Microsoft Group Policy
Management Console, and then saving each as an .inf file with a specific name corresponding to the type of target
asset.
You must provide NeXpose with proper credentials to perform Windows policy scanning. See Establishing scan
credentials (on page 43).
Go to the Windows Group Policy page, and type the .inf file names for workstation, general server, and domain
controller policy names in the appropriate text fields.
NOTE: Use caution when running the same scan more than once with less than the lockout policy time delay between scans. Doing so could
also trigger account lockout.
Configuring NeXpose to test for CIFS/SMB account policy compliance

NeXpose can test account policies on systems supporting CIFS/SMB, such as Microsoft Windows, Samba, and IBM
AS/400.

Go to the CIFS/SMB Account Policy page.
Type an account lockout threshold value in the appropriate text field. This the maximum number of failed
logins a user is permitted before the asset locks out the account.
Type a minimum password length in the appropriate text field.
Configuring NeXpose to test for AS/400 policy compliance

Go to the AS/400 Policy page.
Type an account lockout threshold value in the appropriate text field. This the maximum number of failed
logins a user is permitted before the asset locks out the account. The number corresponds to the QMAXSIGN
system value.
Type a minimum password length in the appropriate text field. This number corresponds to the
QPWDMINLEN system value and specifies the minimum length of the password field required.
Select a minimum security level from the dropdown list. This level corresponds to the minimum value that
the QSECURITY system value should be set to. The level values range from Password security (20) to Advanced
integrity protection (50).
Configuring NeXpose to test for Unix policy compliance

Go to the Unix Policy page.
Type a number in the text field labeled Minimum account umask value. This setting controls the
permissions that the target system grants to any new files created on it. If NeXpose detects broader
permissions than those specified by this value, it will report a policy violation.
Configuring NeXpose to scan database servers

NeXpose performs several classes of vulnerability and policy checks against a number of databases, including:
• MS SQL/Server versions 6, 7, 2000, 2005, 2008
• Oracle versions 6 through 10
• Sybase Adaptive Server Enterprise (ASE) versions 9, 10 and 11
• DB2
• AS/400
• PostgreSQL versions 6, 7, 8
• MySQL
For all databases, NeXpose discovers tables and checks system access, default credentials, and default scripts.
Additionally, NeXpose tests table access, stored procedure access, and decompilation. Go to www.rapid7.com
(http://www.rapid7.com) for a complete list of vulnerability checks.
Go to the Database Servers page.

In the appropriate text field, type the name of a DB2 database to which NeXpose can connect.
In the appropriate text field, type the name of a Postgres database to which NeXpose can connect.
NeXpose attempts to verify a SID on a target asset through various methods, such as discovering common
configuration errors and default guesses. You can now specify additional SIDs for verification. In the
appropriate text field, type the names of Oracle SIDs to which NeXpose can connect. Separate multiple SIDs
with commas.
Configuring NeXpose to scan Web servers

Web designers and programmers may obscure site banners to help prevent attacks by outsiders against known or
unknown vulnerabilities in the Web servers. NeXpose alternately detects Web servers by using behavioral analysis in
addition to banner checking.
You can configure NeXpose to fingerprint Web servers. Doing so enables NeXpose to test for a series of known and
unknown vulnerabilities, and error types as defined by the universal specification for Web servers. As specifications
for Web services have changed over time, so the responses of Web servers has changed to keep track of those
protocols. Early versions of Apache provide different responses to non-existent URLs than later versions, for
example.
NOTE: NeXpose will use the fingerprinting mechanism instead of the banner checker when you enable this setting. NeXpose will only use the
banner checker if the behavioral engine is unable to detect the appropriate Web server version.
NeXpose tracks various versions of Apache, Tomcat, JBOSS, Resin, Websphere and IIS to detect these behavioral
adaptations to detect the Web server type.
Go to the Web Servers page.
Click the check box labeled Enable adaptive HTTP fingerprinting.
Configuring NeXpose to scan mail servers

Go to the Mail Servers page.
Type a read timeout value in the appropriate text field. This setting is the interval at which NeXpose retries
accessing the mail server. The default value is 30 seconds.
Type an inaccurate time difference value in the appropriate text field. This setting is a threshold outside of
which NeXpose will report inaccurate time readings by system clocks. The inaccuracy will be reported in the
NeXpose system log.
Configuring NeXpose to scan CVS servers

NeXpose tests a number of vulnerabilities in the Concurrent Versions System (CVS) code repository. For example, in
versions prior to v1.11.11 of the official CVS server, it is possible for an attacker with write access to the
CVSROOT/passwd file to execute arbitrary code as the cvsd process owner, which usually is root.
Go to the CVS Servers page.
Type the name of the CVS repository root directory in the text box.

Configuring NeXpose to scan DHCP servers

DHCP Servers provide Border Gateway Protocol (BGP) information, domain naming help, and Address
Resolution Protocol (ARP) table information, which may be used to reach hosts that are otherwise unknown.
Hackers exploit vulnerabilities in these servers for address information.
Go to the DHCP servers page.
Type a DHCP address range in the text field. NeXpose will then target those specific servers for DHCP
interrogation.
Configuring NeXpose to scan Telnet servers

Telnet is an unstructured protocol, with many varying implementations. This renders Telnet servers prone to yielding
inaccurate scan results. You can improve scan accuracy by providing NeXpose with regular expressions.
Go to the Telnet Servers page.
Type a character set for NeXpose to use in the appropriate text field.
Type a regex for a logon prompt in the appropriate text field.
Type a regex for a password prompt in the appropriate text field.
Type a regex for failed logon attempts in the appropriate text field.
Type a regex for questionable logon attempts in the appropriate text field.
For more information, go to Appendix A: Using regular expressions (on page 105).
Using default and customized credential checking

Many products provide default login user IDs and passwords upon installation. Oracle ships with over 160 default
user IDs. Windows users may not disable the guest account in their system. If you don't disable the default account
vulnerability check type when creating a scan template, NeXpose can perform checks for these items. See Configuring
vulnerability check settings (on page 67) for information on enabling and disabling vulnerability check types.
NeXpose performs checks against databases, applications, operating systems, and network hardware using the
following protocols.

CVS Sybase
AS/400 DB2
SSH Oracle
Telnet CIFS (Windows File Sharing)
FTP POP
HTTP SNMP
SQL/Server SMTP
To specify users IDs and passwords for logon, a you must enter appropriate credentials during site configuration. See
Establishing scan credentials (on page 43). If a specific asset is not chosen to restrict credential attempts then NeXpose
will attempt to use these credentials on all assets. If a specific service is not selected then NeXpose will attempt to use
the supplied credentials to access all services.
Other tuning options

Beyond customizing NeXpose scan templates, you can do other things to improve scan performance.
Changing net.ipv4.neigh.default.gc_thresh3 setting

NOTE: gc_thresh settings are already optimized on NeXpose Appliances.
If you are running NeXpose on a Linux host, you can speed up the discovery phase of a scan by increasing the
net.ipv4.neigh.default.gc_thresh3 setting on NeXpose Scan Engine host computers. This setting determines the size
of the ARP table, which caches MAC addresses of IP assets on the local network. The value corresponds to the
number of assets that NeXpose can discover efficiently when scanning a local network or subnet as opposed to a
network/subnet through a gateway.
The default setting is 1024, which means that NeXpose can efficiently discover 1024 assets. If the number exceeds
this threshold, NeXpose encounters "transient network errors," which can prolong scan time. It is a best practice to
change the value to the maximum number of IP addresses that NeXpose will scan in the local subnet or subnets. For
example, in a /18 subnet, you would change the value to 16384.
To alter the setting, access the scan engine host using ssh, console access, or a similar method. Then, enter the
following command:
sysctl -w net.ipv4.neigh.default.gc_thresh3=16384
It is a standard practice to set the gc_thresh1 to a quarter of the value of gc_thresh3 and to set the gc_thresh2 value
to half. So, if you change the gc_thresh3 setting to 16384, change the other two settings accordingly:
Also, most Linux distributions contain a file /etc/sysctl.conf that you can modify to make these settings permanent.
To do so, add the following three lines to the file:
net.ipv4.neigh.default.gc_thresh3=16384

Changing scan engine deployment

Depending on bandwidth availability, adding scan engines can reduce scan time over all, and it can improve accuracy.
Where you put scan engines is as important as how many you have. It's helpful to place scan engines on both sides of
network dividing points, such as firewalls. See Distribute scan engines strategically (on page 20).
Editing site configuration

Tailor your site configuration to support your performance goals. Try increasing the number of sites and making sites
smaller. Try pairing sites with different scan templates. Adjust your scan schedule to avoid bandwidth conflicts.
Increasing NeXpose resources

Resources fall into two main categories:
• Network bandwidth
• RAM and CPU capacity of NeXpose hosts
If your organization has the means and ability, enhance network bandwidth. If not, find ways to reduce bandwidth
conflicts when running scans.
Increasing the capacity of NeXpose host computers is a little more straightforward. The NeXpose Installation Guide
lists minimum system requirements for installation. Your system may meet those requirements, but if you want to
bump up maximum number of scan threads, you may find your host system slowing down or becoming unstable.
This usually indicates memory problems.
If increasing scan threads is critical to meeting your performance goals, consider installing the 64-bit version of
NeXpose. A scan engine running on a 64-bit operating system can use as much RAM as the operating system
supports, as opposed to a maximum of approximately 4 GB on 32-bit systems. The vertical scalability of 64-bit scan
engines significantly increases the potential number simultaneous scans that NeXpose can run.
Always keep in mind that best practices for scan engine placement. See Distribute scan engines strategically (on page
20). Bandwidth is also important to consider. See Increasing resource availability (on page 51).
Making your environment "scan-friendly"

Any well constructed network will have effective security mechanisms in place, such as firewalls. These devices will
regard NeXpose as a hostile entity and attempt to prevent it from communicating with assets that they are designed
to attack.
If you can find ways to make it easier for NeXpose to coexist with your security infrastructure—without exposing
your network to risk or violating security policies—you can enhance scan speed and accuracy.
For example, when scanning Windows XP workstations, you can take a few simple measures to improve
performance:
• Make NeXpose a part of the local domain.
• Give NeXpose the proper domain credentials.
• Configure the XP firewall to allow NeXpose to connect to Windows and perform patch-checking
• Edit the domain policy to give NeXpose communication access to the workstations.

Managing users and asset groups
Effective use of the information that NeXpose collects depends on how your organization analyzes and distributes it,
who gets to see it, and for what reason.
Managing access to information in NeXpose involves creating asset groups and assigning roles and permissions to
users.
This chapter provides best practices and instructions for managing users and access groups.
Creating roles and defining roles and permissions

Role-based access control (RBAC) gives you a great deal of flexibility and control over who sees and does what in
NeXpose.
Understanding roles in NeXpose

Five default roles exist in NeXpose:
• Global administrator (on page 79)
• Security manager (on page 80)
• Site administrator (on page 80)
• System administrator (on page 81)
• Nonadministrative user (on page 81)
You can create user accounts with default roles, or you can create custom roles that include any grouping of
permissions that make sense for your organization.
Global administrator
The global administrator role provides the ability to perform all NeXpose Security Console functions for managing
users, sites, scans, asset groups, vulnerabilities, reports, and the console itself:
• create and modify user accounts
• assign and change roles and permissions for users
• give users access to sites and asset groups, or deny access
• view data about discovered assets
• create sites and asset groups
• configure all possible site settings, including target assets to scan
• set up scan engines
• set up scan templates
• set up alerts about scan-related events

• provide NeXpose with logon credentials for deeper scanning capability on password-protected assets
• schedule automatic scans, and run one-off scans manually as needed
• add or remove assets (does not include the ability to delete the underlying asset definition, or discovered asset data)
• create, modify, and run reports
• exclude specific vulnerabilities from reports
• create and assign job tickets for vulnerability remediation
• maintain the NeXpose Security Console
• configure settings for the NeXpose Security Console
A global administrator has access to all sites and asset groups.
Security manager
The security manager role provides the ability to perform a subset of NeXpose functions related to sites, asset groups,
scans, and reports:
• enter a site description and risk factor in the configuration settings for each accessible site
A security manager can only perform these functions in sites and asset groups to which he or she has been granted
access by a global administrator.
Site administrator
The site administrator role provides the ability to perform a subset of NeXpose functions related to sites, scans, and
reports:
NOTE: The difference between the security manager role and the site administrator role is that a site administrator can only operate within
sites, not asset groups. A security manager can operate within both.

• enter a site description and risk factor in the configuration settings for each accessible site
A site administrator can only perform these functions in sites to which he or she has been granted access by a global
administrator.

System administrator
The system administrator role provides the ability to perform a subset of NeXpose functions related to sites, asset
groups, scans, and reports. This subset is smaller than that of the security manager role:
• run one-off scans manually as needed
A system administrator can only perform these functions in sites and asset groups to which he or she has been
granted access by a global administrator.
Nonadministrative user
The nonadministrative user role notably differs from all other default NeXpose roles in that it does not include the
ability to run scans. This role provides the ability to perform two primary functions related to asset groups and
reports:
A nonadministrative user can only perform these functions in sites and asset groups to which he or she has been
granted access by a global administrator.
Map roles to your organization

It is helpful to study how NeXpose roles and permissions map to your organizational structure.
NOTE: NeXpose includes a user authentication system. However, if your organization already uses an authentication service that incorporates
Microsoft Active Directory or Kerberos, it is a best practice to integrate NeXpose with this service. Using one service prevents having to
manage two sets of user information.
In a smaller company, one person may handle all security tasks. He or she will be a NeXpose global administrator,
initiating scans, reviewing reports, and performing remediation. Or there may be a small team of people sharing
access privileges for the entire NeXpose system. In either of these cases, it is unnecessary to create multiple roles,
because all network assets can be included in one site, requiring a single scan engine.
Example, Inc. is a larger company. It has a wider, more complex network, spanning multiple physical locations and
IP address segments. Each segment has its own dedicated support team managing security for that segment alone.
One or two NeXpose global administrators are in charge of creating user accounts, maintaining the NeXpose system,
and generating high-level, executive reports on all company assets. They create sites for different segments of the
network. They assign security managers, site administrators, and system administrators to run scans and distribute
reports for these sites.
The global administrators also create various asset groups. Some will be focused on small subsets of assets. Non-
administrative users in these groups will be in charge of remediating vulnerabilities and then generating reports after
follow-up scans are run to verify that remediation was successful. Other asset groups will be more global, but less
granular, in scope. The non-administrative users in these groups will be senior managers who view the executive
reports to track progress in the company's vulnerability management program.
Paranoia can be time consuming

How you define roles and permissions in NeXpose should refer back to your security goals. What are you gathering
data for? Who needs to see it? How do you want them to view it.

And, realistically, how much work do you want to create for yourself?
If you're a security team leader or auditor, it may be tempting for you to severely limit or even prevent co-workers'
access to asset data. But if you're the only person who sees most of the data, you can make yourself a bottleneck,
especially in a large corporation.
The NeXpose RBAC model is highly flexible and "fine tuned." It's easy to give appropriate stakeholders access to a
narrow subsets of asset data without giving away control over the organization's overall security structure. Think
about roles in terms of asset ownership. Perhaps a particular IT person who supports workstations should be a
security manager for workstations.
As with other NeXpose operations, best practices for managing roles and permissions involves balancing resources
and time. NeXpose isn't designed to make your security team busier but to make them enforce your security policies
more efficiently.
Managing and creating user accounts

The Users links on the Administration page provide access to pages for creating and managing NeXpose user
accounts. Click the manage link next to Users to view the Users page. On this page, you can view a list of all NeXpose
accounts within your organization.
To edit a user account, click the Edit icon for any listed account, and change its attributes. NeXpose displays
the User Configuration wizard. The process for editing an account is the same as the process for creating a
new user account. See Configuring general user account attributes (on page 82).
To delete an account, click the Delete icon for that account. If that account has been used to create a report,
or if that account has been assigned a ticket, NeXpose displays a dialogue box prompting you to reassign or
delete the report or ticket in question. Doing the latter might make sense for a ticket that concerns a closed
issue or an old report that contains out-of-date information.
To assign listed items to an alternate account, select an account from the dropdown list, and click the
Reassign items button.
OR
Click the Delete items button to remove these items from the NeXpose database.
Configuring general user account attributes

On the Users page, click the New User button. Or click the Create button next to Users on the Administration
page. The console displays the General page of the User Configuration wizard.
Enter all requested user information in the text fields.
If you wish to authenticate the user with external sources, select the appropriate source from the dropdown
list. Before you can create externally authenticated user accounts you must define external authentication
sources. See Using external sources for user authentication (on page 88).
Check the Account enabled check box. You can later disable the account without deleting it by clicking the
checkbox again to remove the checkmark.
To save the new user information, click the Save button, which appears on every page of the wizard.
Assigning a role and permissions to a user

Assigning a role and permissions to a new user allows you to control that user's access to NeXpose Security Console
functions.

On the Roles page, choose a role from the dropdown list. When you select a role, the console displays a brief
description of that role. See Understanding roles in NeXpose (on page 79).
If you choose one of the five default NeXpose roles, the console will automatically select the appropriate
check boxes for that role.
If you choose Custom Role, select the check box for each permission that you wish to grant the user.
Giving a user access to specific sites

A global administrator automatically has access to all sites. A security manager, site administrator, system
administrator, or nonadministrative user has access only to those sites granted by a global administrator.
Go to the Site Access page.
If you wish to give the user access to all sites, click the appropriate radio button.
If you wish to give the user access to specific sites, click the radio button for creating a custom list of
accessible sites. Then, click the Add Sites button.
The console displays a box listing all sites within your organization. Click the check box for each site that you
want the user to access.
Click the Save button.
The new site appears on the Site Access page.
Giving a user access to asset groups

A global administrator automatically has access to all asset groups. A site administrator user has no access to asset
groups. A security manager, system administrator, or nonadministrative user has access only to those access groups
granted by a global administrator.
Go to the Asset Group Access page.
If you wish to give the user access to all asset groups, click the appropriate radio button.
If you wish to give the user access to specific asset groups, click the radio button for creating a custom list of
accessible asset groups. Then, click the Add Groups button.
The console displays a box listing all asset groups within your organization. Click the check box for each asset
group that you want this user to access.
Click the Save button.
The new asset group appears on the Asset Group Access page.
Using asset groups to your advantage

Asset groups provide different ways to view asset information. You can use the same grouping principles that you use
for sites. Or, you can base asset groups on membership.
For example, you can have an "Executive" asset group for senior company officers who see high-level business-
sensitive reports about all the assets within your enterprise. You can have more technical asset groups for different
members of your security team, who are responsible for remediating vulnerabilities on specific types of assets, such as
databases, workstations, or Web servers.

One use case illustrates how asset groups can "spin off" organically from sites. A bank purchases NeXpose with a
fixed-number IP address license. The network topology includes one head office and 15 branches, all with similar
"cookie-cutter" IP address schemes. The IP addresses in the first branch are all 10.1.1.x.; the addresses in the second
branch are 10.1.2.x; and so on. For each branch, whatever integer equals .x is a certain type of asset. For example .5 is
always a server.
The security team scans each site and then "chunks" the information in various ways by using reports and asset
groups. It creates one set of asset groups based on locations so that branch managers can view vulnerability trends and
high-level data.
The team creates another set of asset groups based on that last integer in the IP address. The users in charge of
remediating server vulnerabilities will only see ".5" assets. If the "x" integer is subject to more granular divisions, the
security team can create more finally specialized asset groups. For example .51 may correspond to file servers and .52
may correspond to database servers.
Asset groups also have a useful security function in that they limit what members can see and dictate what non-
members cannot see. The asset groups that you create will influence the types of roles and permissions you assign to
users, and vice-versa.
Managing and creating asset groups

Organizing asset groups has a number of benefits. Since an asset group can contain assets from multiple sites, each
using a different scan engine, you can generate reports incorporating information from multiple scan engines.
NOTE: You can only create an asset group after running an initial scan of assets that you wish to include in that group.
The Groups links on the Administration page provide access to pages for creating and managing asset
groups. Click the manage link next to Groups to view the Groups page. On this page, you can view a list of all
NeXpose asset groups within your organization. You also can click the link for any asset group name to view a
list of assets it includes.
To edit an asset group, click the Edit icon for any listed asset group to change its attributes. NeXpose displays
the Group Configuration wizard. The process for editing an existing group is the same as the process for
creating a group. See Configuring general asset group attributes (on page 84).
Configuring general asset group attributes

On the Groups page, click the New User button. Or click the Create button next to Groups on the
Administration page. The console displays the General page of the Group Configuration wizard.
Type a group name and description in the appropriate fields.
To save the new asset group information, click the Save button, which appears on every page of the wizard.
Adding assets to a group

Go to the Assets page.
Click the Select Devices… button.
The console displays a list of assets in your organization. Click the check box for each asset that you wish to
add to the new group.
Click the Save button. The assets appear on the Assets page.
To save the new asset group information, click the Save button, which appears on every page of the wizard.

Managing and maintaining NeXpose
This chapter provides instructions for managing and maintaining NeXpose through controls in the Web interface
and a set of command prompts.
Managing global settings

The Manage Global Settings link on the Administration page provides access to pages for controlling how risk scores
are calculated, and which assets get scanned throughout your entire NeXpose deployment.
Selecting a model for calculating risk scores

NeXpose calculates a risk score for every asset, indicating the potential danger that this asset would pose to your
network or business security if an attacker were to access it. It is a best practice to use risk scores to prioritize
remediation tasks. The risk score appears in the Current Risk column of the Device Listing table for each site.
Many factors influence how a risk score is calculated. And there are different ways to calculate risk scores based on
how these factors are analyzed. With NeXpose, you can select from two risk scoring models for your asset listings.
Each model uses an algorithm that emphasizes certain factors.
Weighted risk score model: The scoring in this model is based primarily on asset data and vulnerability types, and it
emphasizes the following factors:
• vulnerability severity, which is the number—ranging from 1 to 10—that NeXpose calculates for each
vulnerability
• number of vulnerability instances
• type of asset, such as a computer, router, or wireless access point (WAP)
• number and types of services on the asset; for example, a database has higher business value
• the level of importance, or weight, that you assign to a site when you configure it; see Specifying general site
information (on page 32)
NOTE: The Weighted risk score model is the NeXpose legacy model. If your NeXpose deployment predates the 4.8 version, and you have been
tracking risk score trends prior to the 4.8 release, be aware that switching to the Temporal risk score model will dramatically change
data values because of the different scoring system.
Weighted risk scores scale with the number of vulnerabilities. A higher number of vulnerabilities on an asset means a
higher risk score. The score is expressed in lower—usually in single digit—numbers with decimals.
Temporal risk score model: This model is based on the length of time that the vulnerability has existed and the
nature of the risk. Older vulnerabilities are easier to exploit because attackers have known about them for a longer
period of time. The temporal model emphasizes the following factors:
• age of the vulnerabilty, which is determined by the date that it was published
• degree of ease with which the vulnerability can be exploited—whether it can be exploited remotely and
whether access requires authentication

• the nature of the risk—the potential potential impact of an attack to data confidentiality, integrity, and
availability (CIA)
o confidentiality impact—data is disclosed to unauthorized individuals or systems; for example, an
attacker steals credit card data
o integrity impact—data is rendered inauthentic or incomplete; for example, a virus removes records in a
payroll database
o availability impact—data or services are rendered inaccesible; for example, a denial-of-service attack
brings down a Web server
NOTE: CIA vectors are used in the Common Vulnerability Scoring System (CVSS), Version 2.
Temporal risk scores scale with the severity level of vulnerabilites. Higher vulnerability severity levels make for a
higher risk score. The score is expressed in high, whole numbers, ranging as many as six digits. There is no "highest"
number. These numbers are relative to each other.
Because this scoring model is heavily influenced by time and severity, it is the ideal option for new deployments, since
it can help you prioritize remediation projects better.
NOTE: The Rapid7 Professional Services Organization (PSO) offers custom risk scoring development. For more information, contact Rapid7
Technical Support.
To view and select a risk scoring model, go to the Risk Scoring page of the Global Settings configuration wizard.
Select a model from the dropdown list, or click the Browse... button to view more information about the models.
If you click Browse..., NeXpose displays a dialog box that lists the models and brief descriptions. Click the link for
either model to select it.
If you change the current risk model, you may need to refresh your browser before NeXpose displays the scores for
that model.
Excluding specific devices from scans in all possible sites

On the Devices page of the Site Configuration wizard, you can exclude specific assets from scans in the site you are
creating. However, assets can belong to multiple sites. If you are managing many sites, it can be time-consuming to
exclude assets from each site. You may want to quickly prevent a particular asset from being scanned under any
circumstances. A global configuration feature makes that possible. On the Device Exclusions page, you can quickly
exclude specific assets from from scans in all sites throughout your deployment.
NOTE: If you specify a host name for exclusion, NeXpose will attempt to resolve it to an IP address prior to a scan. If it is initially unable to do
so, it will perform one or more phases of a scan on the specified asset, such as pinging or port discovery. In the process, NeXpose may
be able to determine that the asset has been excluded from the scope of the scan, and it will discontinue scanning it. However, if
NeXpose is unable to make that determination, it will continue scanning the asset.
On the Administration page, click the link for managing global settings, and then go to the Device Exclusions
page.
Manually enter addresses and host names in the text box labeled Devices ; or import a comma- or new-line-
delimited ASCII-text file that lists addresses and host names that you don't want to scan. To do so, click
Browse button in the Excluded Devices area, and select the appropriate .txt file from the local computer or
shared network drive for which read access is permitted. Each address in the file should appear on its own
line. Addresses may incorporate any valid NeXpose convention, including CIDR notation, host name, fully
qualified domain name, and range of devices.
Click Save.

Managing NeXpose Security Console settings
Although the default security console settings should work for a broad range of network environments, you can
change settings to meet specific scanning requirements.
Click the Manage link next to NeXpose Security Console on the Administration page to launch the NeXpose
Security Console Configuration wizard.
Viewing general configuration settings

On the General page, you can view the version and serial numbers for the instance of the NeXpose Security Console
that you are using.
You also can enable the process auto-stop feature, which pauses scans and stops report generation when the memory
on the NeXpose host server is dangerously low. The benefit of this feature is that it reduces the possibility of the
server failing. However, it may cause NeXpose to stop scans or reporting activities before they are complete.
Changing the console Web server default settings

The security console runs its own Web server, which delivers the NeXpose interface.
Go to the Web Server page.
Type a new number for the access port if desired.
Type a new session timeout if desired. This value is the allowed number of seconds of user inactivity after
which the console times out, requiring a new logon.
Type new numbers for initial request and maximum request handler threads, if necessary. It is recommended
that you consult Rapid7 Technical Support first. In this context, threads refer to the number of simultaneous
connections that the console will allow. Typically a single browser session accounts for one thread. If
simultaneous user demand is high, you can raise the thread counts to improve performance. The console will
increase the thread count dynamically if required, so manual increases may be unnecessary.
Type a new number for failed logon threshold if desired. This is the number of failed logon attempts that the
console permits before locking out the would-be user.
To save the new console information, click the Save button, which appears on every page of the wizard.
Managing the HTTPS certificate

NeXpose, by default, uses a self-signed X.509 certificate which is created during installation. You can replace this
certificate with a custom, self-signed certificate or a certificate signed by a trusted certification authority (CA), such
as VeriSign, Thawte or your own CA.
NOTE: The signed certificate must be based on a NeXpose-generated CSR. NeXpose does not allow you to import an arbitrary key
pair/certificate that you generated.
You can view the current HTTPs certificate on the Web server page. You also can change the certificate in
three different ways.
You can create a new, self-signed SSL certificate to overwrite the current one for the NeXpose Web server.
You can use the new certificate 'as-is' or you can have it can be signed by a CA by generating a certificate
signing request (CSR).
Click the Manage HTTPS Certificate button on the Web Server page.
The console displays a box titled Manage HTTPs Certificate. Click the Create New Certificate link.

The console displays a box for new certificate information. Type the information, and click the Create button.
Then, click the Done button. The new certificate name appears on the Web Server page.
To generate a CSR once you have created a new certificate…
In the Manage HTTPs Certificate box, click the Generate CSR link.
You may then copy the generated CSR and send to your CA.
To import a certificate after it is signed by your CA…
Copy the certificate.
In the Manage HTTPs Certificate box, click the Import Certificate link.
NOTE: The certificate can contain one or more subject-alternative X.509 name extensions.
Paste it in the text box and click the Import button. Then, click Done.
Configuring auto-update settings

The auto-update function enables the NeXpose Security Console to redirect its update requests to an alternative
server. Rapid7 Technical Support will advise if you need to change this setting.
If the console has no direct connection to the Internet, a preconfigured proxy server can allow indirect access.
NOTE: For information on configuring updates for an appliance, see the NeXpose Console and Scan Engine Appliance Quick-start Guide and the
NeXpose Scan Engine Appliance Quick-start Guide, which you can download from the Support page of NeXpose Help.
Go to the Auto-Updating page.

Type the information for the proxy server in the appropriate fields.
Initiate an auto-update using the update now command. See Using the command prompt (on page 95).
Using external sources for user authentication

You can integrate NeXpose with external authentication sources. If you use one of these sources, leveraging your
existing infrastructure will make it easier for you to manage NeXpose user accounts. NeXpose provides single-sign-on
external authentication with two sources:
• LDAP (including Microsoft Active Directory): Active Directory (AD) is an LDAP-supportive Microsoft
technology that automates centralized, secure management of an entire network's users, services, and
resources.
• Kerberos: Kerberos is a secure authentication method that validates user credentials with encrypted keys and
provides access to network services through a "ticket" system.
NeXpose also continues to support its two internal user account stores:
• XML file lists default "built-in" accounts, such as nxadmin. A NeXpose global administrator can use a
built-in account to log on to NeXpose in maintenance mode to troubleshoot and restart the system when
database failure or other issues prevent access for other users.
• Datastore lists standard user accounts, which are created by a NeXpose global administrator.

Before you can create externally authenticated user accounts you must define external authentication sources.
Go to the Authentication page in the NeXpose Security Console Configuration wizard.
To add an LDAP/Active Directory authentication source, click the Add... button in the area labled LDAP/AD
authentication sources.
The console displays a box labeled LDAP/AD Configuration. Click the checkbox labeled Enable
authentication source.
In the appropriate text fields, type the name, address or fully qualified domain name, and port of the LDAP
server that you wish to use for authentication. Default LDAP port numbers are 389 or 636, the latter being for
SSL. Default port numbers for Microsoft AD with Global Catalog are 3268 or 3269, the latter being for SSL.
NOTE: For best results, it is recommended that you use a fully qualified domain name for the LDAP server configuration.
If you wish to require secure connections over SSL, select the appropriate check box.
If you wish to specify permitted authentication methods, type them in the appropriate text field. Separate
multiple methods with commas (,), semicolons (;), or spaces. Simple Authentication and Security Layer (SASL)
authentication methods for permitting LDAP user authentication are defined by the Internet Engineering
Task Force in document RFC 2222 (http://www.ietf.org/rfc/rfc2222.txt (http://www.ietf.org/rfc/rfc2222.txt)).
NeXpose supports the use of GSSAPI, CRAM-MD5, DIGEST-MD5, SIMPLE, and PLAIN methods. However, it is
not recommended that you use PLAIN for non-SSL LDAP connections.
Click the checkbox labeled Follow LDAP referrals if desired. As NeXpose attempts to authenticate a user, it
queries the target LDAP server. The LDAP and AD directories on this server may contain information about
other directory servers capable of handling requests for contexts that are not defined in the target directory.
If so, the target server will return a referral message to NeXpose, which can then contact these additional
LDAP servers. For information on LDAP referrals, see the document LDAPv3 RFC 2251
(http://www.ietf.org/rfc/rfc2251.txt).
Type the base context for performing an LDAP search if desired. You can initiate LDAP searches at many
different levels within the directory. To force NeXpose to search within a specific part of the tree, specify a
search base, such as CN=sales,DC=acme,DC=com.
Click one of the three buttons for LDAP attributes mappings, which control how LDAP attribute names
equate, or map, to NeXpose attribute names. Your attribute mapping selection will affect which default
values appear in the three fields below. For example, the LDAP attribute Login ID maps to the NeXpose
user's login ID. If you select AD mappings, the default value is sAMAccountName. If you select AD Global
Catalog mappings, the default value is userPrincipalName. If you select Common LDAP mappings, the
default value is uid.
Click Save. The console displays the Authentication page with the LDAP/AD authentication source listed.
To add a Kerberos authentication source, click the Add... button in the area of the Authentication page
labeled Kerberos Authentication sources.
The console displays a box labeled Kerberos Realm Configuration. Click the checkbox labeled Enable
To set the new realm that you are defining as the default Kerberos realm, click the appropriate checkbox. If
you do so, the console will display a warning that the default realm cannot be disabled.
Type the name of the realm in the appropriate text field.
Type the name of the key distribution center in the appropriate field.
Click Save. The console displays the the Authentication page with the new Kerberos distribution center listed.

Once you have defined external authentication sources, you can create accounts for users who are
authenticated through these sources.
On the Home page, click the Administration tab. On the Administration page, click the Create link next to
Users.
The console displays the User Configuration wizard. On the General page, the Authentication method
dropdown list contains the authentication sources that you defined in the NSC configuration file. Select an
NeXpose built-in user store authentication is represented by the “NeXpose user” option.
The “Active Directory” option indicates the LDAP authentication source that you specified in the NSC
configuration file.
If you select an external authentication source, NeXpose disables the password fields. NeXpose does not
support the ability to change the passwords of users authenticated by external sources.
Fill in all the other fields on the General page.
NOTE: If you log on to the interface as a user with external authentication, and then click your user name link at the top right corner of any
page, the console displays your account information, including your password; however, if you change the password on this page,
NeXpose will not implement the change.
Viewing console database information

You can view the name and type of the console database on the Data Store page.
Changing default settings for NeXpose logging

Troubleshooting NeXpose related issues can be complex. The same system may respond in different ways during
different scans based on network traffic, prior access mechanisms, and server performance. NeXpose generates logs
that detail scan-related problems. These are helpful for troubleshooting.
NOTE: Only change the default logging setting if Rapid7 Technical Support advises you to do so.
Go to the Logging page.

Click the checkbox to enable verbose logging if desired. This is a logging mode that records more detailed
information.
Type new values for maximum log file size and number of saved log files if desired.
Click the checkbox to remove the checkmark for compressing saved log files if desired.
Click one of the radio buttons to enable database query logging if desired.
Changing default scan engine settings

On Scan Engines page you can view and edit default settings that affect NeXpose scan engines.
If you wish to change the default setting for scan status timeout, type the new value in the appropriate text
field. For each scan, NeXpose creates a corresponding thread to monitor its status. If a thread has no scan to
monitor, a timeout occurs. When the timeout interval elapses, NeXpose destroys the thread.

If you wish to change the default setting for core scan status thread pool size, type the new value in the
appropriate text field. This setting controls the number of threads that NeXpose retains to contact distributed
scan engines for scan status updates. A pool makes it possible to use processor resources more efficiently,
especially when monitoring a large number of distributed scan engines. For example, you can retain a pool of
5 threads to monitor the status of 100 scans.
If you wish to change the default setting for connection timeout, type the new value in the appropriate field.
When this time interval elapses, NeXpose closes an idle connection.
NOTE: Remote scan engines must be running with NeXpose version 4.8 or later in order to support incremental scan result retrieval.
You can choose to have NeXpose retrieve incremental scan results from remote scan engines, including
Rapid7 hosted engines. Incremental scan results appear in the Scan Progress page while the scan is still
running. They are notifications of individual scan events, such as the discovery of each asset and the flagging
of each vulnerability. By default, NeXpose only retrieves incremental results from the local scan engine, which
runs on the same host as the NeXpose Security Console; and it displays the full set of scan results from a
remote engine after the scan has been completed. Having NeXpose retrieve incremental scan results from
remote engines may slightly increase bandwidth use.
Enabling retrieval of incremental scan results may cause noticeable delays in scan times over high-latency or
low-bandwidth connections.
To change the default setting for incremental scan results, select the option button for local and remote scan
engines.
Entering a new product key or requesting a new key

On the Licensing page, you can see license-related information about your NeXpose Security Console. You also can
enter a new product key or request a new product key.
The value for License Status is one of four different modes, depending on the status of your NeXpose license.
The value for Expiration is the date that your current NeXpose license expires.
The value for Max. Scan Engines is the total number of internal NeXpose Scan Engines that you can use. These scan
engines can be installed on any host computers on your network.
The value for Max. Assets to Scan is the total number of assets that you can scan with your internal NeXpose Scan
Engines.
The value for Max. Assets to Scan w/ Hosted Engine is the total number of assets that you can scan with a Rapid7
Hosted Scan Engine.
If the value for SCADA Scanning is Enabled, you can scan assets with the NeXpose SCADA scan template. For a
description of this template, see Specifying scan settings (on page 33).
If the value for Discovery Scanning is Enabled, you can run discovery scans to determine what assets are available on
your network without performing vulnerability checks on those assets.
If the value for PCI Reporting is Enabled, you can create reports using the PCI Executive Overview and PCI Audit
report templates.
If a member of Rapid7 Technical Support provides you with a new product key, enter it in the fields indicated,
and then click Activate.
The purpose of entering a product key is to prompt NeXpose to install a new license. You only have to enter a
product key if Rapid7 Technical Support has sent you one via e-mail and instructed you to enter it.

The product key is a 16-digit combination of numerals and letters, divided into four-digit segments that are
separated by hyphens.
Example: 123B-45CD-KL89-Z025
If you think you need a product key, you can request one via e-mail. Click the button labeled New Key...,
which opens your e-mail client with a Rapid7 Technical Support address in the To: field.
Backing up and restoring NeXpose

Running regularly scheduled backup and restore routines ensures full recovery of the NeXpose Security Console in
the event of hardware failure. NeXpose performs actual backup and restore procedures in maintenance mode. It
cannot run these procedures while scans are in progress. See Running NeXpose in maintenance mode (on page 94).
However, you set up backup and restore operations while NeXpose is in normal mode.
Important notes on backup and restore

There are four possible options on the backup/restore page:
• Backup NeXpose data onto the NeXpose file system.
• Restore a NeXpose installation from a prior backup already on the NeXpose file system.
• Copy an existing backup to external media using the Browse button.
• Restore a NeXpose installation from a prior backup on external storage.
NOTE: You should copy backed data up to external storage media to prevent loss in the event of a hardware failure.
What is saved and restored

A NeXpose backup will save the following items:
• NeXpose database
• configuration files (nsc.xml, nse.xml, userdb.xml, and consoles.xml)
• licenses
• keystores
• report images
• custom report templates
• custom scan templates
• generated reports
• scan logs
Backing up NeXpose data

To backup NeXpose data, go to the NeXpose Maintenance Mode—NeXpose Backup/Restore page, which you
can access from the Maintenance link on the Administration page.
Type a short description of the new backup for your own reference and click the Start Backup button.
NeXpose displays a message indicating that if you proceed with the backup, NeXpose then restart in
Maintenance Mode.

The console will restart in maintenance mode and run the backup. If you're a NeXpose global administrator,
you can log on to monitor the backup process. You will see a page that lists each backup activity. When you
see a notification that the backup is complete, click the Restart Server button.
NeXpose displays a message indicating that any pending maintenance activities will be canceled if you
proceed with the restart. Click the Restart button at the bottom of that message.
Restoring NeXpose data

The restore procedure will re-establish the NeXpose system to its exact pre-backup state. This means that NeXpose
will retain the serial number, license limits, sites, templates, and all other relevant files and data.
If a hardware failure has rendered a NeXpose system unusable, reinstall NeXpose.
NOTE: If you perform a data restoration, you must contact Rapid7 Technical Support.
You should not run more than one instance of the NeXpose Security Console at any time. The update process that
retrieves new vulnerability definitions verifies the serial number and the current update level before pulling new
updates to the security console. If more than one security console with the same serial number presents out-of-
sequence update data, the update process will be halted on all systems with that serial number, requiring Rapid7
Technical Support to reset the synchronization counter.
Go to the NeXpose Maintenance Mode—NeXpose Backup/Restore page, which you can access from the
Maintenance link on the Administration page.
Click the Browse... button to search for a specific file on the backup media, and then, after finding the file,
click the Start Upload and Restore button.
As with backup, NeXpose will go into maintenance mode to restore the file. Afterward, you may restart
NeXpose in normal operating mode.
Performing database maintenance

You can initiate several maintenance operations to maximize database performance and drive space.
NOTE: Database maintenance operations can take from a few minutes to a few hours, depending on the size of the database. Also, once you
start these operations, NeXpose shuts down and restarts in Maintenance Mode to perform them. Any in-progress scans or reports will
stop before completion and lose any resulting data. You will have to rerun any reports or scans after NeXpose completes maintenance
operations and restarts in Normal Mode. For more information, see Running NeXpose in maintenance mode (on page 94).
Go to the NeXpose Maintenance Mode—NeXpose DB Maintenance page.

Select the check box labeled Clean up Database to remove leftover data that is associated with deleted
objects such as sites, assets, or users.
Select the check box labeled Compress Database tables to free up unused table space.
Select the check box labeled Reindex Database to rebuild indexes that may have become fragmented or
corrupted over time.
After selecting the desired maintenance operations, click the button labeled Start Database Maintenance.
Running NeXpose diagnostics

Selecting diagnostic routines (on page 94)
Sending scan logs (on page 94)

Selecting diagnostic routines
To run diagnostics for internal NeXpose issues…
Click the Administration tab.
On the Administration page, click the Diagnose link next to Troubleshooting.
The console displays the Troubleshooting page. Click the check box for each diagnostics routine you want to
perform.
After performing the requested diagnostics, the console displays a table of results. Each item includes a red or green
icon, indicating whether or not an issue exists with the respective system component.
Sending scan logs

You can transmit logs generated by scan engines to Technical Support at Rapid7 by clicking the Send Logs
button on the Troubleshooting page.
Click the Send Logs button on the Troubleshooting page.
NOTE: An optional SMTP (e-mail) transport mechanism is also supported where a direct link is unavailable. Contact Rapid7 Technical Support
for more information.
The console displays a box for uploading the logs. Select an upload method from the dropdown list. For the
HTTPS upload, NeXpose encrypts the logs using PGP before sending them directly over an SSL connection to
the Rapid7 DMZ, and subsequently to the Rapid7 support database. This method bypasses third-party
servers. With the SMTP option, you can e-mail the reports. Contact Rapid7 Technical Support to inquire about
this option before attempting to use it.
Type a message to send with the logs. The message may refer to scan errors, a support case, or a report of
aberrant system behavior.
Click the Send Logs button.
Running NeXpose in maintenance mode

Maintenance mode is a startup mode in which NeXpose performs general maintenance tasks and recovers from
critical failures of one or more of its subsystems. During maintenance mode, you cannot run scans or reports.
Available functions include logging, the database, and the NeXpose Security Console Web interface.
NOTE: Only NeXpose global administrators are permitted to run NeXpose in maintenance mode.
When NeXpose is running in maintenance mode, you see the page /admin/maintenance/index.html
upon logging in. This page shows all available maintenance tasks and indicates the current status of the task
that NeXpose is performing. You cannot select a new task until NeXpose completes the current task.
Afterward, you can switch tasks or click the Restart button to boot NeXpose back into normal operating
mode.
NOTE: NeXpose automatically runs in maintenance mode when a critical internal error occurs.
Click the Administration tab.

On the Administration page, click the Maintenance link.
The console displays the NeXpose Maintenance Mode page.
Running a database migration

You can migrate NeXpose data between different embedded databases. NeXpose supports PostgreSQL. Running a
database migration will cause NeXpose to shutdown and reboot into maintenance mode.

Go to the NeXpose Maintenance Mode—Database Migration page, and click the Start Migration button.
Addressing NeXpose failure during startup

If a subsystem critical error occurs during NeXpose startup, then NeXpose will attempt to queue an appropriate
maintenance task to respond to that failure. Afterward, it restarts in maintenance mode.
If you are a NeXpose administrator, you can log on and examine the cause of failure. If required, you can take certain
steps to troubleshoot the issue.
Two types of recovery tasks exist in NeXpose.
• DBConfig task is triggered when NeXpose is unable to connect to the configured database. It allows you to
test the database configuration settings and save it upon success.
• NeXpose Recovery task is a general recovery task that is triggered when an unknown failure occurs during
NeXpose startup. This is very rare and happens only when one or more of the configuration files is not
found or is invalid. This task allows you to view the cause of the failure and upload support logs to a secure
log server, where they can be used for troubleshooting.
NeXpose may fail to restart in maintenance mode in case of extremely critical failures if the maintenance Web server
does not have the default port 3780 available. This may happen if there is already an instance of NeXpose running, or
if one or more of the key configuration files is invalid or missing. These files have extensions such as .nsc, .xml,
and .userdb.
Using the command prompt

The NeXpose Security Console, which runs in Windows and Linux environments, includes a standard ASCII
terminal interface. It is similar to the DOS command prompt available with Windows.
If you are a NeXpose administrator, you can use this interface to perform a number of operations in NeXpose. You
can perform many of these same operations more easily using the Web interface. Using the command line, however,
is more helpful when you are performing real-time diagnostics, because it provides an immediate view of NeXpose
processes "behind the scene."
The command line interface is accessible when the NeXpose Security Console is running. How you access it depends
whether the host computer is local or remote. If you are accessing the command line interface on a remote host
computer, the method also depends on what operating system your local computer is running on and what operating
system the NeXpose Security Console is running on.

Scenario Method
Local (Windows) When NeXpose is running, the command line window automatically appears on your desktop. All you
need to do is navigate to that window, using your Windows task bar. A cursor blinks at the beginning of
the bottom line in the window. You can type commands immediately.
Local (Linux) Start a console screen session if one is not already in progress.
Remote (Windows to Use the Windows Remote Desktop program to navigate to, and log into, the remote computer desktop.
Windows) Then, navigate to the command line window as you would on a local computer.
Remote (Windows to Use a Linux environment emulation program for Windows, such as Cygwin, to navigate to, and log into,
Linux) the remote computer.
Remote (Linux to Log onto the remote NeXpose Security Console using SSH. Then, start a console screen session.
Linux)
Remote (Linux to Use a Windows environment emulation program for Linux, such as X (www.x.org (http://www.x.org)) to
Windows) navigate to, and log into, the remote computer desktop. Then, navigate to the command line window as
you would on a local computer running Windows.
If you are running Windows as a service, you can access NeXpose Security Console diagnostic functions on separate
Web-based interface. To access this interface on your browser, type the URL computer that is hosting the console,
followed by the path /admin/diag_console.html.
Example: https://127.0.0.1:3780//admin/diag_console.html
If you are running the NeXpose Security Console on an appliance, you can perform all operations using the
appliance's LCD or via the console Web interface.
For more information on using the appliance LCD, see the NeXpose Console and Scan Engine Appliance Quick-start
Guide and the NeXpose Scan Engine Appliance Quick-start Guide, which you can download from the Support page of
NeXpose Help.
A list of available commands follows. Text in square brackets indicates optional parameters, as explained in the action
descriptions.

Command Action
activate Activate NeXpose with a product key provided by Rapid7.
database diagnostics Check the database for inconsistencies like multiple entries for a device.
[show] diag[nostics] Display diagnostic information about the NeXpose Security Console.
exit Stop the NeXpose Security Console gracefully.
garbagecollect Start the garbage collector, a Java application that frees up drive space no longer used to
store data objects.
get property [name] View the value assigned to a parameter associated with the NeXpose scan engine.
Example: get property os.version. The console would return:
os.version=5.1. If you type get property without a parameter name, the
console will list all properties and associated values. You can view and set certain
properties, such as the IP socket number, which NeXpose uses for communication
between the NeXpose Security Console and the NeXpose Scan Engine. Other properties
are for system use only; you may view them but not set them.
heap dump "Dump," or list, all the data and memory addresses "piled up" by the Java garbage
collector.
help Display all available console commands.
license request from- E-mail a request to Rapid7 for a new NeXpose server license. The email-address
email-address [mail- parameter is your address as the requestor. The optional mail-relay-server
relay-server] parameter designates an internally accessible mail server to which the NeXpose server
should connect to send the e-mail. After you execute this command, NeXpose displays a
message that the e-mail has been sent. When Rapid7 sends you the license file, store it in
the nsc/licenses directory without modifying its contents. Licenses have a .lic
suffix.
log rotate Compress and save the current log. After you run this command, NeXpose automatically
creates a new log.
ping host-address [tcp- Ping the specified host using an ICNMP ECHO request, ICP ACK packet, and TCP SYN
port] packet. The default TCP port is 80.
quit Stop the NeXpose Security Console.
restart Stop the NeXpose Security Console and then start it again.
[show] scan configs Show all defined scan configurations.
[show] schedule Display the currently scheduled scan jobs.
send support [from-email- Send logs generated by the NeXpose Security Console and NeXpose Scan Engine(s) to
address] [mail-relay- Rapid7 for troubleshooting support. By default, NeXpose sends the request to the
server] [message-body] Rapid7 log server via HTTPS. Alternatively, you can e-mail the request to Rapid7 by
specifying a sender's e-mail address or outbound mail relay server . You also can type a
brief message with the e-mail request. When you execute the command, the console
displays a scrolling list of log data, including scheduled scans, auto-updates, and
diagnostics.
server diagnostics Display diagnostic information that may be useful for debugging or simply monitoring
NeXpose.
show activations Show pending rule activations for running scans.
show licenses Display information about all the NeXpose licenses currently in use. Multiple NeXpose
licenses may operate at once.

Command Action
show locked accounts List all user accounts locked out by the console. NeXpose can lock out a user who
attempts too many logons with an incorrect password.
show mem List statistics about operating system and application memory use.
[show] threads Display a list of active threads that NeXpose is currently using. This command can be
useful for debugging the NeXpose system.
traceroute host-address Determine the IP route between your local host and the host name or address that you
specify in the command. When you execute this command, the console displays a
scrolling list of IP addresses of all "stops," or devices, on the given route.
unlock account <name> Reset the number of failed logon attempts for a locked-out user, allowing that user to
attempt to log on again.
update now Check for updates manually and immediately, instead of waiting for auto-update
retrieve the next update.
update engines Send pending updates to all defined scan engines.
[ver] version Display the current software version and license numbers of the NeXpose Security
Console and local NeXpose Scan Engine and the date of last successful auto-update.

Troubleshooting
This chapter provides descriptions of problems commonly encountered when using NeXpose and guidance for
dealing with them. If you do need to contact Rapid7 Technical Support, this guide will help you gather the
information that Support needs to assist you.
Addressing NeXpose failure during startup

If a subsystem critical error occurs during NeXpose startup, then NeXpose will attempt to queue an appropriate
maintenance task to respond to that failure. Afterward, it restarts in maintenance mode.
If you are a NeXpose administrator, you can log on and examine the cause of failure. If required, you can take certain
steps to troubleshoot the issue.
Two types of recovery tasks exist in NeXpose.
• DBConfig task is triggered when NeXpose is unable to connect to the configured database. It allows you to
test the database configuration settings and save it upon success.
• NeXpose Recovery task is a general recovery task that is triggered when an unknown failure occurs during
NeXpose startup. This is very rare and happens only when one or more of the configuration files is not
found or is invalid. This task allows you to view the cause of the failure and upload support logs to a secure
log server, where they can be used for troubleshooting.
NeXpose may fail to restart in maintenance mode in case of extremely critical failures if the maintenance Web server
does not have the default port 3780 available. This may happen if there is already an instance of NeXpose running, or
if one or more of the key configuration files is invalid or missing. These files have extensions such as .nsc, .xml,
and .userdb.
Resetting account lockout

When a user attempts to log on to NeXpose too many times with an incorrect password, NeXpose locks out the user
until the lockout is reset for that user.
The default lockout threshold is 4 attempts. A global administrator can change this parameter on the NeXpose
Security Console Configuration—Web Server page. See Changing the console Web server default settings (on page 87).
You can reset the lockout using one of three methods.
If you're a global administrator, go to the Users page, and click the padlock icon that appears next to the
locked out user's name.
Run the console command unlock account. See Using the command prompt (on page 95).
Restart the NeXpose console. This is the only method that will work if the locked out user is the only global
administrator in your organization.

Long or hanging scans
Occasionally, a scan will take an unusually long time, or appear to have completely stopped.
It is not possible to predict exactly how long a scan should take. Scan times vary depending on factors such as the
number of target assets and the thoroughness or complexity of the scan template. However, you can observe whether
a scan is taking an exceptionally long time to complete by comparing the scan time to that of previous scans.
In general, if a scan runs longer than eight hours on a single host, or 48 hours on a given site, it is advisable to check
for certain problems.
Scan memory issues

Scans can be slow, or can fail, due to memory issues. See Out-of-memory issues (on page 101).
Scan complexity
For every target host that it discovers, NeXpose scans its ports before running any vulnerability checks. The range of
target ports is a configurable scan template setting. Scan times increase in proportion to the number of ports scanned.
In particular, scans of UDP ports can be slow, since NeXpose, by default, sends no more than two UDP packets per
second in order to avoid triggering the ICMP rate-limiting mechanisms that are built into TCP/IP stacks for most
network devices.
To increase scan speed, consider configuring the scan to only examine well-known ports, or specific ports that are
known to host relevant services. See Working with scan templates and tuning scan performance (on page 47).
Scan engine offline

If the scan engine goes off line during the scan, the scan will appear to hang. When a scan engine goes off line
during the scan, the database will need to remove data from the incomplete scan. This process leaves messages
similar to the following the scan log:
DBConsistenc3/10/09 12:05 PM: Inconsistency discovered for dispatched scan ID 410,
removing partially imported scan results...
If an engine goes offline, restart it. Then, go the Scan Engine Configuration wizard to confirm that the engine is
active. See Setting up NeXpose Scan Engines (on page 30).
Viewing the scan log

To view the activity log of a scan that is in progress or complete, click the View scan log button. The console
displays the scan log.
Click your browser's Back button to return to the Scan Progress page.
Scan stopped by a user

If another user stops a scan, the scan will appear to have hung. To determine if this is the case, examine the log for a
message similar to the following:
Nexpose 3/16/09 7:22 PM: Scan [] stopped: "maylor" <>
See Viewing the scan log (on page 100).

Long or hanging reports
Occasionally, report generation will take an unusually long time, or appear to have completely stopped. You can find
reporting errors in the NeXpose Security Console logs.
Reporting memory issues

Report generation can be slow, or can fail, due to memory issues. See Out-of-memory issues (on page 101).
Stale scan data

Database speed affects reporting speed. Over time, data from old scans will accumulate in the database. This causes
the database to slow down.
If you find that reporting has become slow, look in the Security Console logs for reporting tasks whose durations are
inconsistent with other reporting tasks, as in the following example:
nsc.log.0:ReportManage1/5/09 3:00 AM: Report task serviceVulnStatistics finished in 2
hours 1 minute 23 seconds
nsc.log.0:ReportManage1/5/09 3:00 AM: Report task initBaselineDatapts finished in 0
seconds
You can often increase report generation speed by cleaning up the NeXpose database. Regular database maintenance
removes leftover scan data and host information. See Viewing the scan log (on page 100). Also see Backing up and
restoring NeXpose (on page 92).
Out-of-memory issues
Scanning and reporting are memory-intensive tasks, so errors related to these activities may often be memory issues.
You can control memory use by changing settings. Some memory issues are related how system resources are
controlled.
Memory Protection
By default, the NeXpose process auto-stop feature pauses in-progress scans and reports, or prevents them from
starting, to protect the server from crashing if it is running low on free memory. If scans or reports are hanging, check
to see if this feature is enabled. You can disable it; however, be aware that low memory can cause the server to fail. It
is preferable to determine and correct the source of the low-memory issue.
To access the auto-stop feature:
1. Click the Manage link next to NeXpose Security Console on the Administration page.
2. Go to the General page in the NeXpose Security Console Configuration wizard.
3. Select or clear the check box labeled Enable process auto-stop.
java.lang.OutofMemoryError
If the process auto-stop feature is not enabled, excessive scan engine or console activity can cause NeXpose to run out
of memory and crash. If NeXpose has crashed, you can verify that the crash was due to lack of memory by checking
the log files for the following message:

java.lang.OutOfMemoryError: Java heap space
If you see this message, contact Rapid7 Technical Support. Do not restart NeXpose unless directed to do so.
Fixing memory problems

Since scanning is memory-intensive and occurs frequently, it is important to control how much memory scans use so
that memory issues do not, in turn, affect scan performance. There are a number of strategies for ensuring that
memory limits do not affect scans.
Reduce scan complexity

As the number of target hosts increases, so does the amount of memory needed to store scan information. If the hosts
being scanned have an excessive number of vulnerabilities, scans could hang due to memory shortages. To reduce the
complexity of a given scan, try a couple of approaches:
• Reduce the number of target hosts by excluding IP addresses in your site configuration.
• Reduce the number of target vulnerabilities by excluding lower-priority checks from your scan template.
After patching any vulnerabilities uncovered by one NeXpose scan, add the excluded IP addresses or vulnerabilities to
the scan configuration, and run the scan again.
For more information see Working with sites (on page 26) and Working with scan templates and tuning scan performance
(on page 47).
Reduce Scan Count

Running several simultaneous scans can cause the NeXpose Security Console to run out of memory. Reduce the
number of simultaneous scans to conserve memory.
Upgrade Hosts
If scans are consistently running out of memory, consider adding more memory to the servers. In order to add
additional memory, it might be necessary to upgrade the server operating system as well. NeXpose, when running on
a 64-bit operating system, can address more memory than when it runs on a 32-bit operating system. However,
NeXpose requires 8 Gb of memory to run on a 64-bit operating system.
More information on managing scan-related resources

See the following chapters for more detailed information on making scans more memory-friendly:
• Planning a NeXpose deployment (on page 12)
• Working with scan templates and tuning scan performance (on page 47)
Update failures
Occasionally, NeXpose system updates will be unsuccessful. You can find out why by examining the system logs.
Corrupt update table

NeXpose keeps track of previously-applied updates in an update table. If the update table becomes corrupt, NeXpose
will not know which updates need to be downloaded and applied. If NeXpose cannot install updates due to a corrupt
update table, the Scan Console log will contain messages similar to the following:

AutoUpdateJo3/12/09 5:17 AM: NSC update failed: com.rapid7.updater.UpdateException:
java.io.EOFException
at com.rapid7.updater.UpdatePackageProcessor.getUpdateTable(Unknown Source)
at com.rapid7.updater.UpdatePackageProcessor.getUpdates(Unknown Source)
at com.rapid7.nexpose.nsc.U.execute(Unknown Source)
at com.rapid7.scheduler.Scheduler$_A.run(Unknown Source)
If this occurs, contact Rapid7 Support. See Viewing the scan log (on page 100).
Interrupted update
By default, NeXpose automatically downloads and installs updates. NeXpose may download an update, but its
installation attempt may be unsuccessful. You can find out if this happened by looking at the Scan Console log.
Check for update time stamps that demonstrate long periods of inactivity:
AU-BE37EE72A11/3/08 5:56 PM: updating file: nsc/htroot/help/html/757.htm
NSC 11/3/08 9:57 PM: Logging initialized (system time zone is SystemV/PST8PDT)
You can use the update now command prompt to re-attempt the update manually:
1. Click the Administrative tab to go to the Administration page.
2. Go to the diag_console page, where you can run command prompts: In the navigation bar, replace
index.html with diag_console.html.
https://[console_url]:3780/admin/diag_console.html
3. In the text box enter the command update now, and click Execute. NeXpose displays a message to indicate
whether the update attempt was successful.
Corrupt File
If NeXpose cannot perform an update due to a corrupt file, the Scan Console log will contain messages similar to the
following:
AU-892F7C6793/7/09 1:19 AM: Applying update id 919518342
AU-892F7C6793/7/09 1:19 AM: error in opening zip file
AutoUpdateJo3/7/09 1:19 AM: NSC update failed: com.rapid7.updater.UpdateException:
java.util.zip.ZipException: error in opening zip file
at com.rapid7.updater.UpdatePackageProcessor.B(Unknown Source)
at com.rapid7.nexpose.nsc.U.execute(Unknown Source)
at com.rapid7.scheduler.Scheduler$_A.run(Unknown Source)
If the update fails due to a corrupt file, it means that the update file was successfully downloaded, but was invalid. If
this occurs, contact Rapid7 Support.

Interrupted Update
If a connection between the NeXpose Security Console and the update server cannot be made, it will appear in the
logs with a message similar to the following:
AU-A7F0FF3623/10/09 4:53 PM: downloading update: 919518342
AutoUpdateJo3/10/09 4:54 PM: NSC update failed: java.net.SocketTimeoutException
The java.net.SocketTimeoutException is a sign that a connection cannot be made to the update server. If the
connection has been interrupted, other updates prior to the failure will have been successful.
You can use the update now command prompt to re-attempt the update manually. See Interrupted update (on page
103). Also see Viewing the scan log (on page 100).

Appendix A: Using regular
expressions
A regular expression, also known as a "regex," is a text string used for searching for a piece of information or a
message that an application will display in a given situation. Regex notation patterns can include letters, numbers,
and special characters, such as dots, question marks, plus signs, parentheses, and asterisks. These patterns instruct a
search application not only what string to search for, but how to search for it.
Regular expressions are useful in configuring NeXpose scan activities:
• searching for file names on local drives; see Configuring NeXpose to search for files on target systems (on page
69)
• searching for certain results of logon attempts to Telnet servers; see Configuring NeXpose to scan Telnet servers
(on page 76)
• determining if a logon attempt to a Web server is successful; see How NeXpose uses regular expressions when
logging on to a Web site (on page 106)
One of these is the Stanford University regex syntax page (http://nlp.stanford.edu/nlp/javadoc/gnu-regexp-
docs/syntax.html).
General notes about creating a regex

A regex can be be a simple pattern consisting of characters for which you want to find a direct match. For example,
the pattern nap matches character combinations in strings only when exactly the characters n, a, and p occur together
and in that exact sequence. A search on this pattern would return matches with strings such as snap and synapse. In
both cases the match is with the substring nap. There is no match in the string an aperture because it does not contain
the substring nap.
When a search requires a result other than a direct match, such as one or more n's or white space, the pattern requires
special characters. For example, the pattern ab*c matches any character combination in which a single a is followed by
0 or more bs and then immediately followed by c. The asterisk indicates 0 or more occurrences of the preceding
character. In the string cbbabbbbcdebc, the pattern matches the substring abbbbc.
The asterisk is one example of how you can use a special character to modify a search. You can create various types of
search parameters using other single and combined special characters.
How the NeXpose file name search works with regex

NeXpose searches for matching files by comparing the search string against the entire directory path and file name.
See Configuring NeXpose to search for files on target systems (on page 69). Files and directories appear in the results table
if they have any greedy matches against the search pattern. If you don't include regex anchors, such ^ and $, the
search can result in multiple matches. Refer to the following examples to further understand how the search
algorithm works with regular expressions. Note that the search matches are in bold typeface.

With search pattern .*xls
• the following search input,
C$/Documents and Settings/user/My Documents/patientData.xls
results in one match:
C$/Documents and Settings/user/My Documents/patientData.doc
results in no matches
C$/Documents and Settings/user/My Documents/xls/patientData.xls
C$/Documents and Settings/user/My Documents/xls/patientData.doc
With search pattern^.*xls$
C$/Documents and Settings/user/My Documents/patientData.doc
How NeXpose uses regular expressions when logging on to

a Web site
When NeXpose makes a successful attempt to log on to a Web application, the Web server returns an HTML page
that a user typically sees after a successful logon. If the NeXpose logon attempt fails, the Web server returns an
HTML page with a failure message, such as "Invalid password."
Configuring NeXpose to log on to a Web application with an HTML form or HTTP headers involves specifying a
regex for the failure message. During the logon process, Nexpose attempts to match the regex against the HTML
page with the failure message. If there is a match, NeXpose recognizes that the attempt failed. It then displays a
failure notification in the scan logs and in the NeXpose Security Console Web interface. If there is no match,
NeXpose recognizes that the attempt was successful and proceeds with the scan.

Appendix B: Using NeXpose Exploit
Exposure
With NeXpose Exploit ExposureTM, You can now use NeXpose to target specific vulnerabilities for exploits using the
Metasploit exploit framework. Verifying vulnerabilities through exploits helps you to focus remediation tasks on the
most critical gaps in security.
For each discovered vulnerability, NeXpose indicates whether there is an associated exploit and the required skill level
for that exploit. If a Metasploit exploit is available, NeXpose displays the TM
icon and a link to a
Metasploit module that provides detailed exploit information. For more information, see Viewing active
vulnerabilities in the NeXpose User's Guide.
Why exploit your own vulnerabilities?

On a logistical level, exploits can provide critical access to operating systems, services, and applications for penetration
testing.
DEFINITION: An exploit consists of software, data, or commands that provide access to a target system by taking advantage of a vulnerability
within that system. Attackers can use exploits to gain unauthorized control of target systems or to execute malicious code on them.
Penetration testers typically use exploits to verify vulnerabilities.
Also, exploits can afford better visibility into network security, which has important implications for different
stakeholders within your organization:
• Penetration testers and security consultants use exploits as compelling proof that security flaws truly exist in
a given environment, eliminating any question of a false positive. Also, the data they collect during exploits
can provide a great deal of insight into the seriousness of the vulnerabilities.
• Senior managers demand accurate security data that they can act on with confidence. False positives can
cause them to allocate security resources where they are not needed. On the other hand, if they refrain from
taking action on reported vulnerabilities, they may expose the organization to serious breaches. Managers
also want metrics to help them determine whether or not security consultants and vulnerability management
tools are good investments.
• NeXpose system administrators who view vulnerability data for remediation purposes want to be able to
verify vulnerabilities quickly. Exploits provide the fastest proof.

Appendix C: SCAP compliance in
NeXpose
NeXpose complies with Security Content Automation Protocol (SCAP) criteria for an Unauthenticated Scanner
product. SCAP is a collection of standards for expressing and manipulating security data in standardized ways. It is
mandated by the U.S. government and maintained by the National Institute of Standards and Technology (NIST).
This appendix provides information about how NeXpose implements SCAP standards for an Unauthenticated
Scanner:
• The Common Platform Enumeration (CPE) naming scheme, based on the generic syntax for Uniform
Resource Identifiers (URI), is a method for identifying operating systems and software applications.
• The Common Vulnerabilities and Exposures (CVE) standard prescribes how the product should identify
vulnerabilities, making it easier for security products to exchange vulnerability data.
• The Common Vulnerability Scoring System (CVSS) is an open frame work for calculating vulnerability risk
scores.
How NeXpose implements CPE

During scans, NeXpose utilizes its fingerprinting technology to recognize target platforms and applications. After
completing scans and populating its scan database with newly acquired data, NeXpose applies Common Platform
Enumeration (CPE) names to fingerprinted platforms and applications whenever corresponding CPE names are
available.
Within the NeXpose database, CPE names are continually updated in keeping with changes to the National Institute
of Standards (NIST) CPE dictionary. With every revision to the dictionary, NeXpose maps new available CPE
names to application descriptions that previously did not have CPE names.
NeXpose displays CPE names in scan data tables in the NeXpose Security Console Web interface. Users can view
these names in listings of assets, software, and operating systems, as well as on pages for specific assets. CPE names
also appear in NeXpose reports in the Raw XML format.
How NeXpose implements CVE

When NeXpose populates its scan database with discovered vulnerabilities, it applies Common Vulnerabilities and
Exposures (CVE) identifiers to these vulnerabilities whenever these identifiers are available.
You can view CVE identifiers on vulnerability detail pages in the NeXpose Security Console Web interface. Each
listed identifier is a hypertext link to the CVE online database at nvd.nist.gov, where you can find additional relevant
information and links.

You can search for vulnerabilities in the NeXpose interface by using CVE identifiers as search criteria.
CVE identifiers also appear in the Discovered Vulnerabilities sections of NeXpose reports.
NeXpose uses the most up-to-date CVE listing from the CVE mailing list and changelog. Since NeXpose always
uses the most up-to-date CVE listing, it does not have to list CVE version numbers. NeXpose updates its
vulnerability definitions every six hours through a subscription service that maintains existing definitions and links
and adds new ones continuously.
How NeXpose implements CVSS

For every vulnerability that it discovers, the NeXpose product computes a Common Vulnerability Scoring System
(CVSS) Version 2 score. In the NeXpose Security Console Web interface, each vulnerability is listed with its CVSS
score. Customers use this score, severity rankings, and risk scores based on either temporal or weighted scoring
models—depending on their configuration preference—to prioritize vulnerability remediation tasks.
NeXpose incorporates the CVSS score in the PCI Audit Report, which provides detailed Payment Card Industry
(PCI) compliance results. Each discovered vulnerability is ranked according to its CVSS score. Rapid7 is an
Approved Scanning Vendor (ASV); and NeXpose is a Payment Card Industry (PCI)-sanctioned tool for conducting
compliance audits. The CVSS score is also the primary factor in determining whether a given device is compliant
with PCI standards.
NeXpose also includes the CVSS score in report sections that appear in various report templates. The Highest Risk
Vulnerability Details section lists highest risk vulnerabilities and includes their categories, risk scores, and their CVSS
scores. The Index of Vulnerabilities section includes the severity level and CVSS rating for each vulnerability.
The PCI Vulnerability Details section contains in-depth information about each vulnerability included in a PCI
Audit report. It quantifies the vulnerability according to its severity level and its CVSS rating.
Where to find SCAP update information in NeXpose

NeXpose automatically includes SCAP content with each software update. You can view SCAP update information
on the SCAP page, which you can access from the Administration page in NeXpose Security Console Web-based
interface. This page lists dates for when SCAP content was most recently imported into NeXpose software. Three
tables appear on the SCAP page:
• CPE Data
• CVE Data
• CVSS Data
Each table lists a date for the most recent update as well as the "generated" date. The latter is the date on which the
original dictionary for CVE/CVSS and CPE was generated.

Configuring NeXpose to scan CVS servers • 75
Configuring NeXpose to scan database servers • 74
Configuring NeXpose to scan DHCP servers • 76
Configuring NeXpose to scan mail servers • 75
Index Configuring NeXpose to scan Telnet servers • 76,

105
Configuring NeXpose to scan Web servers • 75
Configuring NeXpose to search for files on target
systems • 69, 105
A Configuring NeXpose to test for AS/400 policy
compliance • 74
A deployment plan for Example, Inc. • 24 Configuring NeXpose to test for CIFS/SMB account
About this guide • 6 policy compliance • 73
ACLs • 21 Configuring NeXpose to test for Lotus Domino
Adding assets to a group • 84 policy compliance • 73
Addressing NeXpose failure during startup • 95, 99 Configuring NeXpose to test for Oracle policy
Analyzing four sample templates for • 53 compliance • 72
Appendix A Configuring NeXpose to test for Unix policy
Using regular expressions • 45, 46, 70, 76, 105 compliance • 74
Appendix B Configuring NeXpose to test for Windows Group
Using NeXpose Exploit Exposure • 107 Policy compliance • 73
Appendix C Configuring service discovery • 63, 65
SCAP compliance in NeXpose • 108 Configuring spam relaying settings • 72
Asset discovery methods • 54 Configuring vulnerability check settings • 67, 76
Asset discovery performance • 55 Configuring Web spidering • 70
Assigning a role and permissions to a user • 82 Contacting Technical Support • 7
B Corrupt File • 103
Corrupt update table • 102
Backing up and restoring NeXpose • 11, 92, 101 Create a scan schedule • 30
Backing up NeXpose data • 92 Creating a logon for Web site form authentication •
C 45
Creating a logon for Web site session authentication
Changing default scan engine settings • 31, 90 with HTTP headers • 45, 46
Changing default settings for NeXpose logging • 90 Creating roles and defining roles and permissions •
Changing net.ipv4.neigh.default.gc_thresh3 setting 79
• 77
Changing scan engine deployment • 78 D
Changing the console Web server default settings • Define your goals for NeXpose • 14
87, 99 Define your goals for tuning • 47
Choose a grouping principle • 26 Determine • 16, 18
Choose a scan template • 29 Disaster recovery considerations • 11
Configuring and tuning the NeXpose Security Distribute scan engines strategically • 11, 15, 20, 22,
Console host • 8 26, 49, 54, 61, 78
Configuring auto-update settings • 88 Do you need to alter templates or just alter-nate
Configuring device discovery • 63 them? • 59
Configuring general asset group attributes • 84 Document conventions • 7
Configuring general information for a new scan Don't limit security to compliance • 14
engine • 31
Configuring general scan attributes • 63, 67 E
Configuring general user account attributes • 82 Editing site configuration • 78
Configuring host memory for optimal performance • Enabling the console to use the scan engine • 31
9 Ensuring complete coverage with the fixed-number
Configuring NeXpose for maximum performance in IP address license • 18
an enterprise environment • 8

Entering a new product key or requesting a new key J
• 91
java.lang.OutofMemoryError • 101
Establishing scan credentials • 32, 43, 72, 73, 77
Excluding specific devices from scans in all possible K
sites • 86
Keep the • 47, 48
Exhaustive • 53
Know your business case to know your goals • 15
F
L
Factor in 64 bits • 22
Linux expertise is essential • 9
Fine-tuning
Long or hanging reports • 101
What can you turn up or down? • 59, 60
Long or hanging scans • 100
Fine-tuning asset discovery • 61
Fine-tuning service discovery • 61 M
Fine-tuning thread use • 54, 60
Fine-tuning vulnerability checks • 62 Maintaining and tuning the NeXpose database • 10
Fine-tuning Web site scanning • 62 Making your environment • 54, 78
Fine-tuning Web spidering • 62 Managing and creating asset groups • 84
Firewalls, IDS, IPS, and NAT devices • 21 Managing and creating user accounts • 14, 82
Fixing memory problems • 102 Managing and maintaining NeXpose • 85
Full audit • 53 Managing global settings • 33, 85
Managing NeXpose Security Console settings • 87
G Managing the HTTPS certificate • 87
Managing users and asset groups • 17, 26, 79
General notes about creating a regex • 105
Map roles to your organization • 81
Giving a user access to asset groups • 83
Maximum scan thread use • 50, 53
Giving a user access to specific sites • 83
Memory Protection • 101
Global administrator • 14, 79
Mid-size company with some remote locations • 23
Global enterprise with multiple, large remote
Modifying and creating scan templates • 33, 63
locations • 23
More information on managing scan-related
Grouping options for Example, Inc. • 27
resources • 102
H
N
How big is your enterprise? • 15
NeXpose is • 13
How is your network segmented? • 15
Nonadministrative user • 14, 79, 81
How long does scanning take? • 50
How NeXpose implements CPE • 108 O
How NeXpose implements CVE • 108
How NeXpose implements CVSS • 109 One possible environment
How NeXpose uses regular expressions when Other documents and Help • 6
logging on to a Web site • 105, 106 Other template settings • 59
How the NeXpose file name search works with regex Other tuning options • 77
• 105 Out-of-memory issues • 100, 101
I P
Important notes on backup and restore • 92 Paranoia can be time consuming • 81

Increasing accuracy • 50 Payment Card Industry (PCI) audit • 53
Increasing NeXpose resources • 78 Performing database maintenance • 93
Increasing resource availability • 51, 78 Perimeter networks (DMZs) • 21
Increasing time availability • 49 Planning a NeXpose deployment • 12, 102
Installation scenarios—which one are you? • 23 Ports that NeXpose scans to discover services • 56,
Interrupted update • 103, 104 58
Interrupted Update • 104 Ports that NeXpose uses for asset discovery • 55
IP Fingerprinting • 56 Q
Quick tuning

What can you turn off? • 60 Understanding NeXpose components • 12
Understanding roles in NeXpose • 79, 83
R
Understanding scan engine-omics • 22, 30
Reassigning existing sites to the new scan engine • Understanding sites and asset groups • 13
32 Understanding user roles and permissions in
Reduce scan complexity • 102 NeXpose • 14
Reduce Scan Count • 102 Understanding what NeXpose does • 12
Reporting memory issues • 101 Update failures • 102
Resetting account lockout • 99 Upgrade Hosts • 102
Restoring NeXpose data • 93 Using asset groups to your advantage • 83
Revision history • 5 Using default and customized credential checking •
Running a database migration • 94 76
Running NeXpose diagnostics • 93 Using external sources for user authentication • 82,
Running NeXpose in maintenance mode • 92, 93, 94 88
Using HTML forms and HTTP headers to
S
authenticate NeXpose on Web sites • 44
Scan complexity • 100 Using sites to your advantage • 26
Scan engine offline • 100 Using the command prompt • 31, 88, 95, 99
Scan engine scaling • 11
V
Scan memory issues • 100
Scan stopped by a user • 100 View your network inside-out
Scan volume drives resource requirements • 8, 10 hosted vs. distributed engines • 18
Security manager • 14, 79, 80 Viewing console database information • 90
See your network with hacker • 18 Viewing general configuration settings • 87
Selecting a console host for an enterprise Viewing the scan log • 100, 101, 103, 104
deployment • 9 VPNs • 21
Selecting a model for calculating risk scores • 85 Vulnerability checks • 59
Selecting diagnostic routines • 93, 94
W
Sending scan logs • 93, 94
Service discovery performance • 57, 61 WANs and remote asset locations • 22
Setting up alerts • 32, 42 Web audit • 53
Setting up an optimal RAID array • 10 What are the • 17
Setting up NeXpose and getting started • 23 What are your resources? • 17
Setting up NeXpose scan engines • 24, 30, 100 What exactly are the security risks to your
Setting up sites and scans • 17, 31, 32 organization? • 17
Site administrator • 14, 79, 80 What is saved and restored • 92
Small business, internal network • 23 What is the geography of your enterprise? • 15
Specifying assets to scan • 32 What is your asset inventory? • 16
Specifying general site information • 32, 85 Where to find SCAP update information in NeXpose
Specifying scan settings • 32, 33, 91 • 109
Stale scan data • 101 Where to put the security console • 23
Subnetworks • 21 Who is your security team? • 17
System administrator • 14, 79, 81 Who should read this guide • 6
Why exploit your own vulnerabilities? • 107
T
Working with scan templates and tuning scan
Templates are best practices • 52 performance • 11, 47, 100, 102
The primary tuning tool Working with sites • 22, 26, 102
the scan template • 51
Y
Troubleshooting • 99
You need more accurate scan data • 48
U
You need NeXpose to finish scanning more quickly •
Understand NeXpose key concepts • 12 47
Understanding configurable phases of scanning • 52 You need to reduce consumption of network or
Understanding deployment options • 23 system resources • 48

Your deployment checklist • 25, 30

NeXpose Admin Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

NeXpose Admin Guide

Uploaded by

Copyright:

Available Formats

NeXpose

Revision history ....................................................................................................................................................... 5

NeXpose Administrator's Guide 1

NeXpose Administrator's Guide 2

NeXpose Administrator's Guide 3

NeXpose Administrator's Guide 4

Revision Date Version Description

June 15, 2010 1.0 Created document.

NeXpose Administrator's Guide 5

Who should read this guide

Other documents and Help

NeXpose Administrator's Guide 6

Contacting Technical Support

NeXpose Administrator's Guide 7

Configuring and tuning the NeXpose Security Console host

Scan volume drives resource requirements

NeXpose Administrator's Guide 8

Linux expertise is essential

Configuring host memory for optimal performance

NeXpose Administrator's Guide 9

Setting up an optimal RAID array

Maintaining and tuning the NeXpose database

NeXpose Administrator's Guide 10

Scan engine scaling

Disaster recovery considerations

NeXpose Administrator's Guide 11

Understand NeXpose key concepts

Understanding what NeXpose does

Understanding NeXpose components

NeXpose Administrator's Guide 12

Understanding sites and asset groups

NeXpose Administrator's Guide 13

Understanding user roles and permissions in NeXpose

Define your goals for NeXpose

Don't limit security to compliance

NeXpose Administrator's Guide 14

Know your business case to know your goals

How big is your enterprise?

What is the geography of your enterprise?

How is your network segmented?

NeXpose Administrator's Guide 15

One possible environment: "Example, Inc."

Network segment Address space # of assets Location Asset functions

New York Sales 10.1.0.0/22 254 Building 1: Work stations

New York IT/Administration 10.1.10.0/23 50 Building 2: Work stations

New York printers 10.1.20.0/24 56 Buildings 1 & 2 Printers

New York DMZ 172.16.0.0/22 30 Co-location facility Web server

Madrid sales 10.2.0.0/22 65 Building 3: Work stations

Madrid development 10.2.10.0/23 130 Building 3: Work stations

Madrid printers 10.2.20.0/24 35 Building 3: Printers

Madrid DMZ 172.16.10.0/24 15 Building 3: File server

NeXpose Administrator's Guide 16

What are your resources?

What exactly are the security risks to your organization?

Who is your security team?

NeXpose Administrator's Guide 17

Ensuring complete coverage with the fixed-number IP address license

See your network with hacker “eyes,” using scan engines

View your network inside-out: hosted vs. distributed engines

NeXpose Administrator's Guide 18

NeXpose Administrator's Guide 19

Distribute scan engines strategically

NeXpose Administrator's Guide 20

Perimeter networks (DMZs)