Welcome to CSAM Day 17!  Today is brought to you by Secure Shell (SSH) commonly deployed on port 22/TCP.

SSH has become ubiquitous as a mechanism for command line access to *nix systems, and is sometimes deployed on Windows systems as well.  As the Dshield graph for port 22 shows, it is a popular target for attackers.  These attacks usually take the form of attempts to brute force root accounts and other accounts with weak passwords.

My primary method of protecting SSH servers is threefold:

• Deploy the SSH server on a port other than 22/TCP.  It appears that the SSH probes on the Internet at this time are focusing their interest on the standard SSH port. My personal server is deployed on a non-standard port and I have not had any attempts to login in over two years.
• Deploy one of the SSH brute force prevention tools like DenyHosts, fail2ban, blockhosts, etc.  On one of the servers I run where I have to deploy on the standard SSH port DenyHosts has blocked 65 IPs which have attempted brute force attacks in the last month. 
• Disallow remote root logins.  Most SSH servers provide a mechanism to disallow the ability to login to a root account using SSH. In OpenSSH this is done by setting PermitRootLogin to "no" in the /etc/ssh/sshd_config file. This forces users to login using a user account and escalate privilege using su or sudo to become root.

What strategies do you use to secure SSH?

Do you have any strategies for protecting SSH servers deployed on Windows?

Please submit your suggestions through our contact form or via the diary comment system.  I will summarize throughout the day.

UPDATES:

Faisal pointed out that I was remiss in not mentioning SSH keys.  If you use keys for authentication and disable password authentication via SSH then SSH brute force attacks cannot succeed.  In OpenSSH password authentication can be turned off by setting PasswordAuthentication to "no".

Joanne points out that there are alternatives to using brute force prevention tools.  In her case she uses the iptables firewall to only permit one SSH connection, successful or not, every three minutes.  Joanne also points out that if you must use passwords at least make sure the users use good ones.

Ned maintains a securing SSH page over at the CentOS wiki.  It describes in detail how to implement some of the ideas presented here and more.

Sven sent a number of strategies.  First he suggested using AllowGroups to limit access to a group of people.  He also recommended that if users only require file transfer capability alternative shells like scponly can be utilized. He also points to ChrootDirectory which can be used as a chroot jail for SSH.

Gerard is a fan of sshdfilter.  It is another of the anti-brute forcing tools, but it is an sshd wrapper and doesn't use tcpwrappers for blocking but rather creates iptables or ipfw rules to facilitate the blocking.

Michael suggests that if you know which IP ranges need to access your SSH server that you can limit the IP ranges using the built in iptables firewall.  I have in the past  used TCPWrappers, which is wrapped around most implementations of openSSH to do the same thing.  A good tutorial on how to implement either of these strategies to limit which IPs can connect to your servers is available over at the Debian Administration pages.

-- Rick Wanner - rwanner at isc dot sans dot org