SSH Security Primer: Server Security Settings

By John Traenkenschuh Date: Feb 23, 2007 Return to the article

In this follow-up to his article on SSH client software security settings, John Trnkenschuh describes the settings and implementation details important to your OpenSSH server installation. Because an OpenSSH server functions as a VPN gateway as much as a means to transfer files and invoke commands remotely, it's important to get this right. My previous article in this series discussed SSH client security settings. To summarize, if you cant control installations of rogue SSH clients, your only control is to limit outbound access through firewalling or other network-layer controls. Another of my articles discusses the issues with allowing outbound SSH access to the Internet. If unmonitorable tunnels into your intranet are not a concern, then you have the following goals:

Securing the users private key Ensuring that the authentication of SSH servers isnt disabled (or too trivially reconfigured by users automatically trusting any and all server keys) Making sure that files sourced at SSH startup arent hacked, etc.

There, that was easy. Before you read this article, please review the OpenSSH man pages for the daemon and the OpenSSH client. OpenSSH has a pretty righteous FAQ as well. Review all the technical background yourself, because I cant do that in this article. Consider a good SSH book, and go to Safari to check out the hundreds of hits from many, many books.

SSH Servers: A Basic Risk Analysis

How do you secure your SSH servers? What are the total risks of such servers to your organization? Youre well aware of the possibility of people hacking your server and getting unauthorized access. Thats bad. But there are other risks. The SANS Institutes Top 20 risk list really stresses SSH risks. If compromised, that host can be a router/forwarder that will forward any kind of traffic to any host the p0wned box can accesseven your "secured" hosts given Internet Assigned Numbers Authority (IANA) reserved IP addresses. (Read RFC 3330 and RFC 1918 for the gory details on these addresses.) In most cases, those addresses arent accessible over the Internet. More of a concern is your hosts threat to the rest of the Internet. With poor security, the unmonitorable SSH pipe leads from your host to the Internet itself. What will you do when your mail servers are blacklisted because of your machine being every spammers holiday present? Poorly secured SSH servers

are a threat both to your organization and to other organizations, and just may get you blacklisted. Obviously, its important to secure these servers. TIP SSH has been on many researchers radars. Dug Song, the great security researcher, has created some great tools; for example, check out his SSHMitM. This tool is aimed primarily at Protocol 1 SSH servers, a point important to remember as you read this article. Server security offers many more options than client security. Its important to establish your baseline server security before configuring the first OpenSSH server. Lets dive in.

Step 1 in Securing Your SSH Servers

As I mentioned in the previous article, you should get a copy of Metasploit or Nessus and scan your servers running OpenSSH. OpenSSH.org does a great job of listing known issues with their product. Make sure that you have the latest version, of course, but beyond that, make sure that you have the bestpatched version of anything running on the system. The weakest defensible service is the weakest link in your SSH installation. Review the reported SSH security issues with some objectivity. Some of these issues, reported as "SSH issues," arent solely a problem with SSH. Need an example? Youll read about SSHs issue with the X Window System (commonly referred to as X). Whether using OpenSSH and the X Window Systems tunneling (or using X and common forms of xhost security), you have the same security issue. In most cases, a compromised server, throwing sessions and displays to your X Window System software, can monitor (and inject data into) your session. Somehow a core X vulnerability gets tied to SSH when SSH is used to tunnel X? Just remember that the attacker who controls a service gets that service. Now consider the SSH issue. The attacker who controls your SSHD gets the SSH service and basic networking connectivity into your intranet or back onto the Internet. SSH must be secured well. Give your OpenSSH environment a solid, secure foundation. Secure the server itself well.

Creating a Solid Configuration Baseline

You need a solid foundation for your server implementation. With clear baselines established, you can distinguish a hacked configuration file quickly. Define your absolute must-haves: no protocol version 1 support, no blank passwords, etc. Monitoring absolutes is easy because theyre very distinct and clear, providing expected values on all devices. Of course, lets not forget that SSH can source configuration information from the "official" configuration file, from command-line parameters, or from a configuration file called out on the command line during a HUP. Your monitoring system cannot just check the standard files placed in standard locations and assume that these defaults were used to start the daemon. And lets really get ugly: Check the provided configuration file. None of the security features are configured by default in the official configuration file. Lets let the OpenSSH crew explain their approach:

Lines starting with # and empty lines are interpreted as comments. # # # # The strategy used for options in the default sshd_config shipped with OpenSSH is to specify options with their default value where possible, but leave them commented. Uncommented options change a default value.

#Port 22 #Protocol 2,1

Whats the impact of this design? The sshd provided by OpenSSH has many security defaults compiled in. But whats the impact if a hacker moves a new copy of sshd onto your system? If the new copy of sshd has no security settings compiled into it, the configuration file wont call for them. This means that assumed security configurations are totally undone, and you have no easy way to determine just what your actual settings are. Lets be honest, however. Too many administrators load a piece of software onto a system, hope the default settings are secure, and then run it as production. The problem isnt OpenSSHs approach; rather, its those people who assume security without confirming it. You must understand each OpenSSH security setting. You must set consistent baselines for each setting. I would even suggest that you spell out each required setting in the configuration file. A hacked daemon may ignore it, but you will have provided fellow support staff with a clear statement of expected settings. Under these conditions, a daemon that doesnt log, for example, gives a clear error condition. So how will you monitor your running daemons? Sure, you can monitor your configuration files for unauthorized changes, once you have baselines; but what if the attacker uses command-line options to call out an alternate configuration file or settings? UNIX systems may sometimes reveal command-line parameters when a process list is generated (ps ef), but that can have problems. I can only suggest that you will restart your daemons from time to time with set values. Maybe youll check logs for daemon restarts outside of your normal service windows, which helps to show a possible insertion of new configurations. But what about the hacked copy of sshd? Maybe youll try to use a single version of sshdone thats fully patched? Maybe youll at least have an MD5 sum calculated (or read the sum documented in your rpm package) and check the local copy of sshd against the known MD5 value. These approaches to configuration, patching, and file-versioning management will go a long way toward lessening your risks. And now that you know the difficulties youll face in controlling SSH security, we can consider the settings that seem to have the most relevance to your final security settings.

Relevant Settings
The information in Table 1 is derived from the actual sshd_conf documentation. If you find something really puzzling, review the documents again. Buy a book. The OpenSSH community is pretty helpful if you have a big problem or worthy suggestion. And dont forget those hundreds of hits in Safari waiting for you to activate your free trial period. Table 1 OpenSSH server security settings and possible values. Directive Security Importance

Port 22

#Protocol 2,1

# HostKey for protocol version X

Running a service on a nonstandard port is part of the "security through obscurity" game, which seldom works with todays sophisticated scanning engines. Some people have implemented a configuration called "port-knocking," something that requires a separate article. Others ensure that OpenSSH is compiled with TCP wrappers support. This strategy allows for basic address filtering of unwanted hosts. (Want an article on TCP wrappers and what this feature can bring you? Respond below.) Protocol 1 seems to have some security risks tied to it. Most sources I read recommend sticking to Protocol 2 for most SSH installations. See this as a flashing sign. You must protect the integrity of these keys. There is no easy revocation process, and implementing a new key will have lots of SSH clients complaining about the new signature. Your help desk will love you if you keep the updates to organized, communicated changes. Still going to use Protocol 1, eh? Right now, 1024 key size seems to be a value that many sources recommended. You must keep track of cryptographic happenings yourself and adjust the key bits up as needed. You must turn on logging. From there, the recommended values get fuzzy. Try the defaults and check the logs. Got enough for an investigation? If not, see the sshd_conf man page for values and their meanings. Servers set to debug levels of logging might indicate that an intruder is analyzing your sshd design closely. These settings generate a lot of discussion among experts. Should you permit a direct login as root? Should you require people to log in with basic accounts and then invoke root privilege as needed? Im going to invite flames by stating that its okay to permit root login under certain conditions (to be listed in any rebuttal to said flames). I also believe that StrictModes is important. If a user opens his or her home directory (o +w), all SSH files are open to hackers tantamount to loaning your system account to anyone else in the world. StrictModes keeps sshd from accepting logins from poorly secured account settings.

# Lifetime and size of ephemeral version 1 server key #KeyRegenerationInterval 1h #ServerKeyBits 768 # Logging # obsoletes QuietMode and FascistLogging #SyslogFacility AUTH #LogLevel INFO # Authentication: #LoginGraceTime 2m #PermitRootLogin yes #StrictModes yes #MaxAuthTries 6

#RSAAuthentication yes #PubkeyAuthentication yes #AuthorizedKeysFile .ssh/authorized_keys

RSA authentication is used with Protocol 1 only, so I wont cover it in this article. PubkeyAuthentication is used to enable public key authentication. Part 1 of this series specifies the potential shortcomings of digital key authentication, but overall I strongly prefer it to passwordsgiven sane credential handling practices in the field. AuthorizedKeysFile is another important setting. Users can place their public key(s) into a file and thereby enable PubkeyAuthentication. Note the plural: Users can create and misplace and undersecure all the key pairs they choose to use. Your goal is to select a reasonably secure file choice and location for the key pair(s). Something like the /pub directory in /var/ftp might be a bad choice.... Again, RSA authentication is used with Protocol 1 only, and so Ill duck out of covering it here. Host-based authentication attempts to wed ~/.rhosts or /etc/hosts.equiv with digital key authentication. The default is no, and seemingly for good reason. There are many attacks (and attack tools) that love to attack .rhosts and hosts.equiv. Leave it off. I believe that most users will set home directory permissions to 777 if an attacker asks nicely enough. I believe that theyll use Yahoo! mail to distribute the most confidential informationand unencrypted at thatif a stranger insinuates a big order. I dont that believe you should trust user-configured ~/.rhosts or their known_hosts files. I believe that UserKnownHosts and user .rshosts and .shosts should be ignored. Think otherwise? Respond below. Tough choices, indeed. Passwords suck, but we still use them. Theyre configured by users, using predictable values. But until we have easier methods to generate, distribute, and revoke digital keys securely, I think we still need to configure SSH to use passwords. I think you shouldnt permit empty passwords. Even if you have a service account with a truly secure "forced command," enabling empty passwords will enable it for other users.

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts #RhostsRSAAuthentication no # similar for protocol version 2 #HostbasedAuthentication no # Change to yes if you dont trust ~/.ssh/known_hosts for # RhostsRSAAuthentication and HostbasedAuthentication #IgnoreUserKnownHosts no # Dont read the users ~/.rhosts and ~/.shosts files #IgnoreRhosts yes # To disable tunneled clear text passwords, change to no here! #PasswordAuthentication yes #PermitEmptyPasswords no

# Change to no to disable s/key passwords #ChallengeResponseAuthentication yes # Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes #KerberosGetAFSToken no # GSSAPI options #GSSAPIAuthentication no #GSSAPICleanupCredentials yes #UsePAM no #AllowTcpForwarding yes #GatewayPorts no

OpenSSH supports some sophisticated authentication technologies. If your organization uses s/key, Kerberos, or the Generic Security Services Application Program Interface (GSSAPI), test them and then enable them here. PAM is cool; get a book on using it with SSH, however. Theres a lot of complexity, some of which is hinted at strongly in the sshd_conf comments.

#UsePrivilegeSeparation yes

#UseDNS yes

#PermitTunnel no

# no default banner path #Banner /some/path

Allow forwarding? Provide an open gateway to all? Do you want your sshd to act as a VPN gateway? If you feel you have the skills needed to understand and support/secure such a configuration, enable it. Be prepared to answer for your decision, however. Upon successful authentication, sshd forks a process that runs as the user account. Use this setting to slow many privilege-escalation attacks. Im going to vote no here. Try it with a yes. If you find that people cant log in, thank some ISPs DNS tables. Some dont have accurate PTR records that resolve successfully to their A records. Even with accurate DNS, what security is provided? I personally believe in authenticating people, not devices and locations. Internet connection-sharing technologies and firewalls that translate outbound traffic to split DNS designs just make it tough to draw too much specific information on a device and its reported IP address. See my comments on forwarding. Youre joking, right? Security folklore has it that some hacker wasnt convicted of his/her crimes because of a welcome banner that actually welcomed the users. Anyone have specifics on this? Is it truly important to have a banner that warns users that theyre being monitored? If so, heres where you specify a banner file.

Clearly, the SSH server has many intricate and useful security settings that can be applied in many ways. Your distribution may have many moreboth settings, and ways to apply them. Feel free to plug them into the final row of the table and respond below.

The Big Picture

As you review these two articles on OpenSSH security, you see that this is a tool with many abilities and precautions. You can trade in simplistic passwords for sophisticated digital keysand wonder how many keys are copied during an attack. You can provide an encrypted tunnel that protects passwords and watch the same tunnels keep you from monitoring infiltrators as they go where they shouldnt. The goal of all of these articles is to raise awareness of SSHs many features and risks, if said features are applied haphazardly without a clear understanding of the butterfly effect causing a security tsunami. The best way out of this is to get a good team together; provision them with good books, training, and consulting; and then empower them to create an architecture that stays consistent. I hope youve found this article useful. If not, respond below.

2010 Pearson Education, Inc. All rights reserved. 800 East 96th Street Indianapolis, Indiana 46240