Linux :: How to harden SSH security on CentOS

Secure Shell for Linux has been one of the most attacked on servers, we find many cases where the bruteforce finally compromises the server for root access. One of the most common queries that come on to desk is how to harden out SSH - here are few tips that should help - I wont recommend enabling every bit of it, but will include the list which is most required and ones that are optional.

The configurations of SSH is available either on /usr/local/ssh/sshd_config or /etc/ssh/sshd_config - so that is where we start. So we need a connection on KVM or SSH on to the server and knowledge of popular editors like pico or vim to start with it.

Most Important Changes

These are the list of configurations that you should never do away with, so start with the first:
1. Block SSH Version1:
SSH protocol version 1 (SSH-1) has man-in-the-middle attacks problems and security vulnerabilities. SSH-1 is obsolete and should be avoided at all cost. Open sshd_config file and make sure the following line exists:

Protocol 2

2. SSH Port
From what I have seen, most of the bruteforce happens on to the port 22, considering the fact that most of the server owners doesn't care to change the SSH port. So this is the second most important thing to be done- change the SSH port to a number different from 22 - which is the default port id:

Port 1111

be sure to remove the comment mark preceding the Port entry and also ensure that you update your firewall or firewall wrapper configuration for the new port to be accessible. Another option of securing sites will be to disable access from all public entries and allow access to port 22 via LAN or WAN connection - this is possible only for local servers or locations where you have static IP range - the iptables entries will need to be updated as :

pico /etc/sysconfig/iptables 

(or find the locations of iptables by running /etc/init.d/iptables save)and add the following entries:

-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -s 202.54.1.5/29 -m state --state NEW -p tcp --dport 22 -j ACCEPT

if you do not want to alter the firewall configuration, you can restrict access on to the server from specific network by removing the command on 'ListenAddress' keyword:

ListenAddress 192.168.1.5
ListenAddress 202.54.1.5

where the first entry should be updated by your LAN IP and the second by your WAN IP address.
3. Protect SSH with Firewall
Apart from the iptables rules said above, it will be wise to install a bruteforce prevention firewall wrapper like CSF or similar where you can define the count of failures on to SSH and block the originating IP address. I am recommending CSF since its getting updates on a regular basis and has a simple configuration that can be used to carry out much complex operations.

4. Disable Root Login
Disabling root login is another good option which should protect the server even if your workstation is compromised with key loggers. The root password, even if it is correct, wont be accepted by the system which inturn will need a non-root user to login to the server first and then use the 'su -' command to gain root access. You can achieve this by updating the configuration entry:

PermitRootLogin no

to take this option to the next level, you can also define the set of users which do have access on to the ssh server, thereby minimizing the chances of compromise, you can do this by adding in the entry:

AllowUsers root raj rahul

or

AllowGroup sshusers

which should help you from not defining each individual user - and add the new users to the group if you want them to have SSH access

5. Defining Idle Timeout for users:
Another important setting that shouldn't be ignored is having an idle timeout set for your logins so that the active sessions doesn't allow hackers to change settings. We can get this done by updating:

ClientAliveInterval 300
ClientAliveCountMax 0
HostbasedAuthentication no

this is required by most of the systems unless you have a more secure network behind a hardware firewall. The above timeout is for 5 minutes and post this period all active sessions will be terminated.
6. Ensure that the defaults are not modified:

IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
PermitEmptyPasswords no
UsePam yes

ensure that these settings are not altered as you wouldn't want the rhosts entry and empty passwords to be active on for SSH logins.

7. Issue a notice on each login:
Issuing a well defined banner on each SSH login should be good as well, add in the guidelines and also define the penalty of breaching into the system - that should help at times:

Banner /etc/issue

and a sample entry would look:

----------------------------------------------------------------------------------------------
You are accessing a XYZ Government (XYZG) Information System (IS) that is provided for authorized use only.
By using this IS (which includes any device attached to this IS), you consent to the following conditions:
+ The XYZG routinely intercepts and monitors communications on this IS for purposes including, but not limited to,
penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM),
law enforcement (LE), and counterintelligence (CI) investigations.
+ At any time, the XYZG may inspect and seize data stored on this IS.
+ Communications using, or data stored on, this IS are not private, are subject to routine monitoring,
interception, and search, and may be disclosed or used for any XYZG authorized purpose.
+ This IS includes security measures (e.g., authentication and access controls) to protect XYZG interests--not
for your personal benefit or privacy.
+ Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching
or monitoring of the content of privileged communications, or work product, related to personal representation
or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work
product are private and confidential. See User Agreement for details.
----------------------------------------------------------------------------------------------

courtesy:cyberciti.biz

Optional Settings for Added Security

8. Using Key based login
This is usually a recommended option which allows each user to create a sign in key and if it matches with the key on the server, the access is granted in. We had skipped this option earlier as it becomes tough when you are not on the machine or laptop that you are used to working from and will be troublesome if you have to get to the system from a new machine.

You can refer : http://www.cyberciti.biz/faq/ssh-passwordless-login-with-keychain-for-scripts/ for setting up the key authentication.

Another interesting addition will be : Using Google Authenticators So the settings you will need to update is to enable key based authentication are:

PasswordAuthentication no
ServerKeyBits 2048
RSAAuthentication yes
PubkeyAuthentication yes

That should help you get running.

9. Disabling SSH open Server
So if it is just for SSH that you need the server running for and to avoid users from sending out or receiving files over SSH, you can disable SSH server entity which is enabled by default, you can do that by running the commands:

chkconfig sshd off
 yum erase openssh-server
 service iptables restart
 service ip6tables restart

10. Use Log-level info
Read your logs using logwatch or logcheck. This should help you keep constant check on the SSH activity and modify the security rules based on incoming traffic. Make sure LogLevel is set to INFO or DEBUG in sshd_config:

LogLevel INFO

Additionally, you can recompile the source code of SSH to enable the following options which should help you gain added security:

#  Turn on privilege separation
UsePrivilegeSeparation yes
# Prevent the use of insecure home directory and key file permissions
StrictModes yes
# Turn on  reverse name checking
VerifyReverseMapping yes
# Do you need port forwarding?
AllowTcpForwarding no
X11Forwarding no
#  Specifies whether password authentication is allowed.  The default is yes.
PasswordAuthentication no

Once the modifications are complete, save the configuration and run the following command to ensure the compatibility of changes:

`which sshd` -t

if the syntax returns no error, then feel free to restart the services:

service sshd restart

Hope this did help!

Unknown

- Unknown Updated at: Monday, February 04, 2013