6 SSH best practices to protect networks from attacks | Server Security
byAlbert D. Beard-
0
The vast majority of network administrators would not be able to do their jobs without SSH.
The protocol has replaced insecure mechanisms, such as Telnet and FTP, to become the de facto standard for remote access and administration. SSH not only ensures confidentiality and integrity for data exchanged between networks and systems, but it also enables public key-based authentication.
However, a default installation for SSH isn’t necessarily secure. And, if administrators don’t follow best practices, SSH can make a network vulnerable to a variety of attacks. Let’s examine six key SSH best practices security admins should write into policies and procedures to ensure their organizations’ SSH installation is secure.
1. Strong authentication
Hackers are constantly scanning for SSH servers and attempting to brute-force usernames and passwords. It is therefore critical to enforce strong passwords and explicitly disallow remote logins from accounts with empty passwords. Use the open source John the Ripper tool to find any existing weak passwords. The best option, however, is to disable server password authentication altogether and only allow key-based authentication. Also, require two-step verification when users log in. When private keys are created, protect them with a strong passphrase.
2. Least privilege
Follow the principle of least privilege; it’s critical when determining who is allowed to use SSH and how. Limit SSH logins to only those users who need remote access, and ensure those users only have the privileges they need to perform the tasks for which they are responsible. Always disable root user login to SSH, and instead add administrators to the sudo group so they can log in as regular users and use the su command to execute commands as the root user. Also, set an idle timeout interval to avoid having an unattended SSH session — inactive users will be automatically logged out once the interval has passed.
Follow the principle of least privilege; it’s critical when determining who is allowed to use SSH and how. Limit SSH logins to only those users who need remote access, and ensure those users only have the privileges they need to perform the tasks for which they are responsible.
3. Secure configuration
Patch all SSH servers on a regular basis to ensure they are running the latest software and they employ SSH-2 security. SSH-2 offers better security than SSH-1, which is no longer allowed by several compliance standards. Disable SSH port forwarding because it opens the possibility of unapproved communications avoiding detection because they are operating over an encrypted SSH connection.
There is a slight benefit to changing SSH from listening on the standard port 22 to a different unused port. This security by obscurity will avoid the amateur hacker’s automated scans but will not fool serious attempts to discover an SSH server. Whichever port SSH is running on, enforce a rate limit to perform simple throttling on incoming connections. Set a low limit for the maximum number of authentication attempts permitted per connection to protect against brute-force attacks. SSH ports should never be opened to external untrusted connections, so be sure to filter connections at the firewall to allowed IP addresses, as well as configure perimeter defenses to log and block repeated attempts to log in from the same IP address. Port knocking can add another layer of protection. This SSH best practices technique relies on firewall rules to only allow users who know the “secret knock” to enter the network through a particular port by performing a sequence of connection attempts called a knock sequence. This prevents an attacker from port scanning a system for potentially exploitable services. Without the correct knock sequence, protected ports will appear closed. Another possibility is to enforce the use of a bastion host so all other incoming SSH connections are automatically blocked.
A safe SSH implementation requires special consideration before and after deployment.
Only designated admins should configure servers to keep SSH services secure and to ensure central oversight and review.
4. Monitoring and auditing
The above steps are essential before exposing an SSH server to the internet. Once it is live, deploy constant monitoring and auditing. Monitor SSH logins and activity to detect any unusual activity. Conduct regular audits to discover new instances of servers running SSH and to detect any unsanctioned changes to configuration settings. This will prevent shadow or insecure SSH services from increasing the network’s attack surface. There are several tools that can automate this process, discussed below.
5. Training
Training is essential. Make users aware of company policies and procedures that cover the use of SSH. Check the authenticity of the public key for an SSH server every time a connection is established to avoid a possible man-in-the-middle attack. SSH keys should never be hardcoded, stored or backed up to source control or public repositories. Many organizations leave themselves open to SSH-based attacks because they have no inventory of deployed SSH keys. Preventing SSH key sprawl is an important way to mitigate SSH-based security risks.
6. Key management
Use an SSH risk assessment tool to manage the multitude of SSH keys that may exist within an organization’s IT infrastructure. These tools scan a network for SSH servers and then read configuration files to extract the exact location and use of every key. They also test for weaknesses in the configuration. This ensures all keys are brought under active management and each key is associated with only one individual or device. Another important key management task is key rotation. This involves the regular generation of new keys so that the same keys aren’t used for an extended period of time.
A number of SSH risk assessment tools are available. Among them, SSH Communications Security Inc. provides a report of a client’s most significant SSH risks, visualizations that illustrate trust relationships and prioritized recommended actions. Scans also parse configuration files to extract the exact location and activity of every key. Venafi, meanwhile, provides similar reports with its SSH Risk Assessment report, which covers exposure and actionable recommendations to reduce SSH risk. Both firms offer lifecycle SSH key management software that inventories SSH keys and analyzes each one to display the trust relationships enabled. Other firms that provide SSH key management tools include Userify and Keyfactor.
For open source SSH tools, CloudSploit and Scout Suite are two projects that detect potential misconfigurations and security risks in cloud infrastructure accounts, a common location for poorly configured SSH services.
SSH is a key administration tool to improve security, as long as SSH server deployment and management are governed by SSH best practices that prevent hackers from using those servers as backdoors to the network. Attacks against insecure and poorly configured SSH servers are becoming widespread. Update SSH-related policies and procedures to embed security into the protocol’s deployment and use.
