With all of the NSA spying and privacy items out there, I thought I’d write a quick post on easy ways to lock down your SSH server for people who may want to make some tweaks to their sshd_config on their Ubuntu (or other Linux) installations. This article specifically covers opensshd_config settings. PAM settings and other SSH related settings will come later.

I have a series of bash scripts that generate these settings automatically. If you are interested, let me know and I will send you them. Note: everything in <<Code>> format references a line in your /etc/ssh/sshd_config. If you don’t see the line (or similar) anywhere, then you may need to add the line.

Some of the items below prevent information leakage, a determined adversary will be able to get around them, but it will prevent script kiddies and scanning attacks, easing the load on your server.

Port Settings

If possible, you should not use port 22 as the SSH port.

Port 22

Instead you should choose another unused port randomly and set that as the SSH port. For example:

Port 6920

There are many circumstances, however, where a client’s IT will not permit a non-SSH port to be open on their firewall. In these circumstances, leave the port as port 22. This is not a high security change. This change avoids automated SSH attacks and allows the server to have a lower profile if the ports are scanned.

IP Listen Address

ListenAddress 0.0.0.0

Try to avoid having ListenAddress set to 0.0.0.0 (All IPs). If there are multiple IPs available to the machine, a specific IP should be used for SSH and no other services. This will allow for easier auditing, as well as more difficult matching up specific websites to specific SSH servers.

This also allows you to set up very specific rules on the firewall for this machine. As well, it ensures that you know precisely where the SSH is open. If you are only to have it open on the internal network, this will naturally restrict it to that.

Protocol Version

Protocol 2

SSH protocol version 1 (SSH-1) has known man-in-the-middle attacks problems and myriad security vulnerabilities. SSH-1 is formally obsolete and should be avoided at all cost.

Privilege Separation

UsePrivilegeSeparation yes

UsePrivilegeSeparatation sets up a child process to deal with any incoming traffic. Only after the user successfully authenticates will it give them the privilege of the authenticated user. This is so that if any of the incoming traffic corrupts the process, there will be no privilege escalation.

While this is usually by default “yes”, it should be listed as a line item in sshd_config to ensure that it is on.

Logging

SyslogFacility AUTH
LogLevel INFO

Logging should be set to go to the /var/log/auth.log facility by using the SysLog AUTH parameter. This will ensure that any problems around invalid logins or the like are forwarded to a central security file for auditing purposes.

Allowed settings for LogLevel at Panda Rose are ERROR, INFO, VERBOSE. In general, LogLevel should be INFO if diskspace is not a concern, however it should not go to DEBUG levels as that will violate the privacy of users. If disk space is a concern, LogLevel should be at ERROR and it should be gzipped and stored on a regular basis for auditing purposes.. VERBOSE should be used for debugging purposes if necessary. However, it should not be on as the default LogLevel as the data it produces is far more difficult to audit than either ERROR or INFO.

Authentication

LoginGraceTime 120

This is the time allowed for a non-authenticated user to stay connected to the system. Commonly 120 seconds is the default. You can set this lower to avoid this being a DDOS vector, however 120 seems to work well for most circumstances.

PermitRootLogin no

There is no circumstance that this value should be anything other than no.

StrictModes yes

StrictModes specifies whether sshd checks to ensure a user did not make their .ssh directory and files writable by anyone other than its rightful owner. If the permissions are wrong, then the user cannot log in. As a security tool this prevents a hostile user or a hacked account from gaining access to other user accounts (and possibly administrative access) to the server.

PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys

Public Key Authentication is recommended for general use. This functionality allows users to create password-protected public/private keypairs using a facility like Puttygen or ssh-keygen and then connect securely using said private/public key pairing. Instructions for how to properly create one of these keys is explained in a later article on client security procedures.

IgnoreRhosts yes

This prevents issues around HostbasedAuthentication. While not likely a big issue, it should be set to ignore them.

HostbasedAuthentication no

In circumstances where the server is an independent, secure server, HostBasedAuthentication should be set to no.  When there are multiple servers that are not all necessarily secure servers, and a need to have a centralized server handing HostbasedAuthentication, this can be set up. This will be discussed in further detail in a later article.

PermitEmptyPasswords no

This one is just simple common sense one. No one should be able to login if they don’t have a password.

ChallengeResponseAuthentication yes
UsePAM yes

This is related to the PAM based authentication set up for root users to be explained in another article. This allows Google Authenticator or another token-based or biometric-based authentication system to be implemented to improve security security for administrative users.

UsePAM allows us to set up PAM to use these extra methods of authentication for logging in administrative users.

KerberosAuthentication no
GSSAPIAuthentication no

For the purposes of most installations, neither Kerberos nor GSSAPI-based systems will be used.

Forwarding

X11Forwarding no

Unless absolutely needed, X11 shouldn’t be running on a Linux server open to the web. X11 Forwarding should be off. In circumstances where X11 Forwarding is on, treat the server as a secure Linux client and not a server.

GatewayPorts no

In most cases individuals won’t be using your server as a gateway to other machines. Set GatewayPorts to no to ensure that any port forwarding is limited to the local machine. If this needs to be set to yes, make a note of it in that server’s details document for future audits.

Information Leakage

PrintMotd no

While a message of the day seems useful, in many circumstances it gives away information to end users who may not be administrators that they should not be aware of. This setting is by default on for many Ubuntu installs, it should be turned off.

PrintLastLog yes

This will print the IP, date and time of the last user login for that user. This is useful information as it can give a user a hint if someone were to gain access to their account. Leave this one on.

Prevent zombies

TCPKeepAlive yes

To avoid infinitely hanging sessions, this should be left on. This will send TCP keepalive messages to determine if the client has gone down. If the client goes down or the connection is interrupted, it will be noticed and the server will end the session. To avoid consuming server resources with “ghost” users, this should be left on.

Some users may complain since it implies if the route goes down temporarily, the connection will die. In these circumstances, determine if their needs require this to be turned off. Turning this off has no security implications.

Legal banner

Banner /etc/issue.net

This will display a banner before a user logs into the server. For clients who have their own legal team, a proper banner should be requested from them for their servers. Panda Rose’s standard banner is as follows:

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
 You are accessing a Panda Rose Consulting Studios (PRCS) managed 
Information System (mIS) that is provided for authorized use only.
  
 By using this mIS (which includes any device attached to this mIS), 
you consent to the following conditions:
 
 * PRCS routinely intercepts and monitors communications on this mIS.
 * At any time, PRCS may inspect and seize data stored on this mIS.
 * Communications using or data stored on this mIS are not private. 
They are subject to routine monitoring, interception and search. 
They may be disclosed or used for any PRCS authorized purpose.
 * This mIS includes security measures (e.g., authentication and 
access controls) to protect PRCS and our clients' interests -- 
not for your personal benefit or privacy.
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= 

Your IP has been logged.

Contact your lawyers, or make an adjusted version to fit your needs.

Protocols

Ciphers blowfish-cbc,aes256-cbc,aes256-ctr
MACs hmac-sha2-256,hmac-sha2-512,hmac-sha1

Restrict Ciphers and MACs to the best secure ciphers. While not a real issue, this shows attention to detail. HMAC-SHA1 is required since PuTTY does not support the other algorithms yet.

Restrict Users

AllowUsers name1,name2

It is a good practice practice to limit the SSH to only users who should have access to it, this is done with an AllowUsers line at the end of the sshd_config listing the users who can log in with SSH.

Final thoughts

The above are suggestions, and over time may change to fit the needs. At the end of the day, these settings are just a small piece of ensuring your server is secure. Most of the determined attacks on your server will be based on zero-day vulnerabilities or other security holes, many of which are not even related to SSH. Ensure your server is up to date regularly, and always audit your logs to detect break-ins. You can use a tool like logcheck or logwatch to aide you in this process.

This article is crossposted at Panda Rose’s blog