Security Management Strategies for the CIORequires Free Membership to View
In the August Apache server attack, an unrestricted SSH key from an account used for automated backups was compromised. This key was then used to access a high-visibility server.
Passwordless SSH keys used for automated processes represent an attack vector because their safety is determined by the security of the host. If the security of this host system is compromised, an attacker consequently has access to the SSH key. In fact, the SSH key needs to not have a password so that the automated processes can run unattended. The SSH key can be password protected and the automated process can have the password embedded in it, but these settings only slow the attacker down. Unrestricted SSH keys will also slow or restrict an attacker to only use the SSH key to connect from specified locations or from using specified commands. This will require the attacker to route his or her attack through these systems or be limited to the specific command. These restrictions can greatly improve the security of SSH keys, but one additional step that can be taken on the SSH server is to only enable an account used during the time necessary to set up a connection, thus further limiting access to the account.
For example, if you need to use rsync, a software application that synchronizes files from one location to another, over SSH, follow the recommendations from the Apache incident and restrict where a SSH key can be used from, what commands it can run, and additionally have an automated process that enables and disables the account used during the time window for the rsync. This limits an attacker to only using the SSH key from the specified host using the specified command at the specified time. The technique here isn't impervious from attack, but it is a definite improvement over unrestricted, passwordless SSH keys.
This was first published in December 2009
Join the conversationComment
Share
Comments
Results
Contribute to the conversation