Nessus Scanning Through Firewalls
A number of factors can inhibit a successful Nessus scan: busy systems, congested networks, hosts with large amounts of listening services and legacy systems with poor performance all contribute to scan failure(s). However, firewalls (or other types of filtering devices) are one of the major causes of slow or inaccurate scans. Firewalls are essential for an organization’s perimeter protection and internal network segregation. Host-based firewalls are now common on both Linux and Windows systems. Scanners can be placed on network segments behind a firewall to avoid these problems, but this may not be feasible in your network, create extra burden moving a scanner around and is 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. There are two strategies for dealing with firewalls when using Nessus to perform internal or external vulnerability scans.
Tuning a Network Scan
The first scan strategy targets a single Linux host (Fedora Core release 5) running iptables. In this example, we do not have credentials on this system, so we must scan across the network. The first step is to configure the number of vulnerability checks to run concurrently for each host:
Since iptables is a stateful firewall, it will keep track of connections. 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. By limiting Nessus to only 5 checks at once, we can reduce the number of simultaneous connections. Another setting exists to help control the number of total sessions created for a given host, which encompasses the port scanners, service detection and vulnerability checks. The network tab of the scan configuration has the following options:
I started by setting "Maximum simultaneous TCP sessions per host" to 100, and then reduced it to 50 to get the scan running smoothly. Even with these reduced settings, I observed errors on the target host:
ip_conntrack is the iptables module that is responsible for managing sessions. When it encounters too many sessions, its connection table becomes full and it starts dropping traffic in an attempt to keep up with the onslaught of packets it is receiving. You can tune the above two settings in Nessus to be less aggressive and attempt to avoid these errors. For this example, I did not drop them down any further as the scan would have taken longer and I wanted to show an example of the iptables errors that may occur. You can also tune the portscanner to be more sensitive when it encounters a firewall:
Even with the above tuning, the scan may take anywhere from 20 to 30 minutes to complete. Despite the iptables errors, we get some good results:
Since we were scanning through a firewall, Nessus only found TCP ports 80 and 22 available. The web server was running osCommerce, and plugin 19253 was triggered, "osCommerce Unprotected Admin Directory".
Configuring a Credentialed Scan
A Nessus scan with credentials avoids most of the problems encountered with a network scan of a firewall protected host. In this example we will be scanning the same host as before, however our scan configuration will be very different. The first screen is configured with the following settings:
Since it will be scanning the target host locally, we can disable all of the network port scanner plugins. We enable the "netstat portscanner (SSH)" plugin, which will run the netstat command on the target system to get a listing of open ports. This provides far more accurate results than network port scanning in a fraction of the time. Next, go to the Credentials tab, and select "SSH settings":
A user called "nessus" has been previously created on the target host. This user does not need to have any special or elevated privileges. The system running the NessusClient will need the public and private SSH keys of the target host. Although supported, it is not recommended to use password authentication for performing SSH scans. It should be noted that the Nessus server will require SSH access to the host through the firewall. Our policy looks very different as well:
The only plugin that needs to be enabled is the "Fedora Local Security Checks". This greatly speeds up the scan, which completes in just a few minutes. The scan results are slightly different, but no less important to review:
Instead of reporting on vulnerabilities found remotely in the web server, Nessus reports a long list of missing operating system and software patches, equally as important as some of the issues found in the network-based scan. 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.
Conclusion
Nessus works great for both network scans and credentialed scanning. When scanning through firewalls it will take longer, but tuning your settings can ensure more accurate results. Scanning with credentials is the best way to get around firewalls, but offers different results. The best strategy is to perform both types of scans on a regular basis and act upon the results according to your vulnerability management plan. Nessus ProfessionalFeed customers can get more information from credentialed scanning by applying various audit files to check the operating system against industry or local standards.
