This post was originally published here by aliaksei kulik.
Along with the unveiling of Container Secure, this week CloudPassage announced the availability of CSM policies for CentOS 7 and 6. These policies are inline with the CIS CentOS Linux 7 Benchmark v2.1.1 and CIS CentOS Linux 6 Benchmark v2.0.2. There are more than 189 controls in each policy which relate to granular and advanced system-hardening setting.
While developing the policy I came across research from the University of California, San Diego and the University of Michigan. Researchers at these universities found that almost 10% of SSH keys used in the production infrastructure are considered vulnerable as a result of incorrect configuration or weak encryption algorithms. While there are dozens of advanced security-hardening settings available, it was an eye-opening to discover that even today, SSH configuration still isn’t well-understood.
The research mentioned that despite of the use of strong cryptographic algorithms, SSH could still be vulnerable. For example there are two vectors of attack on the SSH. The first being that when using block-based encryption, data is transmitted by 8 bytes. Second, when using SSH in interactive mode, any key you press generates an IP packet immediately after you click it (except for some meta-keys, such as Shift or Ctrl). So what does this mean? Well, this allows an attentive listener to map out the timings of user input from the moment of selection, until the arrival of IP packets that get processed at the kernel level.
SSH Crash Course
SSH works on the transport layer (RFC 4253). This layer handles initial key exchange as well as server authentication, and sets up encryption, compression and integrity verification. It exposes to the upper layer an interface for sending and receiving plaintext packets with sizes of up to 32,768 bytes each (more can be allowed by the implementation). The transport layer also arranges for key re-exchange, usually after 1 GB of data has been transferred or after 1 hour has passed, whichever occurs first. The IANA assigned to SSH protocol is TCP and port is 22. So the following ciphers are currently defined:
This is the official data provided by the RFC standard for SSH protocol. Note that the RFC recommends the use of one algorithm only. We recommend choosing between aes256-cbc, aes192-cbc, aes128-cbc. For the choice, you must understand that the stronger the algorithm, the more computing resources are needed for the process of encryption and decryption of a data. Understanding this will help you choose the ideal solution between security and performance. Which brings us to public keys. The following public key and/or certificate formats are currently defined:
In addition to the weaknesses highlighted in the university research, some other well known methods of attack are Eavesdropping SSH, Traffic Signature Attack, Multi-User Attack, Nested SSH Attack and the classic man-in-the middle, brute Force and weak protocol attack.
Recommended configuration
First and foremost, you need to pay attention to which protocol for provided data you use. The work of SSH is provided by 2 protocols: SSH v1 is no longer used, (it’s outdated and contains several security problems), SSH v2 is far more secure and doesn’t contain the critical problems found in SSH v1.
So when you’re configuring an SSH server, use:
Protocol 2
You need to limit the maximum number of authentication attempts within the one session. A report about incorrect inputs will create event logs in the OS, which can help to identify an attack.
MaxAuthTries 4
Do not resolve a login as root via SSH. In the case when data will be compromised, these actions reduce possible vectors of attack for hackers.
PermitRootLogin no
Do not authorize a user who doesn’t have a password.
PermitEmptyPassword no
Use strong encryption algorithms, such as Ciphers:
aes256-ctr, aes192-ctr, aes128-ctr
Set the timeout of interval after multiple incorrect password attempts, this will protect against a brute force attack.
LoginGraceTime 60
Use the principle of minimum sufficiency when you grant access. You need to provide access only to those who must connect via SSH. It can be a group or a list of specific users. Use:
AllowUsers <userlist>
AllowGroups <grouplist>
DenyUsers <userlist>
DenyGroups <grouplist>
What about the client workstation?
The most important rule is to keep the keys in a secure place. Limit the rights of access to the folder of keys and for the keys only used for your account. Don’t transfer keys in clear form through public communication channels. Use the master password for access to a key. And be sure to provide the password with sufficient cryptographic resistance.
Protection is only built from the set of measures that are applied. Meaning you must employ: correct network architecture, secure communication protocols, correct configuration of services, monitoring of new software versions, anti-virus protection, network-level protection, intrusion detection and intrusion prevention systems, and incident response services. And lastly – you must train and inform employees about the rules of information security.
It’s important to note that SSH protocol protection will not make your server completely secure, but it will greatly help to protect your infrastructure and your server.
Photo:YourStory.com
