This is the third installment in our three-part series exploring how to use Tenable products to protect credentials used for network assessments. Here, we focus on ’nix style systems: Linux, Unix and macOS.
In part 1 of our three-part series, I covered general best practices for protecting credentials when performing network assessments. In part 2, I provided specific guidance for Windows systems. In this third and final post in the series, I take a look at protecting credentials authenticating against ’nix hosts (by ’nix, we mean Linux, Unix, and macOS), specifically focused on SSH.
Please note that enabling some of these controls may have other effects on your network and systems. Before you implement any of these changes, you should test all settings thoroughly to determine if they are appropriate for your environment. Not all organizations will be able to implement all these settings. When configuring account(s) for use in credentialed scanning, below are some key considerations unique to ’nix hosts.
5 tips for credentialed scanning of ‘nix hosts
- Securely configure SSH.
There are more than a dozen different configuration changes you can make to an SSH server to make it more secure. We won’t go into them all here, but a great place to start is to take a look at the recent benchmarks from CIS for your target operating system. Some, like Ubuntu and CentOS, have specific SSH sections that should be reviewed in their entirety. You can also use Nessus to check many of these specific configurations.
- Use least privilege functionality to limit what access is needed.
Full root or sudo privileges can be a risk in certain environments. Using Nessus, you can test to see exactly what privileges are needed to run vulnerability and compliance assessments in your environment and only allow access to what’s needed.
- Use unique accounts for authentication and assessments.
The ’nix subsystem allows for the option of using unique accounts for remote authentication and actually running the tests with plugins using ‘su’ or a combination of this and ‘sudo.’ Consider configuring this in Nessus.
- Use SSH keys or certificates.
Using a username/password to authenticate to a system with SSH usually means you implicitly trust your target systems, as a rogue or compromised system could be configured to steal your scanning credentials. Use SSH keys or certificates to mitigate this. Strongly consider setting up or using existing management tools to manage SSH key or certificate deployment and revocation.
- If using SSH keys, encrypt the private key.
A compromised unencrypted private key could mean full access to your internal infrastructure, just like a remote code execution vulnerability. Ensure your SSH keys are secured with a passphrase.
Read the online documentation:
Other blog posts in this series:
- Overview: How to Protect Scanning Credentials
- 5 Ways to Protect Scanning Credentials for Windows Hosts