Establishing the right configurations and settings can improve Nessus scan results when scanning through firewalls.
Of all the factors that can inhibit a successful Nessus scan — busy systems, congested networks, legacy systems, hosts with large amounts of listening services — firewalls (and other types of filtering devices) are one of the major causes of slow or inaccurate scans. Network-based firewalls are essential for an organization’s perimeter protection and internal network segregation, while host-based firewalls are common on both Linux and Windows systems.
Scanners can sometimes be placed on network segments behind a firewall to avoid these problems, but this may not be feasible in all situations, creating an extra burden when moving a scanner around. This approach is also ineffective against host-based firewalls: Even if you allow the scanner's IP address through the firewall, connection tracking and stateful inspection can interfere with the scan and negatively impact performance on the firewall.
In a typical modern environment, it’s unlikely that these configurations will be needed. However, organizations often have older equipment or infrastructure lying around which may require modifications to compensate for these types of devices. Or, if you’re required to run a full port scan against your environment for auditing purposes, understanding the potential impact that could occur is key. Read on to learn about multiple strategies you can use to deal with firewalls when using Nessus to perform internal or external vulnerability scans.
Tuning a network scan
The first approach is to configure the number of vulnerability checks to run concurrently for each host. These controls are located under the “Advanced” policy setting in Nessus:
The default for this setting is 4 or 5, depending on the scan policy used. This is reasonable for most systems; however, systems connected over low-bandwidth links, older systems, or ones with less robust networking stacks may benefit from setting this to 2 or even 1. Note: As with most of the configuration changes detailed in this post, lowering the number of simultaneous checks per host can increase your scan times, sometimes significantly.
Most modern host firewalls are stateful, thus, they keep track of the connections made to them. If Nessus makes too many connections at once, the firewall may become overwhelmed and drop connections, causing the scan to miss open ports and/or vulnerabilities or causing the target to experience issues with other connections. By limiting Nessus to only 1 or 2 checks at a time, we can reduce the number of simultaneous connections per host, as well as the resources on the target taken by responding to the scanner’s queries.
Other settings, such as the maximum number of concurrent TCP sessions per host or per scan, can help control the number of total sessions created for a given host, which encompasses service detection and vulnerability checks. These can be helpful when extremely fine granularity is required, especially with older network infrastructure. Note: These settings do not directly impact the default SYN port scanner as its TCP session control.
Tuning the port scanner
You can also tune the port scanner to be more sensitive when it encounters a firewall, by adjusting the “Discovery - Port Scanning” setting of the scan policy:
It may also be beneficial to review which port scanner your policy is using. While the SYN scanner is the default, and works well in most situations, it can cause connections to be “left open” in the state table of the firewalls you’re scanning through. The TCP scanner will attempt a full 3-way handshake, including closing the connection. This can entail more overall target and network overhead, but can be useful in situations where your network firewall can’t be upgraded or re-configured to support a larger state table or decrease the timeout.
Impact of full port scanning on a network firewall
Some users may need to perform full port scanning for network audit purposes. If the scanning traffic will pass through a network firewall, please make sure you plan carefully and monitor the session and resource utilization of your infrastructure.
For example, if we are assessing 30 hosts simultaneously, the potential half-open sessions that will be generated is 30 times 65,535, or the maximum number of TCP ports on a single host; this equates to 1.96 million sessions. Additionally, some of the network firewalls maintain state on both the ingress and egress interface, resulting in the requirement to maintain 3.9 million sessions in its state table.
As a mitigation, Tenable recommends configuring the network firewall with a more aggressive timeout for dropping half-open sessions or reducing the number of hosts that are scanned simultaneously. If these are not sufficient, the number of SYN packets sent by the scanner can be controlled by editing the "nessus_syn_scanner.global_throughput.max" configuration in the Nessus scanner advanced settings. Please contact your Tenable representative for additional guidance on scanner placement if this is a requirement.
Configuring a credentialed scan
A Nessus scan with credentials avoids most of the problems encountered with a network scan of a firewall-protected host because it uses local port enumeration versus externally trying thousands of different ports to see what’s open. Local port scanners are enabled by default, and will run as long as Nessus can successfully authenticate to the target.
We also get much more accurate port scan results, as it provides a complete list of open TCP and UDP ports in a fraction of the time. For more information on how to configure credentialed checks for Windows versus Linux, you can visit our Nessus documentation page.
Conclusion
Nessus works great for both unauthenticated network scans and credentialed assessments. Although scanning through firewalls may take longer, tuning your settings can ensure safer, more accurate results. And to further improve accuracy, scanning with credentials is the best way to reduce the load and assess through firewalls.
Lastly, you can explore our enterprise solutions to address this challenge. Within Tenable.io and Tenable.sc, Nessus Agents provides visibility into hard-to-scan endpoints, and Nessus Network Monitor provides a continuous view of managed and unmanaged assets on your network. Tenable.ot is also available for further visibility across operational technology environments.