Managing Unix servers often requires command-line access, which means using a SSH (Secure Shell) environment, and possibly directly accessing that environment via the Internet. Modern Unix distributions come with SSH pre-configured,
If you have command-line access to Unix servers but are still using Telnet, stop. Using unencrypted communications to manage your systems is not an acceptable risk.
If you have command-line access to Unix servers but are still using Telnet, stop. Step away from the keyboard, and replace Telnet with SSH. Right now, begin using SSH. Do it for me, and if not for me, for your company's sake. Using unencrypted communications to manage your systems and to pass around plain-text passwords is not an acceptable risk, and there are no technology barriers that should keep you from disabling all Telnet on servers and switching entirely to SSH.
SSH is most commonly used for Unix servers, but Windows admins can profit from this advice as well. SSH is a good low-bandwidth way to get into your Windows servers for occasional maintenance tasks. If you are linking Windows and Unix systems, you may want to look at using encrypted file transfer rather than normal CIFS. The SCP and SFTP protocols, useful for moving files between systems across untrusted networks, both run on top of SSH.
If you're using SSH already, here are some ideas to consider. Most of these Unix SSH example configurations can be done in a few seconds by simply changing the SSH configuration files (usually called /etc/ssh/sshd_config or /etc/sshd_config, depending on the flavor of Unix you're using).
- Change the SSH port number for any system that faces the Internet. SSH normally runs on port 22, but it doesn't have to. I suggest changing the port number to anything else you can easily remember. I find a lot of "222" servers out there, for example. Why do this? Well, not to increase security, because it doesn't actually increase anything but security-by-obscurity. Instead, I do it for one reason: to avoid the plethora of SSH scanners running on the Internet. These fill up logs with noise and potentially obscure true attacks, and they can trigger break-in evasion, which could result in a denial-of-service (DOS).
- Stop using passwords to access and manage your servers. We all know that passwords are awful:
easy to guess, steal, lose, and share. Public/private cryptography is used throughout the Internet
to help provide better authentication and increase security, so why not use it for your SSH access?
Yes, it does mean you now have to carry around your physical private key (and not lose it, share
it, or let it be stolen). But it does eliminate any possibility that a stolen
or guessed password will be used to compromise security. Generating the public/private key pair
for each user and configuring the SSH server only takes a few moments, but it raises the level of
security tremendously, and it's a cheap investment. Of course, when you do this, you also have to
disable password access, or you're defeating the point of the exercise.
This part of the tech tip really only works when the number of servers is small; if you have a farm of dozens or hundreds of systems, you should investigate some other form of centralized authentication, such as token-based access. If you don't like that idea, then consider the possibility of creating a bastion host that serves as the SSH gateway between the Internet and your local network. In this case, you'd only make the bastion host accessible via the Internet, use public/private key pairs for authentication to the bastion host, and then jump from the bastion host to servers in the organization using passwords. To really make this effective, configure the SSH servers on every other host to only allow logins from the known IP address of the bastion host.
- Don't let everyone log in. Many Unix servers have a small number of people who manage them, and a large number of other accounts that are only used for daemons or administrative separation of controls. Disable SSH access for everyone by default, and only allow real people to log in -- people you've listed specifically in the SSH configuration files. When I say "real people", I don't mean root. I always want people to log in as themselves using SSH first before using tools like su (super user) or sudo to gain privileged access. This helps in accountability and debugging. Many SSH servers have a specific configuration to disable root logins entirely, so even if you don't follow my suggestion to limit logins to a small list of users, you can disable root access via SSH easily.
Configuring a typical Unix server using Unix SSH along the lines I've suggested here will take an experienced Unix administrator less than 15 minutes, and perhaps one or two hours if you've never done it before. Either way, that investment in time will avoid problems and risks and increase security, a worthwhile goal for a network of any size.
About the author:
Joel Snyder is a senior partner at Opus One, an IT consulting firm specializing in security and messaging.
This was first published in December 2010