Skip to main content

Scanning Best Practices

  • Updated

Introduction

Discovery is performed by Scan Jobs that are based on the scope of the discovery that is to be executed by an appliance.

  • Scan Type - based on the scanning objective (based on Customer Intention and Advice from CloudSphere)
  • Appliances - used to execute the Scan Job (based on Customer Deployment and Configuration)
  • Scope - the IP Addresses, Host Names, Subnet, and Range for scan targets (based on Customer Knowledge)
  • Keychains - credentials (usernames and passwords) to access targets in the discovery process (based on Customer Knowledge)
  • Exclusions -  targets that should not be scanned by the scan job (based on Customer Knowledge)
  • Execution Schedule - how often a scan operation is to be repeated (based on Customer Intention and Advice from CloudSphere)

There are a number of best practices that can be followed to have a smooth and efficient scanning of the environment. They will help in running the scans efficiently and getting the desired output sooner.  Follow this article to find out some of the best practices that can be followed while scanning.

For the purposes of this discussion, it is assumed that a single appliance has 
access to all the scan target IPs. If this is not case (i.e. an appliance only 
has access to specific subnets) then the following discussion can be considered 
as if each appliance is a separate project with the same basic rules applied.

 

Initial Scan - Established Scope/Density

  • Restrict Range Lengths: In a Scan Scope, an IP Range of up to 32k is supported. Smaller scan lengths are easier to handle, and manipulate and are less subject to scanning timeouts. This is because the scan times and load can be affected by the type of targets present within the scope. Windows targets are typically more load-intensive and slower than the *NIX servers.
  • Establish Density of “Live” machines: The purpose of an initial scan is to identify the subnets that contain “live” machines i.e. ones that respond to connection attempts. The purpose of this is to focus the majority of scanning time on live machines and continue to scan subnets that are empty as a background task. The background task ensures that machines that are typically not present are identified if they are booted up.

mceclip0.png

Approach

This initial scan is intended to provide answers to some of the questions:

  1. How many target IPs are to be scanned? This question is typically known i.e. the boundaries of the scope can be established.
  2. How many target IPs are expected to be present in the N target IPs? This may or may not be known.
  3. How many targets IP should be actively excluded in the range? This may or may not be known.

Proposed solution

  1. Create a Number (N) of Scopes with approximately 1000 IPs each e.g. if the total scope is 3000 IPs, create 3000/1000 = 3 scopes. This is only an approximate grouping and can be guided by customer knowledge about the subnets to be scanned.
    1. Provide a meaningful name for each Scope that easily represents what is contained in the Scope.
    2. A couple of examples could be: “Server Scope X.X.41.1 - X.X.45.255” or “Server Scope X.X.110.0/22”.
  2. Put vCenter scanning IP addresses in a separate scope. Since vCenter scanning is considered to be a “gold-standard” in terms of the creation of information, it is useful to keep this separate from standard scanning
  3. Execute scan jobs (either manually for a small set of scan jobs or by scheduling with a large set of scan jobs). Allow a reasonable timeout (6-8 hrs) for these initial scans as the density of each scope is unknown.
  4. Note, as we have not provided any Keychains at the moment, “scanning” of the target IP will be limited to a port-scan operation.

The results of this operation can be split into two (2) scan result types:

  • No Active IPs

  • Mixed Active IPs2024-03-01 15_52_41-CloudSphere - Discovery.png

Follow-Up Scan - Consolidation

  • Group Live Machine subnets: Accumulate subnets with “live” machines into smaller scopes for scanning. Initial scanning for a few days will provide a good picture of which IPs are alive when scanning subnets.

Approach

  1. Accumulating active subnets into smaller scopes means that less time is wasted on machines that are known to be inactive, improving the efficiency of data retrieval and ease of configuration.
  2. The original scan scopes should not be discarded but should continue to be executed to identify any machines that may become live over time. The live subnets within these scan scopes should obviously not be scanned.

Proposed solution

  1. When a “live” subnet needs to be moved from an existing scope to a new scope, a new exclusion scope should be created (or an existing exclusion scope modified) for this subnet.
  2. A new scope should be added (or an existing scope updated) to include the “live” subnet.
  3. The original scope should the modified to include the exclusion scope so that this live subnet will no longer be included in the original scan.
  4. It should be noted that a “consolidated” scope” is probably best kept below a range of 500 IPs. If the consolidation scope is likely to exceed this then split the consolidated scope and share the live subnet between the split scopes.
  5. Manually run the “live scopes”.
  6. Schedule the “dead scopes” to be run every 12 hours.

Extend Scan - Add KeyChains

  • Provide credentials for Device Scan

  • Provide credentials for Application Scans

Approach

  1. The scanning operations can now be extended by providing appropriate credentials to access Devices O/S (i.e. login credentials for Wndows or *nix boxes).
  2. The scanning operations can now be extended by providing appropriate credentials to access Applications (i.e. login credentials for vCenter, SQL Server, etc).

Proposed solution

  1. For each live machine provide a credential appropriate to accessing this target type (Windows or *Nix).
  2. Perform a manual scan to identify that new credentials provide access to all devices.
  3. For vCenter IP targets (typically defined within their own scope) provide a credential that allows access to the vCenter application.
  4. Perform a manual scan to identify that new credentials provide access to the vCenter application (information returned from a VCenter scan is considered to be a gold standard of device creation).
  5. Repeat for other application types.
  6. Perform a manual scan to identify that new credentials provide access to applications.

Extend Scan - Define Exclusions

  • Identify out-of-Scope IPs/Subnets

Approach

  1. Create an exclusion scope for targets that should not be scanned under normal circumstances.

Proposed solution

  1. Identify the IP addresses or subnets that should not be actively scanned.
  2. Create an exclusion scope that includes the target IPs.
  3. Add the exclusion scope to all existing scopes.

Review Schedule - Final scan set-up

  • To discover new servers and keep up-to-date with existing ones, it is recommended to run scan jobs at regular intervals. The scan Jobs can be scheduled to run repeatedly over specified intervals. Frequency should be based on:
    • The size of the scan scope (and the time taken to scan) e.g. a scan that takes two hours to complete should not be scheduled for a period less than that; a rule of thumb would be to schedule the scan job for 3 * scan duration e.g. if a scan job takes 2 hours to run, initially schedule for every 6 hours.
    • How often change occurs within your infrastructure (endpoints and applications) e.g. slowly changing estates should be scanned less often (e.g. non-live subnets could be scheduled every 8 hours).
  • To avoid multiple jobs queuing or waiting to scan, the scan schedules should be modified to ensure a gap between different scheduled jobs. For optimal configuration, you could calculate the length of each scan job, before setting up schedules. That way you can schedule the jobs that don’t overlap.
Was this article helpful?
0 out of 0 found this helpful
Return to top

Related articles