Escolar Documentos
Profissional Documentos
Cultura Documentos
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
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.
• 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.
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.
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.
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.
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.
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?
Following are examples of situations that could call for the placement of a scan engine.
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
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.
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.
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.
Asset Location
10.2.0.0/22
Madrid 10.2.10.0/23 233 NeXpose Scan Engine
#1
10.2.20.0/24
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.
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.
• 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.
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).
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.
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
Maximum # scan threads: 10
ICMP (Ping hosts): Y
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
Device discovery performance: 5 ms send delay, 2 retries, 3000 ms block timeout
TCP port scan method: Stealth scan (SYN)
TCP optimizer ports: None
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
TCP port scan performance: 0 ms send delay, 25 blocks, 500 ms block delay, 3 retries
UDP ports to scan: 161, 500
Simultaneous port scans: 10
Specific vulnerability checks enabled (which disables all other checks): None
Specific vulnerability checks disabled: None
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
Maximum # scan threads: 25
ICMP (Ping hosts): Y
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
Device discovery performance: 0 ms send delay, 2 retries, 3000 ms block timeout
TCP port scan method: Stealth scan (SYN)
TCP optimizer ports: None
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
TCP port scan performance: 0 ms send delay, 25 blocks, 500 ms block delay, 3 retries
UDP ports to scan: 161, 500
Simultaneous port scans: 25
Specific vulnerability checks enabled (which disables all other checks): None
Specific vulnerability checks disabled: None
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.
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: 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)
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: None
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."
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: 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.
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: None
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.
Device/vulnerability scan: Y/Y
Maximum # scan threads: 10
ICMP (Ping hosts): N
TCP ports used for device discovery: None
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
TCP port scan performance: 0 ms send delay, 10 blocks, 10 ms block delay, 5 retries
UDP ports to scan: None
Simultaneous port scans: 5
Specific vulnerability checks enabled (which disables all other checks): DNS, database, FTP, Lotus Notes/Domino, Mail, SSH, TFTP, Telnet,
VPN, Web check categories
Specific vulnerability checks disabled: None
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.
Device/vulnerability scan: Y/Y
Maximum # scan threads: 10
ICMP (Ping hosts): Y
TCP ports used for device discovery: 22, 23
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: 22, 23
TCP port scan performance: 0 ms send delay, 10 blocks, 10 ms block delay, 5 retries
UDP ports to scan: None
Simultaneous port scans: 5
Specific vulnerability checks enabled (which disables all other checks): RPM check type
Specific vulnerability checks disabled: None
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.
Device/vulnerability scan: Y/Y
Maximum # scan threads: 10
ICMP (Ping hosts): Y
TCP ports used for device discovery: 135, 139, 445, 1433, 2400
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: 135, 139, 445, 1433, 2433
TCP port scan performance: 0 ms send delay, 10 blocks, 10 ms block delay, 5 retries
UDP ports to scan: None
Simultaneous port scans: 5
Specific vulnerability checks enabled (which disables all other checks): Microsoft hotfix check type
Specific vulnerability checks disabled: None
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.
Device/vulnerability scan: Y/Y
Maximum # scan threads: 10
ICMP (Ping hosts): Y
TCP ports used for device discovery: 22, 23, 25, 80, 443
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: All possible (1-65535)
TCP port scan performance: 1 ms send delay, 5 blocks, 15 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: Policy check types
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.
Device/vulnerability scan: Y/Y
Maximum # scan threads: 10
ICMP (Ping hosts): Y
TCP ports used for device discovery: 21, 22, 23, 25, 80, 443, 8080
UDP ports used for device discovery: None
Device discovery performance: 5 ms send delay, 4 retries, 1000 ms block timeout
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: 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
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.
Device/vulnerability scan: Y/Y
Maximum # scan threads: 10
ICMP (Ping hosts): Y
TCP ports used for device discovery: 21, 22, 23, 25, 80, 443, 8080
UDP ports used for device discovery: None
Device discovery performance: 5 ms send delay, 4 retries, 1000 ms block timeout
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: 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
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.
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
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.
Device/vulnerability scan: Y/Y
Maximum # scan threads: 5
ICMP (Ping hosts): Y
TCP ports used for device discovery: None
UDP ports used for device discovery: None
Device discovery performance: 10 ms send delay, 3 retries, 2000 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: 10 ms send delay, 10 blocks, 10 ms block delay, 4 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: Policy check typeTCP 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: None
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.
Device/vulnerability scan: Y/Y
Maximum # scan threads: 10
ICMP (Ping hosts): N
TCP ports used for device discovery: None
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
TCP port scan performance: 0 ms send delay, 10 blocks, 10 ms block delay, 5 retries
UDP ports to scan: None
Simultaneous port scans: 5
Specific vulnerability checks enabled (which disables all other checks): Web category check
Specific vulnerability checks disabled: None
Setting up alerts
You can set up alerts for certain scan events:
• a scan starting
• a scan stopping
• a scan failing to conclude successfully
Go to the Credentials page, and click New Login. The console displays a New Login box.
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.
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.
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.
• 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.
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.
• 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.
Scan times
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.
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.
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.
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.
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).
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.
Exhaustive 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.
Template TCP ports used for service discovery UDP ports used for service discovery
Exhaustive 80 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.
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.
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
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.
Template TCP port scan send TCP port scan TCP port scan TCP port TCP connect
delay block size block delay scan retries scan timeout
Exhaustive 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.
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.
Full audit 5
Exhaustive 5
PCI audit 5
Web audit 5
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.
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.
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.
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.
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:
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.
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.
To save the new scan template, click the Save button, which appears on every page of the wizard.
RPM 27686
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.
To save the new scan template, click the Save button, which appears on every page of the wizard.
Click the Save button. The console displays the new search criteria on the File Searching page.
To save the new scan template, click the Save button, which appears on every page of the wizard.
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.
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.
To save the new scan template, click the Save button, which appears on every page of the wizard.
To save the new scan template, click the Save button, which appears on every page of the wizard.
To save the new scan template, click the Save button, which appears on every page of the wizard.
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.
To save the new scan template, click the Save button, which appears on every page of the wizard.
AS/400 DB2
SSH Oracle
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.
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:
sysctl -w net.ipv4.neigh.default.gc_thresh2=8192
sysctl -w net.ipv4.neigh.default.gc_thresh1=4096
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
net.ipv4.neigh.default.gc_thresh2=8192
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
Security manager
The security manager role provides the ability to perform a subset of NeXpose functions related to sites, asset groups,
scans, and reports:
• view data about discovered assets
• enter a site description and risk factor in the configuration settings for each accessible site
• 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
• create, modify, and run reports
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.
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:
• view data about discovered assets
• create, modify, and run 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.
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.
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).
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
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.
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.
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.
Paste it in the text box and click the Import button. Then, click Done.
To save the new console information, click the Save button, which appears on every page of the wizard.
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
authentication source.
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.
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.
To save the new console information, click the Save button, which appears on every page of the wizard.
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.
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.
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.
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.
database diagnostics Check the database for inconsistencies like multiple entries for a device.
[show] diag[nostics] Display diagnostic information about the NeXpose Security Console.
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.
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.
restart Stop the NeXpose Security Console and then start it again.
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 licenses Display information about all the NeXpose licenses currently in use. Multiple NeXpose
licenses may operate at once.
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.
[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.
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).
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:
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.
Update failures
Occasionally, NeXpose system updates will be unsuccessful. You can find out why by examining the system logs.
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.
See Viewing the scan log (on page 100).
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.updater.UpdatePackageProcessor.getUpdates(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 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.
See Viewing the scan log (on page 100).
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.
I P