Very often, Nessus is used by MSPs, consultants and IT security staff to test the security of an Internet facing server. Occasionally, we see the default settings of Nessus, which are optimized for a credentialed internal LAN audit, used to audit an external server. Although this usually results in a majority of the vulnerabilties being identified, Nessus can be configured to work a bit harder for these types of scans. This blog entry details some different strategies and scan settings that can be used to perform a more complete audit of an Internet facing server.
Nessus Scanner Settings
When scanning a few external hosts, we do not envision the scanning process to impact your system's performance. However, if you do encounter issues, consider the following. The scan settings we will be enabling will cause Nessus to work much harder than it does during a typical LAN or default scan. If the system running Nessus is not a dedicated system (such as a consultant's laptop), you should consider configuring it to have less impact on the underlying operating system. Otherwise, the system may become unresponsive during the audit. On UNIX, the "be_nice" setting should be set to "yes" in the nessusd.conf file and then the nessusd process restarted. On Windows, the nessusd.exe process can have its priority lowered. For this blog entry, I had several heavier scans running at the same time from my local Nessus scanner and had no noticeable impact to my operating system.
If the audit is taking place over a slow Internet connection or a connection which is being served by a device that may be impacted by many simultaneous connections, considering reducing the "max_hosts" setting from the default of 40 to 10. This will generate less overall traffic during any given moment of an audit and also reduce the number of simultaneous checks (and connections). On the Nessus Client, this setting is available under the "Options" tab and is named "Number of Checks in Parallel".
Scan Policy Settings
Global Variable Settings
Many plugins implement more thorough audits when the "Thorough Tests (slow)" setting is enabled. These tests often implement the same logic, but try more combinations of potential security issues. This causes security audits to run longer than they normally do. For example, when looking for FTP, SMB or HTTP servers hosting potentially copy written content, this setting increases the level of recursion used to look for files. There is a slight chance of impacting a server's performance during this audit, as the server will also have to respond to more probes than during a normal scan.
Also in this section, the "Network Type" should be set to "Public WAN (Internet)". This effects some plugins which are required to choose relevant IP addresses.
Below is a screen shot of the Nessus Client implementing these settings:
|
Service Detection
By default, SSL detection is normally performed on services that are expected to support encryption such as port 443. However, for any discovered port facing the Internet, SSL service detection should be enabled. This is accomplished by changing the "Service Detection" set of options under the "Advanced" tab from the default setting of "Known SSL Ports" to "All".
If the audit is being performed remotely, this section also has a separate setting for the number of service fingerprints to be performed in parallel. This setting effects the few plugins which perform service fingerprinting and can generate many sessions at the same time. The default value for this is 10 and for the policy used in our example policy, I reduced this by half to 5.
Below is a screen shot of the Nessus Client implementing these settings:
|
Auditing CGIs
Nessus includes a plugin that can "torture" any discovered CGI or other type of interactive web document. This can uncover a wide variety of security, stability and other issues with poorly written login pages, feedback forms and other types of dynamic pages that process user content.
To enable this, under the "Advanced" tab, select the "Unknown CGIs arguments torture" and enable the "Send POSTs requests" check box.
During the audit, if a complex web site is being tested, you should discuss this type of test with the site owners ahead of time. Nessus will try a wide variety of common form exploits which can result in unexpected behavior or unanticipated system loads. Even if a web site is secure, these tests may show issues with logging failure messages (or lack thereof) and could also highlight issues with custom logging in general.
I've spoken with one customer that tried this sort of auditing and they did not have any security issues, but the error logging process involved writing to a SQL database. This surge in errors resulted in an unacceptable denial of service for the web site.
Port Scanning
Since this is an Internet facing system, no port should be left untested. A full port scan from 1 through 65535 is suggested. If you are omitting port scans for some reason, it should be noted in the final audit.
Web Mirroring
The default Nessus settings to look for web pages that may have vulnerabilities can be made more aggressive. These settings take longer to execute than a default scan, but are more likely to find a vulnerable server. The "Web Mirroring" set of scan options is available under the "Advanced" tab of the Nessus Client. The following settings are recommended:
- The default number of web pages to mirror is 200. This should be raised to something that matches the destination site being audited.
- If Nessus learns of a dynamic web page, it normally won't add this to the mirror list, unless the "Follow Dynamic Pages" option is set. Web sites that link to login screens, include feedback forms and have other types of dynamic content are often dynamically generated.
If an audited CGI or other type of dynamically generated web page is poorly written, the Nessus audit may cause a spike in the performance level of the audited server. For example, a web site may have a slow method to read content from a SQL database before rendering a login page or some type of default screen. A rapid set of web queries performed by Nessus could impact the system.
Below is a screen shot implementing these settings with the Nessus Client:
 |
Performing the Scan
Nessus 3.2 does include the ability to pause a scan. If your audit causes some unanticipated effect on the target servers, you should stop it or pause it immediately.
Tenable receives many reports from customers scanning their remote systems and having ports that were available during the start of a scan, not be available at the end of a scan. This shows up in a Nessus report like this:
System: 192.168.20.200 unknown (0/tcp)
Vulnerability: [10919] Check open ports
Severity: Informational
The following ports were open at the beginning of the scan but are now closed:
Port 80 was detected as being open but is now closed
This might be an availability problem related which might be due to the following reasons :
- The remote host is now down, either because a user turned it off during the scan
- A network outage has been experienced during the scan, and the remote
network cannot be reached from the Vulnerability Scanner any more
- This Vulnerability Scanner has been blacklisted by the system administrator
or by automatic intrusion detection/prevention systems which have detected the
vulnerability assessment.
In any case, the audit of the remote host might be incomplete and may need to
be done again
If an Intrusion Prevention System (IPS) or Unified Threat Manager (UTM) devices is configured between you and the target host, it may detect some of your activity after the scan has started and then block further testing. This can cause an incomplete audit. In these situations, it's important not to speculate. Finding out how the IPS is detecting the scan is important because it is also part of the system being audited. For example, if it is only configured to block hosts that perform a port scan, it may not stop a host or worm trying one SQL injection attack. The point is to provide an accurate assessment so the customer or management does not put their faith in something that might not be reflective of other threats.
For More Information
We have blogged several times in the past about configuring Nessus for optimum scanning:
