INFORMATION

Phases of a Vulnerability Scan:

Settings:

1. Scan Policy and Global Scanner Settings

Information Gathering:

1. Ping and Port Scanning
2. Port Service, Banner, and Interface Checking
3. Local Checks

Information Processing:

1. KB Reliant Checks
2. END Type Checks

DETAILS

NOTE: This article outlines the process of a Vulnerability scan primarily in Nessus. There may be additional settings in Tenable Vulnerability Management or Tenable Security Center that aren't cover in this article.

Settings:

Scan Policy and Global Scanner Settings:

• Type of scan being implemented: Basic Network Scan, Advanced Network Scan, etc.
  • The differences between a Basic Network Scan and an Advanced Network Scan are such that, the Basic Network Scan is a great policy that can be applied to virtually any host. The Advanced Network Scan, however, allows for a lot more customization to basically tailor fit a policy against a host. Specifically, there are a lot more settings that are available to customize within an Advanced Network Scan policy that are automatically set to default values in a Basic Network Scan. Also, within an Advanced scan, you have the ability to control what plugins are automatically enabled/disabled within the policy. A Basic Network Scan can be configured similarly to an Advanced Network Scan, however, that will remove the defaults which makes it safe to apply to almost any host. 
    • Please read our documentation for more information on configuration options within our policies.
• Type of scanner being used: Global Cloud Scanner vs. Local Scanner
  • The type of scanner being used depends on the purpose of your scan. If the intent of a vulnerability scan is for an internal view of your network that provides vulnerability information that exists internally (locally) on your hosts, you would use a Local Nessus scanner that's been installed on your network. A Cloud Scanner, however, is great for performing cloud-based scanning from an external view. A key example for a Cloud Scanner would be if you were conducting an External PCI scan that relied on an external perspective of your network. Our Cloud scanners do not provide an internal view into networks. 
• Examples of how Policy Configuration can affect how a scan works:
  • Paranoia - Levels 0,1, and 2 (default is 1). This setting will tell Nessus what to report on in regards to its confidence in its finding. Paranoia level 0 means to avoid displaying results that Nessus isn't completely confident in, and 2 means display all finding regardless of confidence levels. Some plugins specifically require certain Paranoia settings. You can discover which ones by filtering for that setting on our plugin website.
  • Supersedence - Enabled by default. This will include all of the plugins related to vulnerabilities that are patched through cumulative updates. It paints a more complete picture, but in most cases may not be necessary as installing the latest patch will cover the most recent version of that plugin (if this option is enabled, you will see vulnerabilities for older patches that may not really apply anymore as a result of having the latest patch).
    • Please refer to this article for more information related to Plugin Supersedence.
  • Safe Checks - Enabled by default. When this setting is on, it disables a large amount of plugins that are considered intrusive when scanning a host. Generally speaking, this is a great stress-test option for pre-production hosts vs. production hosts in which you'd want to minimize the impact of vulnerability scanning. Without safe checks, it's possible to actively test for vulnerabilities or mimic the attack of a vulnerability. With Safe Checks being enabled, certain plugin categories like ACT_DESTRUCTIVE_ATTACK, ACT_DENIAL, ACT_KILL_HOST, and ACT_FLOOD are disabled. 
    • Please refer to this article for more information related to Plugin Categories.
  • Thorough Checks - Disabled by default. This setting can enable additional checks within certain plugins. A great example for this would be Plugin 128304. Within that specific plugin, if Thorough Checks are enabled within the policy, the plugin will perform an additional step to obtain even more information. There are also quite a few plugins that rely on this setting to run. Generally speaking, this setting will force the scan to obtain more information at the cost of performance both within the scan and on the target (it becomes more intrusive).
• NOTE: If rules have been defined in the nessusd.rule configuration file, those rules will supersede anything set within the policy (ports, IP, hosts, etc) (related article).

Details: At the start of each scan, Nessus retrieves the scan settings, such as the ports to be scanned, which plugins are enabled, and which settings to apply under the policy's preferences.

Information Gathering: 

Ping Method and Port Scanning:

• Pinging the host to ensure they're alive based on the selected method(s) (i.e. ARP, TCP, ICMP, UDP).
  • Note: If a host doesn't respond to a ping request, Nessus will mark the host as dead unless otherwise specified from within the scan policy (i.e. scan hosts that don't respond to ping requests). As a default, if a host doesn't respond to a ping, it will not be scanned and will not return any results, that will be the end of the scan. 
• Externally scanning for open ports using SYN scanning (default) or UDP scanning.

Details: The first step that Nessus performs in a scan is performing host discovery by pinging each IP address or hostname in the target list. It then determines whether or not the host is live or not. Nessus utilizes ICMP, TCP, ARP, and UDP to make the determination. Afterward, Nessus begins scanning ports to determine which are open. This setting can be adjusted to determine which port from 1 to 65,535 to scan.

With Ping Disabled: The full defined port scan range will be done for every IP. If the host is dead the scan will discontinue after the attempted port scan due to no service being found.

Port Service, Banner, and Interface Checking:

• After viewing what ports are open, the scan will check what services are there.
• The scan will also attempt to interact with any Banners or Interfaces it finds to collect information for the KB.
  • Banner checks include a wide range such as HTTP, FTP, SSH, etc. These checks are performed with the intention of figuring out what service is running and perhaps what application/version. This can also yield OS information for the host.
• This portion is also where the scan will attempt to remotely identify the OS of the host. Plugin 11936 is a combined plugin that has both remote and local checks within it.
  • If credentials with the appropriate permissions are supplied, the plugin will attempt to use both components of its code. If credentials aren't supplied then only the remote portion of the plugin will fire, the rest will exit. 
  • We have a great article that expands on the remote functionality of 11936 and how it attempts to fingerprint the OS from remote checks. 

Details: After determining which ports are open, Nessus will attempt a series of banner captures and other tests on each of the open ports to detect what services are running on the targeted host. Based on the running services, Nessus will identify the operating system and run plugins that match appropriately (OS respective)

Local Checks:

• The scanner attempts to access the host locally to perform local checks (This would require credentials with the appropriate permissions to access the host locally).
• The scanner will attempt to consolidate as much local information as it can into the KB to prevent having to connect locally over and over.

Details: After the operating system has been determined, Nessus will attempt to login to the host. Afterward, it'll attempt to elevate to an administrative account (if privilege escalation is set) and check local plugins (that can only be run with an administrative account) respective to the operating system. An example of this would be Plugin 10400, which indicates that accessing the Windows Registry through supplied credentials was possible (a local check).  

Information Processing:

KB Reliant Checks:

• Our plugins analyze all the information collected in our KB from the previous steps of the scan.
  • For some background information, a Nessus KB, or rather a Knowledge Base is where Nessus stores information that our plugins gather during a vulnerability scan. A lot of plugins will utilize the KB before attempting to collect information, as a lot of the information our plugins collect is also utilized by other plugins. KBs make fewer redundant checks on a host for information already acquired by the scan (related article)

Details: After all the necessary information has been gathered, the enabled plugins that are running analyze the information collected in the Nessus' knowledge base. Generally speaking, that's the conclusion to data collecting, however, if some plugins require additional information, Nessus may reconnect to a host to perform additional scanning.

END Type Checks:

• END Type Checks are plugins that fall under the ACT_END plugin category - they are the last plugin category that are set to be executed before a vulnerability scan finishes.
• These are basically summary plugins that run after all the information has been collected (i.e. plugin 19506).

ADDITIONAL RESOURCES

Plugin Categories, Nessusd.Rules, Template Settings, Scan and Policy Templates, Plugin Database, Nessus Installation (local scanners), Local Checks on Hosts, Knowledge Base (KB)