I don’t think this really adds anything to the security, but it looks cool.
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
