With the sudden rise in SSH brute force attacks, securing SSH is more important than ever. In a shared hosting environment, you options are somewhat limited, but if you have a well defined user group, you can really lock down SSH such that brute-force attacks are no longer a threat. Here are a few methods you can employ to further harden your SSH installation.
Default Settings
Before going over the changes, I just want to highlight some of the issues with the default settings. These apply to Red Hat, Fedora, and CentOS distributions.
- Allows Legacy SSH protocol version 1 which has known security issues
- Allows direct access to root via password authentication
- Uses low key strength to secure sessions
- Allows access to all users
Though these items are relatively minor, they can easily be corrected with proper configuration.
Harden SSH
Previously, I commented on some ways to protect S“SH against brute force attacks”:https://www.rackaid.com/blog/how-to-block-ssh-brute-force-attacks. For more generally applicable changes such as restricting root login, limiting timeouts, and disabling protocol 1, see my post on how to add protective measures to SSH.
The changes below are designed for systems that have a finite, well controlled user base and go much further to harden SSH.
Default Port
If you scan the web, you will find recommendations on changing the default port of SSH. You will see this justified with statements like:
The vast majority of SSH attacks are directed by compromised zombie machines against SSH servers listening on the default port of “22”. By changing this port to something else you greatly reduce the risk of an automated break-in.
*If an automated attack can break into your server, you have security issues beyond what SSH port you are using.*
This approach simple obscures the security problem, such as weak passwords, by hiding it. While you may reduce the number of successful attacks from zombie bots, an attacker or bot doing port-scanning can quickly identify your SSH port.
Changing the default port merely complicates management issues – users must use special configuration, you have to keep track of the port, and security scanners may flag it as suspect.
Protect SSH with a Firewall
One of the best things you can do is start at the perimeter and use your firewall to block access to SSH to unauthorized IP addresses. If you have road warriors, you can then use VPN to provide secure access. This provides a very secure, first layer of security. If you do not have a hardware firewall, you can use IPTables to limit SSH access. This is one of the best measures you can apply.
Restrict Users
You can configure SSH to permit only certain users to log in. By default all users can access SSH. By using the AllowUsers directive, you can restrict access. I like using this as it provides another layer of security. There is also an AllowGroup directive. Using the group option, you can put all approved SSH users into a group and then allow this group.
AllowUsers root admin webmaster
Or
AllowGroup sshusers
Do not Use Passwords
SSH can use keys to provide authentication. If you use keys, you can completely disable password-based logins. Even if the person has the password, they cannot login. Before enabling this, be sure you have your keys configured properly. You don’t want to lock yourself out. Many SFTP/SCP clients can also use keys. I’m sure you can find a tutorial on how to use keys with your favorite SSH or FTP client.
To stop password authentication, you simply set this directive:
PasswordAuthentication no
Use TCPWrapper
TCPWrapper provides an additional security layer. If your environment is relatively, stable you can block SSH in your /etc/hosts.deny file and then open up SSH to specific IP addresses using /etc/hosts.allow
/etc/hosts.deny sshd: ALL
and
pre(console)./etc/hosts.allow
sshd: 192.168.1.1, 10.10.0.0/255.255.0.0
This is very easy to configure and while it may be in part redundant to your firewall settings, security in layers is a good thing. For example, what if your firewall was offline for some diagnostics? This would still provide you another level of IP-based access control.
Increase Key Strength
By default, a key strength of 768 bits is used. Current recommendations are for 1024 or 2048 bit strength. While I don’t expect this to be an issue, its a simple step. Once you change this, you will need to delete your current host keys and SSH will regenerate them when it restarts.
ServerKeyBits 1024
Check the Defaults
There are several settings which by default are secure but you want to review them. You can find more details on these in the SSH documentation. But quickly:
IgnoreRhosts yes RhostsRSAAuthentication no HostbasedAuthentication no PermitEmptyPasswords no UsePam yes
There’s always more ….
I am sure there are more settings and tweaks that can be applied. I’ve found the methods above very effective in hardening SSH. I don’t worry about brute-force attacks on our systems. Using these methods and rate-limiting SSH access with IPtables is a powerful security setup.