SANS ISC: Cyber Security Awareness Month - Day 17 - Port 22/SSH

• SANS Site Network
  • Current Site
  • SANS Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

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 ssh wrapper and doesn't use tcpwrappers for blocking but rather creates iptables or ipfw rules to facilitate the blocking.

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