Credentialed Checks on Linux
Follow the steps in this document to configure Linux systems for local security checks. The SSH daemon used in the following examples is OpenSSH. If you have a commercial variant of SSH, your procedure may be slightly different.
You can enable local security checks using an SSH private/public key pair or user credentials and sudo or su access.
Tip: To view the Linux operating systems that are compatible with Tenable Nessus, see Tenable Nessus Software Requirements.
Prerequisites
Tenable Nessus supports the blowfish-cbc, aesXXX-cbc (aes128, aes192, and aes256), 3des-cbc, and aes-ctr algorithms.
Some commercial variants of SSH do not have support for the blowfish cipher, possibly for export reasons. It is also possible to configure an SSH server to accept certain types of encryption only. Check that your SSH server supports the correct algorithm.
For maximum effectiveness, the SSH user must be able to run any command on the system. On Linux systems, the SSH user must have root privileges. While it is possible to run some checks (such as patch levels) with non-privileged access, full compliance checks that audit system configuration and file permissions require root access. For this reason, Tenable recommends that you use SSH keys instead of credentials when possible.
If you use Kerberos, you must configure sshd with Kerberos support to verify the ticket with the KDC. You must properly configure reverse DNS lookups for this to work. The Kerberos interaction method must be gssapi-with-mic
.
Enable SSH Local Security Checks
This section provides a high-level procedure for enabling SSH between the systems involved in the Tenable Nessus credential checks. It is not an in-depth tutorial on SSH, and assumes the reader has the prerequisite knowledge of Linux system commands.
Generate SSH Public and Private Keys
The first step is to generate a private/public key pair for the Tenable Nessus scanner to use. You can generate this key pair from any of your Linux systems, using any user account. However, it is important that the defined Tenable Nessus user owns the keys.
To generate the key pair, use ssh-keygen and save the key in a safe place (see the following Red Hat ES 3 installation example).
# ssh-keygen -t ecdsa -b 521
Generating public/private ecdsa key pair.
Enter file in which to save the key (/home/test/.ssh/id_ecdsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/test/.ssh/id_ecdsa
Your public key has been saved in /home/test/.ssh/id_ecdsa.pub
The key fingerprint is:
SHA256:xL27sSSquFGQ2jhemuZGDdtt8lXL3nuUcOVrDIHtfi0 test@ubuntu2204-test
The key's randomart image is:
+---[ECDSA 521]---+
| o |
| . . . . o . |
| o o . . + |
| = . . . o + . |
|+ *.o S o + + o|
|.++= o . o . +E=.|
|.=. + . o = . o. |
|o. o . . + = . |
|..o.... o.o |
+----[SHA256]-----+
#
Note: If you experience SSH key compatibility issues when authenticating to an SSH server, you can generate a key using the dsa command instead of ecdsa:
ssh-keygen -t dsa
Do not transfer the private key to any system other than the one running the Tenable Nessus server. When ssh-keygen asks you for a passphrase, enter a strong passphrase or press the Return key twice (that is, do not set any passphrase). If you specify a passphrase, you must specify it in Policies > Credentials > SSH settings for Tenable Nessus to use key-based authentication.
Create a User Account and Set Up the SSH Key
On every target system that you want to scan using local security checks, create a new user account dedicated to Tenable Nessus. This user account must have exactly the same name on all systems. For this document, we call the user nessus, but you can use any name.
Once you create the user account, make sure that the account has no valid password set. On Linux systems, new user accounts are locked by default, unless you explicitly set an initial password. If you are using an account where someone had set a password, use the passwd –l command to lock the account.
You must also create the directory under this new account’s home directory to hold the public key. For this exercise, the directory is /home/nessus/.ssh. See the following Linux systems example:
# passwd –l nessus
# cd /home/nessus
# mkdir .ssh
#
For Solaris 10 systems, Sun has enhanced the passwd(1) command to distinguish between locked and non-login accounts. This is to ensure that you cannot use a locked user account to execute commands (for example, cron jobs). You can only use non-login accounts to execute commands, and they do not support an interactive login session. These accounts have the “NP” token in the password field of /etc/shadow. To set a non-login account and create the SSH public key directory in Solaris 10, run the following commands:
# passwd –N nessus
# grep nessus /etc/shadow
nessus:NP:13579::::::
# cd /export/home/nessus
# mkdir .ssh
#
Now that you have created the user account, you must transfer the key to the system, place it in the appropriate directory, and set the correct permissions.
Example
From the system containing the keys, secure-copy the public key to the system that you want to scan for host checks as shown in the following example.
# scp ssh_key.pub [email protected]:/home/nessus/.ssh/authorized_keys
#
You can also copy the file from the system on which you installed Tenable Nessus using the secure ftp command, sftp
. You must name the file on the target system authorized_keys.
Return to the Public Key System
Set the permissions on both the /home/nessus/.ssh directory and the authorized_keys file.
# chown -R nessus:nessus ~nessus/.ssh/
# chmod 0600 ~nessus/.ssh/authorized_keys
# chmod 0700 ~nessus/.ssh/
#
Repeat this process on all systems that you want to test for SSH checks (starting at Create a User Account and Set Up the SSH Key).
Test to make sure that the accounts and networks are configured correctly. Using the simple Linux command id, from the Tenable Nessus scanner, run the following command:
# ssh -i /home/test/nessus/ssh_key [email protected] id
uid=252(nessus) gid=250(tns) groups=250(tns)
#
If it successfully returns information about the Tenable Nessus user, the key exchange was successful.
What to do next:
-
Configure Tenable Nessus for SSH host-based checks.