QualysGuard Tips and Techniques Unix Trusted Scanning

October 21, 2010

QualysGuard Trusted Scanning allows organizations to systematically audit their network infrastructure all the way down to individual IPs without the burden of deploying agents on every desktop and server. With Trusted Scanning the service has the ability to gather more system intelligence on target hosts, increasing the number of vulnerabilities detected. QualysGuard supports Trusted Scanning for Windows, MS SQL Server, Unix, Oracle and SNMP. This article describes Unix Trusted Scanning. The steps for enabling Unix Trusted Scanning are: 1. Setup SSH authentication credentials (on target hosts). 2. Add Unix authentication records. Optionally, add authentication vaults for your Cyber-Ark PIM Suite environment. 3. Enable Unix authentication in an option profile (for vulnerability scans). 4. Launch scans. 5. Verify authentication success. These steps are described below. For more information, please refer to Trusted Scanning and Unix Authentication in the QualysGuard online help.

Setup SSH Authentication Credentials

With Unix authentication, the scanning engine is able to access patch history and system configuration information for target hosts, increasing the number of vulnerabilities that may be detected during vulnerability scans. When the compliance module is enabled, users with compliance privileges can launch compliance scans to identify whether hosts are compliant with user-defined policies. Successful authentication to target hosts is required for compliance scans. In this case, Unix authentication must be performed with superuser (root) privileges. When supplying Unix authentication credentials, you must include a user account to be used by the scanning engine to log into target hosts. You may also supply a password for the user account, an RSA private key, and a DSA private key. When authenticating to target hosts that support SSH2, authentication is attempted in the following order: 1) RSA key, 2) DSA key and 3) password. For target hosts that only support SSH1, only the supplied user name and password are used for authentication.

Copyright 2005-2010 by Qualys, Inc. All Rights Reserved.

Account Requirements
Vulnerability Scanning

For vulnerability scanning, the user account provided for authentication must be able at a minimum to execute these commands:

The account must be able to execute uname in order to detect the platform for packages. If the target is running Red Hat, the account must be able to read /etc/redhat-release and execute rpm. If the target is running Debian, the account must be able to read /etc/debian-version and execute dpkg.

The service sends many more commands than those listed above to perform information gathering and vulnerability assessment. The specific commands used vary over time as the vulnerability signatures and scanning engine are updated, and improvements are made to the service. Contact our Support team for a list of commands used during authenticated scanning.
Compliance Scanning

For compliance scanning, the user account provided for authentication must have superuser (root) privileges (or lower privileges if Sudo is enabled). If root privileges are not provided or if authentication to hosts fails, then no controls can be evaluated for the host and no compliance data can be collected for the host. If authentication to a host is successful, then the host can be evaluated for compliance.

Using Basic Authentication

Basic authentication (user name and password) is supported for SSH1 and SSH2. For basic authentication to be successful, the user account must be added to all target hosts. The corresponding user name and password must be supplied in an authentication record.

Using Key Authentication

Key authentication is supported for SSH2 only. The service supports RSA and DSA keys generated with any version of OpenSSH that supports SSH protocol version 2 (SSH2). The private keys must be PEM-encoded (the standard for OpenSSH), and must not be encrypted with a passphrase, meaning that the passphrase is empty. For key authentication to be successful, the user account must be added to all target hosts along with the public key, which will be appended to the .ssh/authorized_keys2 file in the users home directory. The private key is supplied in an authentication record along with the user name and password. Important! The scanning engine must have full access to the target hosts during scanning in order to perform security assessments. It is possible that manually added options in .ssh/authorized_keys2 files (like no-pty) lockout the scanning engine so security tests cannot be performed. Before you begin, ensure that the scanning engine has full, unrestricted access to the target hosts. If you are troubleshooting the reason why a scan did not return expected results, it is recommended that you remove the additional, manually added options from the scanning accounts public key in the .ssh/authorized_keys2 files and scan the target hosts again to confirm whether the scanning engine can authenticate to hosts and perform scanning.

QualysGuard Tips and Techniques

Working with Keys

Generate an SSH Key Pair Using OpenSSH For SSH key authentication, the service supports private RSA and DSA keys generated with any version of OpenSSH that supports SSH protocol version 2 (SSH2). The private key must be PEM-encoded and must not be encrypted with a passphrase, meaning that the passphrase is empty. To generate an OpenSSH Key Pair using SSH: 1. Login to any system with a supported version of OpenSSH. 2. Enter the following key generation command and then press Enter. $ ssh-keygen t type Where type is either rsa or dsa, depending on the key pair type you want to generate. 3. Press Enter when prompted for the file in which to save the private key. The private portion of the key pair is saved at either $HOME/.ssh/id_rsa or $HOME/.ssh/id_dsa. The public key will be stored in the same directory with .pub appended to the file name. 4. Press Enter when prompted for a passphrase to keep the passphrase empty. The service does not currently support private keys encrypted with passphrases. 5. Press Enter to confirm the empty passphrase. Two key files are created in the (hidden) directory .ssh:

Private key (id_rsa or id_dsa) to be supplied in a Unix authentication record. Public key (id_rsa.pub or id_dsa.pub) to be distributed to all target hosts to be scanned.

Distribute your Public Key The public key (id_rsa.pub or id_dsa.pub) needs to be installed on each target host to be scanned. Do this by appending the contents of the public key file to the .ssh/authorized_keys2 file on each target host, in the home directory of the user for whom the key was created. To distribute the public key to target hosts: 1. From the system where the key pair was generated, copy the public key to each target host. You can use the SSH secure copy (SCP) program for this by entering the following: $ scp public_key username@targethost:. Where public_key is either id_rsa.pub or id_dsa.pub. For example, you might enter: $ scp id_rsa.pub scanner@test.mycompany.com:. Enter your user account password when prompted. Login to each target host as the user created for the purpose of authentication. Enter your user account password when prompted. Enter the following commands: $ mkdir .ssh $ chmod 700 .ssh $ cat public_key >> .ssh/authorized_keys2 $ rm public_key Where public_key is either id_rsa.pub or id_dsa.pub.

2. 3. 4. 5.

QualysGuard Tips and Techniques

If the authorized_keys2 file already exists, the contents of the public key will be appended to it. If the authorized_keys2 file does not already exist, it will be created and the public key will be appended. Its recommended that you check file permissions for authorized_keys2 to ensure that the file is world-readable and owner-writable. See instructions below. To verify permissions for the authorized_keys2 file: 1. Use the chmod utility to set permissions by entering the following command: $ chmod 644 .ssh/authorized_keys2 2. Verify permissions by entering the following command: $ ls -l .ssh/authorized_keys2 3. The file permissions should show up as: -rw-r--r--

Add Unix Authentication Records

At least one Unix authentication record is required for Unix Trusted Scanning. Unix authentication records contain Unix authentication credentials and the target hosts that those credentials apply to. You must supply a user name to be used by the scanning engine to log into target hosts. Optionally, you may also supply an RSA and/or DSA private key. When authenticating to target hosts that support SSH2, authentication is attempted in the following order: 1) RSA key, 2) DSA key and 3) user name and password. For target hosts that only support SSH1, only the supplied user name and password are used for authentication. User Permissions: Managers can create and edit authentication records for all hosts in the subscription. Unit Managers who are granted the extended permission Create/edit authentication records/vaults in their account in order for them to manage authentication records and vaults. When this permission is granted, Unit Managers can create records for IPs in their business unit, and edit records when at least one IP in the record is in their business unit. Managers may grant any Unit Manager this permission; a Unit Manager who has this permission in their own account may grant this permission to another Unit Manager in the same business unit. Important: When a Unit Manager edits a record, the Unit Manager only sees the IPs in the record that they have permission to. Any changes made by the Unit Manager to the record settings will apply to all IPs defined in the record, regardless of whether all IPs belong to the user's business unit. The record may contain more IPs that are not visible to the Unit Manager. To create a Unix authentication record: 1. Select Authentication Records from the left menu, under Tools. 2. Go to NewUnix Record. 3. In the Title field, enter a descriptive name for this record. 4. On the Login Credentials tab, enter the Unix login credentials to be used for authentication to the target hosts. These additional options are available: Enable Sudo, Clear Text Password, Use Authentication Vault.

QualysGuard Tips and Techniques

5. (optional) In the Policy Compliance section, identify custom ports to scan for authentication and compliance assessment. By default, these well known ports are scanned: 22 (SSH), 23 (telnet) and 513 (rlogin). If services (SSH, telnet, rlogin) are not running on these well known ports for the hosts you will be scanning, then you must define a custom ports list. 6. On the IPs tab, select all hosts that the scanning engine should log into with the specified credentials. If key authentication is used, each of the target hosts must contain the corresponding public key or authentication will fail. Each IP may be included in one Unix record. 7. (optional) In the Comments section, enter notes about the account, credentials or both. 8. Click Save. Enable Sudo Sudo (superuser do) allows a system administrator to give certain users the ability to run some (or all) commands as root. A Sudo option is available for Unix authentication. When this option enabled and properly configured, the scanning engine can log in to target hosts using a lower-privileged user account and perform scan tests with the elevated privileges of the superuser (root). This enables the scanning engine to perform more in depth analysis without requiring that you provide the root account and password in the authentication record. The scanning engine 1) authenticates to target hosts using the login credentials provided in the record (user name and password, RSA key or DSA key) and then 2) executes Sudo to perform scan tests with root authority. Note that if a password is required to execute Sudo on target hosts then you must include the user name and password in the authentication record. Note that Sudo is not a standard part of all Unix distributions. If its not included as part of the default installation for your Unix distribution, then you can download it from http://www.sudo.ws
Sudoers Configuration File

The configuration file /etc/sudoers specifies which users can run which commands and on which machines. The user account provided in the Unix authentication record must be properly configured in the sudoers file to have access to commands that require root privileges. Add /bin/su to the sudoers file to allow the user to execute /bin/su in order to gain elevated privileges. One method for setting this up in your sudoers file is to create a command alias for the /bin/su command and then grant the privilege to run this command to the user account. See an example of this below: # Cmnd alias specification Cmnd_Alias SU=/bin/su # User privilege specification root ALL=(ALL) ALL scanuser ALL=SU Where scanuser is the user account that you provide in the Unix authentication record. See the sudoers manual for information on configuration options and proper syntax for the version you have installed. If you configure the sudoers file without the NOPASSWD option, meaning that a password is required to run Sudo, then you must include the user name and password in the Unix authentication record. If you do not include the user name and password, then the scanning engine will not be able to execute Sudo to perform scan tests as root. In this case, you can also provide an RSA and/or DSA key for the initial authentication to the target hosts.
QualysGuard Tips and Techniques 5

If you configure the sudoers file with the NOPASSWD option, meaning that a password is not required to run Sudo, then a password is not required in the Unix authentication record. You must still provide credentials for the initial authentication. Clear Text Password A Clear Text Password option is available in your Unix authentication record. Select this option to allow your password to be transmitted in clear text when connecting to services which do not support strong password encryption. The service uses supplied credentials for remote access to different command line services such as SSH, telnet and rlogin. When the Clear Text Password option is cleared (the default), the scanning engine only uses strong password encryption for remote login. Note that this setting may prevent the scanning engine from detecting some vulnerabilities on hosts which do not support strong password encryption. When the Clear Text Password option is selected, the scanning engine uses strong password encryption for remote login, if possible, and falls back to transmitting credentials with weak encryption or in clear text for services which do not support strong password encryption. If these credentials are intercepted by a malicious person, then they may be used to completely compromise a host for attack and theft of information. It is recommended that you replace unsecured services, such as telnet and rlogin, with a secured SSH service. If you must operate unsecured command line services, it is recommended that you operate them within a secured tunnel like SSL/TLS or VPN. Use Authentication Vault The service supports use of Cyber-Ark PIM Suite for authentication to hosts for both vulnerability scans and compliance scans. If the password for the Unix user account to be used for authentication is stored in your Cyber-Ark PIM Suite environment, then you must 1) define an authentication vault configuration within your account (see Add Authentication Vaults in the next section), and 2) enable use of the authentication vault in your Unix authentication record. To enable use of the authentication vault in your Unix record, select the option Use Authentication Vault and provide the following details: the user name for the system user account to be used for authentication, the title of the authentication vault defined in your account, and the name of the folder and file in the safe containing the account password.

Add Authentication Vaults

An authentication vault is a user-defined configuration that gives the service access to login credentials stored in your Cyber-Ark PIM Suite environment for authenticated scanning. Customer Requirements: Cyber-Ark PIM Suite. Please contact Cyber-Ark Software to confirm that your Cyber-Ark PIM Suite license permits integration with our security service. User Permissions: Managers can create and edit authentication vault configurations. Unit Managers must be granted the extended permission "Create/edit authentication records/vaults" in their user account in order for them to manage authentication vault configurations. When this permission is granted, Unit Managers can create authentication vaults, and edit their own authentication vaults.

QualysGuard Tips and Techniques

To create an authentication vault: 1. Select Authentication Vaults from the left menu, under Tools. 2. Go to NewCyber-Ark PIM Suite. 3. Under Vault Title, enter a title for this authentication vault. Each vault title must be unique within the subscription. (You will need to reference this title in your Unix authentication record.) 4. Under Login Credentials enter the following information for your existing Cyber-Ark PIM Suite environment: IP address and port for the vault server, name of the secure digital safe within the vault containing the login credentials to be used by the service, and the user name and password for the vault user account. 5. (optional) In the Comments section, enter notes to be saved with the authentication vault. 6. Click Save.

Enable Unix Authentication in an Option Profile

For vulnerability scans, authentication is performed only when enabled in the option profile applied to the scan task. Create a new option profile or edit an existing option profile and select the Unix option under Authentication. Note that authentication is automatically enabled in compliance profiles for all authentication types because successful authentication is required for compliance scans. To enable Unix authentication in an option profile: 1. Select Option Profiles from the left menu, under Tools. 2. Create a new option profile (NewOption Profile) or edit an existing option profile. 3. Click the Advanced button to see all available options. 4. On the Scan tab, scroll down to the Authentication section, and select the Unix check box. 5. Click Save.

Launch Scans
After completing the setup steps described above, you are ready to see the impact of Unix Trusted Scanning. Simply run a scan and apply an option profile with Unix authentication enabled. Review your scan results and then compare the results to scans run without Trusted Scanning. You should see that the authenticated scan provides much greater vulnerability information. To launch a vulnerability scan with Unix authentication: 1. Select Scan from the left menu. 2. Go to NewScanVulnerability. 3. In the Option Profile menu, select an option profile with Unix authentication enabled. 4. In the Target Hosts section, enter the asset groups and/or individual IPs that you want to scan. The target hosts should already be included in your Unix authentication record.

QualysGuard Tips and Techniques

5. Click Launch. Launching a compliance scan is similar to launching a vulnerability scan. In Step 2, go to NewScanCompliance. Then select a compliance profile to apply to the scan task, enter the target hosts you want to scan, and click Launch. Note that authentication is automatically enabled in all compliance profiles for all authentication types. After launching scans, verify that authentication was successful. It is recommended that you resolve authentication failures before the next scan.

Verify Authentication Success

Verify Authentication: Vulnerability Scans The service provides information in vulnerability scan results about whether authentication was successful. By viewing scan results, you can verify that authentication occurred on the target hosts defined in your authentication records.
Report Summary

The report summary displays the number of successful and failed authentication attempts for each authentication type enabled in the option profile applied to the scan task.
Authentication Status QIDs

The service returns certain information gathered QIDs in vulnerability scan results that provide information about Unix authentication status. Depending on the authentication success, one of the following QIDs is returned: QID 38307 Unix Authentication Method. Authentication was successfully performed for the host. The Results section includes a list of authentication records used and the credentials associated with each record. QID 105053 Unix Authentication Failed. Authentication was enabled for the host, but login attempts using the credentials defined in the authentication records failed. Verify that the login credentials specified in the authentication record are valid for the host. QID 105297 Unix Authentication Not Attempted. Authentication was enabled for the host, but not performed because the host's IP address was not included in any authentication records.
Scan Report Appendix

The scan report appendix provides additional information related to authentication. When authentication is enabled, the appendix lists hosts with successful authentication and failed authentication for each authentication type. The appendix also lists the scan options so you can verify the types of authentication enabled in the option profile applied to the scan task. Verify Authentication: Compliance Scans A policy compliance report called Authentication Report is available to identify whether authentication to hosts was successful for the most recent compliance scans. Note that this report is only available when the compliance module is enabled for your subscription and you have compliance management privileges.

QualysGuard Tips and Techniques

The Authentication Report identifies the authentication status (Passed, Failed or Passed with insufficient privileges) for each compliance scanned host. If the scanning engine was able to successfully authenticate to a host, then the status Passed appears. If the scanning engine was not able to authenticate to a host, then the status Failed appears. If the scanning engine was able to authenticate to a host but there were insufficient privileges to perform posture evaluation, then the status Passed* appears.

QualysGuard Tips and Techniques