Secure OpenSSH
These days I got a security advisory that demonstrates above words – possibly exists 0day exploit for OpenSSH daemon, that seems to affect OpenSSH 4.3 on CentOS/RHEL servers.
This post provides you with the instructions how to make your OpenSSH daemon secure and usable as possible.
To quickly secure OpenSSH daemon, open config file located at /etc/ssh/sshd_config and make the following changes:
Protocol 2 PermitRootLogin without-password StrictModes yes Banner /etc/sshd_banner LoginGraceTime 60 MaxAuthTries 3 MaxStartups 10 PermitEmptyPasswords no PrintLastLog yes AllowTcpForwarding no IgnoreRhosts yes IgnoreUserKnownHosts yes HostbasedAuthentication no</code>Create SSH banner, just open in a favourite text editor file /etc/sshd_banner and fit it with following contents:
This is secured SSH service. Your activities are logged and monitored.
Warning: Unauthorized access to this system is strictly prohibited.Also, to secure access to the OpenSSH daemon it is recommended to disable the password authentication and use a public/private keys.
Below is a description of directives used to secure OpenSSH:
Protocol
This directive allows to specify the version of SSH to use. For security reasons it is strongly recommended to use only protocol 2, because the old version has several security flaws.
PermitRootLogin
Configure behaviour for the root account to eliminate security risks. The without-password argument allows root login only using public keys. The password authentication will not be allowed.
StrictModes
Tells SSH daemon to check user's permissions in their home directory and rhosts files before accepting login. For security reasons it is recommended to enable it because sometimes users may accidentally leave files or directories writable, and script-kiddies may use this to assume user's identity.
Banner
Directive tells to SSH daemon to the file that contents should be displayed before login occurs. Usually this directive is used by organizations where is required some legal verbage to be shown when host is accessed.
LoginGraceTime
This parameter tells to SSH daemon drop connection attempts if a successful connection hasn't occured in a specifed amount of seconds. I limited it to 60 seconds.
MaxAuthTries
This directive allows to avoid some brute-force attacks to the daemon by limiting failing connections attempts. By default, users who cannot remember the password, gets 3 attempts.
MaxStartups
This parameter enhance security by limiting number of unauthenticated sessions keeped alive. This also helps in combating brute-force attacks because other attempts to authenticate will not be blocked, until one of active sessions succeeds authentication or times out.
PermitEmptyPasswords
Allows or disallows empty passwords. It is recommended to disable them because usage of empty passwords is discouraged for security reasons.
PrintLastLog
This directive empowers the user to check for security by displaying the users last login time at the time of login.
Reference:
http://www.sysadmin.md/secure-existing-openssh-installation.html
AllowTcpForwarding
Controls tunneled connctions of TCP protocols over SSH (like rsync over SSH). Sometimes tunneling is a security risk because it is difficult to detect behaviour of malicious protocols or applications. Also, tunnels are usually used by script-kiddies for crossing firewalls.
IgnoreRhosts
This directive enhances security by ignoring the legacy .rhost file from users. This is a best practice, in case rsh/rlogin are enabled or could accidentally become enabled.
IgnoreUserKnownHosts
Directive is used to protect against users setting up host-based authentication. For security purposes, it is often best to change the directive to yes.
HostbasedAuthentication
Tells SSH daemon to enable or disable host-based authentication. Most security experts are extremely opposed to any form of host-based authentication and recommends to use public keys or password authentication as alternative.
