Author: Brian Warshawsky
VII. Thou shalt use encryption for insecure services
Believe it or not, security-related information can often be found in plain text floating around your network. I invite you to plug into the gateway to your network and capture traffic. At your leisure, go through the traffic and follow what you can follow. If you haven’t stressed the implementation of various encryption mechanisms within your servers and network, you’re likely to be shocked at what you will find. If you’re using Ethereal, look for a Telnet session and then select “Follow TCP stream.” You’ll see the entire Telnet session, login, password and all, naked to the world. The same goes for logins to internal Web pages that are not encrypted with SSL. If you add a wireless network into the equation without encryption, your troubles triple. Now malicious people don’t even need to physically be plugged into your network to catch valuable information.
There are easy ways to prevent these scenarios. A variety of encryption methods are available for a number of services, and in the event that one is not available for a specific requirement of yours, odds are that you can tunnel it yourself through SSH.
First let’s look at email. As a system administrator in a large production environment, you’re likely to have contact with various other administrators. Database administrators will need to talk to systems administrators, and outside resources might need to access servers to assist you with various problems that lie outside your realm of expertise. If this is the case in your work environment, I invite you to consider implementing a limited PGP email setup to use for these communications. Most email clients, including Thunderbird, Novell Groupwise, and Microsoft Outlook, support PGP encryption, and you can choose to encrypt only messages that are sensitive enough to warrant it. The PGP setup varies depending on your operating system and email client, but it is worth investigating in order to ensure that sensitive information doesn’t leak out to those who shouldn’t have it.
The vulnerabilities and inherent lack of security in Telnet are well-known, so we can shorten this topic to three words: Don’t use it! This goes for rlogin and rsh as well. Use SSH instead. SSH is fairly well established now, so for all but antiquated or legacy equipment this shouldn’t present much of an issue. If you have important network devices or servers that for whatever reason do not support SSH, consider adding a serial-port keyboard/video/mouse (KVM) switch to your setup so that you can attach securely to the KVM device, and limit your unencrypted traffic to the cable between the device and the KVM. If a serial KVM is too expensive, consider setting up a small Linux box with old surplus equipment that you can connect to serial-enabled equipment and SSH to. You can then use an application called minicom to communicate securely with your device.
If you have a Web application or portal page that takes usernames and passwords or allows employees or customers access to data, set it up utilizing SSL encryption. Nearly all browsers now support SSL, and its encryption will help prevent login information or other confidential records from becoming public knowledge. Using SSL used to mean that you had to purchase a verified SSL certificate, but nowadays you can create your own using Linux instead. This cuts down on both the cost and the time delay in deploying SSL on your Web application.
If you’re running Apache as your Web server, make sure you install mod_ssl to ensure proper functionality. Alternatively, you may choose to run Apache_SSL instead, which is a different version of Apache that incorporates SSL by default.
The worst place you can have unencrypted traffic is on your wireless network. I love the freedom of wireless networking, and I have it deployed both in my datacenter and across my entire campus. But I have seen wireless networks used by law firms and doctors’ offices without even the relatively weak WEP encryption enabled! Don’t let this happen to your network.
The most common method of encrypting a wireless network is to use WEP, but I recommend WEP encryption only as a last resort. Many access points now support more secure methods of encryption, such as WPA and AES encryption, though support for these on the client side can be spotty. It is also prudent to invest in a hotspot gateway for user authentication, which can help keep malicious users off your network in the event that they can crack the encryption. Cheap hotspot gateways can be found in the nocatauth project, or at www.mikrotik.com if you require a fully functional hotspot gateway.
Despite your best efforts, in some unfortunate cases an encryption mechanism may not be available. If a device running an unencrypted service offers an SSH server, then you’re in luck. It is possible to tunnel services through SSH in order to provide them with encryption. For example, you can configure SSH to encrypt remote syslog messages going from remote host to syslog server, or you could encrypt the traffic between yourself and a mail server. Tunneling through SSH is an excellent way to secure server-to-server and, in more limited cases, client-to-server communications. While a step-by-step guide on how to do this is a bit long for this article, you can find such a guide here.
Having said all this, it’s also important not to get carried away with the encryption. If the login methods and configuration changes are too complicated for your typical user, complaints and orders to change will win out over the supreme encryption scheme you’ve created. However, the benefits of a well-designed and -implemented encryption policy will make the time you spend putting them together well spent.
The commandments so far:
I. Thou shalt make regular and complete backups
II. Thou shalt establish absolute trust in thy servers
III. Thou shalt be the first to know when something goes down
IV. Thou shalt keep server logs on everything
V. Thou shalt document complete and effective policies and procedures
VI. Thou shalt know what cable goes where
VII. Thou shalt use encryption for insecure services
