If you perform internal vulnerability scans, be sure that the scanning tool is configured to authenticate to the systems it is examining. Without this crucial step, your visibility into the systems’ security posture is drastically diminished. Here are a few considerations for defining the scanner’s login credentials.
Unauthenticated Vulnerability Scans
An internal vulnerability scanner can usually gather only basic details about the system without authenticating to it. They include:
- The operating system and, in some cases, its version
- Network ports open on the system
- Services listening on the ports, if these details are available without authentication using techniques such as banner-grabbing
- Data “leaked” by the services, such as the listing of open shares and users of Windows hosts that support null-user connections
This information is useful for maintaining an inventory of hosts and services, and can help spot anomalies, such as new systems or services that might introduce risks into the environment. The scanning tool may be able to use these details to identify some vulnerabilities, such as missing security patches and configuration weaknesses; however, the accuracy and thoroughness of this data will be much lower than if the scanner authenticated to the system.
Authenticated Vulnerability Scans
If you provide the scanning tool with valid login credentials, it should be able to authenticate to the scanned systems and obtain detailed information about installed applications, including configuration issues and missing security patches. As the result, authenticated scans findings are more comprehensive and have fewer false positives than anonymous scans.
The manner in which an authenticated scanner collects data differs across operating systems and scanning tools:
- The scanner might use SSH to interactively login to a Linux host to run shell-level commands that would enumerate installed packages and gather other relevant data.
- The scanner examining a Windows host will usually authenticate remotely using Windows domain or local credentials to obtain patch and configuration data from the registry and the file system.
- SNMP can be used to authenticate to network devices, if necessary.
- Scanning tools are also usually able to authenticate to databases, which might use a protocol such as SQL*Net.
For instructions necessary to configure authenticated scans consult your tool’s documentation. Representative details are available from:
- QualysGuard: Getting Started with Trusted Scanning
- Nessus Credential Checks for Unix and Windows (PDF)
Caution With Authenticated Vulnerability Scans
Most scanning tools ask you to supply root/administrator credentials for authenticated scans. This presents an element of risk. A few words of caution when configuring your scanner with login credentials for authenticated scans:
- Create an account dedicated to authenticated scanning, rather than using user accounts used for other purposes.
- Consult the tool’s documentation to see if it’s possible to define more granular account privileges, rather than granting it full administrator rights.
- Avoid authenticating using clear-text protocols, such as telnet.
- Consider man-on-the middle attacks that might expose the scanner’s login credentials. For instance, an attacker might set up an internal SSH server to which the scanner will authenticate and give up the username and password. Using key-based authentication for SSH usually mitigates this risk.
- Keep an eye on the account’s activities to make sure it’s not misused.
- Confirm that scans authenticate to all the hosts you expect the scanner to be able to login to. Don’t assume this works without validating this.
Steve Shead’s article Protecting Scanning Credentials from Malicious Insiders offers additional tips for dealing with the risks of authenticated scans.
