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.
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.
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--
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.
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.
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.
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.
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.
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.