While Nessus is a widely common scanning platform, there are a few best practices to consider when completing your scan without error or oversight.
RedLegg has extensive experience in vulnerability scanning using the Nessus platform, and during our use of the software, we have discovered several scenarios that have caused issues with our scans. (These issues can be caused by a variety of configurations and deployments.)
We’ll talk about the issues we have encountered, indicators of these issues, and our resolutions.
What is Nessus, and how do you use it?
Used by security administrators, penetration testers, and network administrators to diagnose weaknesses and points of potential vulnerability, Nessus is a widely used platform for vulnerability scanning and assessment.
RedLegg uses the data created by Nessus to examine a target’s network and make plans for intrusion. Data is then exported and parsed into a custom database that allows for quick analysis of potential vulnerabilities. Once a target list has been provided, the administrator can configure scans using the Nessus web application, while more ‘under-the-hood’ adjustments can be made using a command line interface included in the software.
RedLegg uses the Advanced Network Scan as a template for all scans. This template allows for customization of the scan through the web GUI and allows the administrator control over aspects of the scan, including plugins and modules used, port listings, CRL checking, and many other options. The GUI is the easiest place to configure the scan for a new user.
Common Issues With Nessus
RedLegg has encountered several configurations that have caused issues with scans. These issues could be every port being open, or zero ports open on host that is known to be accessible. Sensitive networks can become congested and give false positives, bad results, and have impact on production networks. Network issues can be mitigated beforehand by communicating with the client on the network load of sensitive equipment, high priority hosts, and high availability hosts. Legacy hardware, such as printers, can cause similar “denial of service” conditions.
Many of these issues have options in Nessus for quick configuration changes while the scan is running, allowing the user to fix potential issues on the fly.
During our scanning efforts against targeted hosts, we have seen Nessus report every port as open, usually when scanning a target list that is for a web application.
These results can be caused by a firewall or content delivery network (CDN) accepting connections on all ports and then forwarding that traffic based on access control rules. When using this against an external target list, the issue is usually caused by a CDN or another web-based target. However, when used against an internal target set, this issue can arise from scanning a VMWare-based client.
To mitigate this, under Discovery in an Advanced Scan, turn off “Ping the remote host.” This will stop the scanning host from using ICMP to determine if a host is live, allowing the scan to continue. ICMP may be passed through a firewall and will return an “ICMP Unreachable” message1. This is a false positive in Nessus by saturating the results of the scan with thousands of informational findings.
Sensitive networks can also prove to be troublesome. In many of Tradecraft Labs engagements, we have been tasked to examine a development or staging environment. While many issues do not progress beyond simple IP whitelisting and access control, some can cause network congestion.
Rate limiting is useful when congestion issues occur. Options for rate limiting a scan are under Advanced > Performance Options. Adjust the “Max Concurrent Checks Per Host” if the target is a web application or service that may be under a heavy load. Adjusting this option will limit the number of plugins simultaneously scanning the host.
When testing high-availability networks such as production VPNs, OWA, and other internet-based systems, rate limiting can be used to hide Nessus traffic as well as limit impact on production. Using the “Max TCP Sessions per Host” can help obfuscate traffic by limiting the number of incidents and logs that a defender has to investigate. The number entered will be multiplied by 10 to get the number of SYN packets that will be sent per second2.
Using Nessus to scan legacy hardware can cause problems as well. Legacy printers have been known to receive malformed packets from scanning software such as Nessus and nmap which will spool the printer, making it print blank pages. Other sensitive devices include remote terminal units (RTUs) and programmable logic controllers (PLCs) which could cause malfunctions with industrial equipment.
The default option for this is set to “Disabled.” Keeping this option set is usually enough to avoid sensitive equipment. However, on some cases, Tradecraft Labs has used configuration files to blacklist hosts. Nessus web GUI does not have an option for blacklisting of hosts within a given range, and all targets given must be ranges or in CIDR notation. The instructions for creating the nessusd.rules file can be found on the Tenable Community pages3.
Nessus For Your Internal Team
We’ve walked through common scenarios that RedLegg and Tradecraft Labs have discovered throughout testing for a variety of targeted environments:
- CDNs and firewalls can cause Nessus to report every port being open or closed, depending on the firewall response. Properly configure the Nessus appliance by turning off “Ping the Remote Host.” Disabling this function will disable ICMP packets being sent through the firewall.
- Network congestion can be managed through the Performance options. Limiting the number of concurrent plugins scanning a target, as well as concurrent TCP sessions, can reduce load on a production server or help obscure packets being sent to the host.
- Finally, legacy and specialty devices can be accounted for by leaving the default options set to disabled. If IP blacklisting is needed, create a nessusd.rules file to exclude hosts from the scan.
Using this info may help your own internal team’s vulnerability scanning efforts. You can also view some of our general vulnerability scanning best practices here as well. If you have further questions or want a vulnerability scan completed for your environment, reach out.