There is no doubt that the de facto technology to gain remote command line access is Secure Shell on Linux and UNIX systems. While there are numerous security guidelines suggesting many different configuration settings, I think there are some fundamentals which are missed.
Secure Shell is, in my opinion, the best method for remote access due to its flexibility and security. It makes it attractive for system administrators as well as system developers and architects. The ability to easily execute commands on remote systems and retrieve files over “secure” channels is seductive. Especially, since there is little-to-no programming required to facilitate this. However, in my opinion, this should be done with caution.
First of all, Secure Shell (SSH) is a network protocol that allows data to be exchanged using a secure channel between two networked devices.1 SSH was designed as a replacement for Telnet and other insecure remote access methods, which send information, notably passwords, in plain text, rendering them susceptible to packet analysis.
The most common server daemon and client software which employs the SSH Protocol is developed by the OpenSSH Project. Of course, there are several SSH capable clients available including the popular Windows client called PuTTY.
Besides having encrypted communications, the idea of being able to remotely log in or copy a file from one machine to another without being prompted for a password is attractive to many developers and architects. Through the use of Public Key Infrastructure (PKI) the machines can “trust” certain keys and allow remote access.
This is great and many would ask, “What's your beef with it Jamie? You're just a grumpy paranoid old man.” Yes, I am. My beef is that this technique often gets abused and is sometimes deployed in a sloppy manner.
If you're going to use hands-free logins, please consider a couple of things. First of all, restrict access to the OpenSSH daemon through the use of host-based (iptables) firewall and network-based firewalls.
Also, restrict who (which users) can login using configuration options such as DenyUsers, AllowUsers, DenyGroups, and finally AllowGroups. Some system administrators create a user group called “sshusers” and then set “AllowGroups sshusers” in the configuration file. Then assign the “sshusers” as the secondary group to user accounts to login via Secure Shell.
Administrative, shared accounts such as Oracle should NEVER be logged into directly. Furthermore, “PermitRootLogin” should be set to “no” to prevent direct login to the root account.
As an added layer of protection ensure the “StrictModes” value is set to “yes”. Sometimes users, and system administrators, get sloppy and relax the discretionary access controls on user home directories where the SSH credentials are stored.
Finally, I would ensure that the Secure Shell service is using the strongest encryption possible and is only configured to accept protocol version 2 connections. Set the following in /etc/ssh/sshd_config:
Protocol 2 Ciphers blowfish-cbc,aes256-cbc,aes256-ctr,aes192-cbc,aes192-ctr,aes128-cbc,aes128-ctr
I hope this article got you thinking about how you use Secure Shell. I encourage you to read the various security guidelines and other recommendations that are available. In the end, however, one of the best defenses is diligence by system administrators who review and remove inactive user accounts and are aware of how their architecture is configured.
1. Network Working Group of the IETF, January 2006, RFC 4252, The Secure Shell (SSH) Authentication Protocol
0 comments:
Post a Comment