Enhanced Vulnerability Scanning (Credentialed Scanning)

Attacks against client-side software such as Adobe Flash, Adobe Acrobat Reader, Microsoft Internet Explorer, and others have increased significantly across the Internet. To help combat these threats, the UF Office of Information Security and Compliance is providing a new customizable vulnerability scanning method to authorized IT workers.

In order to determine the vulnerabilties of client-side software, privileged access is needed. Using the new method, IT workers can configure credentials that allow them to scan client-side software. Many other customizations can be configured by IT workers to refine the vulnerability scanning policy of their choice.

Note that when configuring your scan with prvileged credentials, these credentials are not revealed to the UF Office of Information Security and Compliance or any other parties – the credentials are only used for the vulnerability scanner to obtain access for the scanning session and evaluate client-side vulnerabilities..


Obtaining access to the credentialed scanner

Registration is required to use the new scanning method. To register, email ufirt@ufl.edu. Registration is not required to scan hosts without using customizations. Authorized IT workers can conduct non-customized scans using the self-service vulnerability scanner web interface.

Authorization to use either scanning method is based on the Subnet Manager’s Database maintained by the Network Services group of Computing and Networking Services. If the information about your subnet is incorrect, please request a correction submitting a request to CNS Network Services.


Instructions for using the credentialed scanner

Open a web browser and connect to the Nessus scanner user interface that you have been granted access to (either https://authorized-scanner-1.ns.ufl.edu:8834 orhttps://authorized-scanner-3.ns.ufl.edu:8834) and select the “Policies” tab.

Create a new policy or edit an existing policy (under the “Policies” menu) and select the “Credentials” tab on the left.

  • For *nix based hosts that provide SSH access, select “SSH settings” from the drop down menu at the top as shown in this image. The most effective credentialed scans are those when the supplied credentials have root privileges. Since best practice security practices do not allow remote login as root, users can invoke “su” or “sudo” with a separate password for an account that has been set up to have “su” or “sudo” privileges.
    • For the item “SSH user name”, enter the name of the account that is dedicated to Nessus on each of the scan target systems. It is set to “root” by default.
    • If you are using a password for SSH, enter it in the “SSH password” box.
    • If you are using SSH keys instead of a password (recommended), click on the “Select” button next to the box labeled “SSH public key to use” and locate the public key file on the local system.
    • For the item “SSH private key to use” click on the “Select” button and locate the private key file (that is associated with the public key above) on the local system.
    • If you are using a passphrase for the SSH key (optional), enter it in the box labeled “Passphrase for SSH key”.
    • Nessus and SecurityCenter users can additionally invoke “su” or “sudo” with the “Elevate privileges with” field and a separate password.
    • If an SSH known_hosts file is available and provided as part of the scan policy in the “SSH known_hosts file” field, Nessus will only attempt to log into hosts in this file. This can ensure that the same username and password you are using to audit your known SSH servers is not used to attempt a log into a system that may not be under your control.
  • For Windows hosts, Select “Windows credentials” from the drop down menu at the top as shown in this image. A very common mistake is to create a local account that does not have enough privileges to log on remotely and do anything useful. By default, Windows will assign new local accounts “Guest” privileges if they are logged into remotely. This prevents remote vulnerability audits from succeeding. Another common mistake is to increase the amount of access that the “Guest” users obtain. This reduces the security of your Windows server.

    The most important aspect about Windows credentials is that the account used to perform the checks should have privileges to access all required files and registry entries, and in many cases this means administrative privileges. If Nessus is not provided the credentials for an administrative account, at best it can be used to perform registry checks for the patches. While this is still a valid method to determine if a patch is installed, it is incompatible with some third party patch management tools that may neglect to set the key in the policy. If Nessus has administrative privileges, then it will actually check the version of the dynamic-link library (.dll) on the remote host, which is considerably more accurate.

    Note that for Windows Vista, Server 2008, and later, UAC must be disabled for Nessus Credentialed Scans to succeed.

External Resources:

Below are links to blog posts and how-to’s that will help you use Nessus. If you have any problems or questions, feel free to contact us a ufirt@ufl.edu or 352-273-1344.

Back to top button