We spend a lot of time and money trying to keep our systems secure. From security patches to intrusion prevention systems, we attempt to fortify our systems from the hackers while not frustrating our end users. We remind users to choose good passwords and keep their systems free from viruses. If we are diligent, we check for new security patches frequently and carefully monitor our systems for signs of mischief. Despite these efforts, we often let clear text protocols slip into the mix of our internet operations and possibly compromise all of our efforts. We first touched on this topic in our May issue, but we now have a much more complete overview of the topic in an effort to convince you to make the switch.
What are clear text protocols? You are likely using one right now (HTTP). Clear text protocols are communication methods that do not encrypt data. They include popular services like POP3 and remote MySQL connections. Using a clear text protocol is akin to writing a letter to someone on the outside of an envelope. Anyone handling your letter could easily read its contents. Similarly, when you login to check your email using POP3, anyone with access to the network path could capture your login information and other contents using a packet sniffer. Popular programs like Ettercap make this easy to do.
We’ve long seen people warn against using telnet to login into our systems. “Don’t use telnet!” is a mantra often posted in many online forums. People mention POP3, IMAP, SMTP AUTH, and MySQL less frequently. Though technically, all of these protocols also send your password data in plain text. Just like we’ve long abandoned telnet we should also abandon these other protocols for secure ones. How many times does your system check your POP3 account a day? If your computer is on all day and checking your email every minute, then you send out your password 1440 times a day.
Fortunately, if you are running a server with RedHat 7.x or later, you likely already have secure protocols installed. By default, many popular control panels, such as Ensim, Plesk, and cPanel, already use secured methods for email communications. We will not focus on secure remote MySQL connections in this article but on email, shell and file transfers. Worth noting is that MySQL did introduce SSL secured connections in MySQL 4.0, so options are available. Implementing secure email communications is straightforward but will likely require changes on behalf of your end users.
Most systems use SSL to secure these common clear-text communications.
SSH for Telnet
Telnet has long been derided and many people have now switched to SSH or secure shell. Unlike telnet, SSH creates an encrypted communications tunnel between you and the server. When you login, your connection is secured using the secure socket layers or SSL. This is similar to the security protocols used to secure HTTP through HTTPS. If you are still using telnet to administer your server, STOP! Though your server may be secure, you never know if another server on your subnet may be compromised, this is especially true when leasing systems from dedicated hosting providers. Someone could compromise another server on the subnet and simply install Ettercap. When you logged in, your passwords, commands and all data you transmit via telnet could be captured. If you use SSH, the data can still be captured but it is encrypted. Breaking the encryption is theoretically possible but would take a very long time – possibly hundreds of years.
Most Linux distributions already have a command line SSH client, but if you are using Microsoft Windows, there are many options as well. We prefer the commercial SSH client from SSH. Pricing is around $100 (US) but the built in profile features, sftp client and other options make it worthwhile if you find yourself needing to access a server daily. For less frequent use or for tight budgets, consider the ubiquitous Putty, a free SSH client.
SFTP/SCP for FTP
FTP is easy to use and you have likely been using it for years. However, like telnet it sends your password as plain text. A hacker could sniff your password and then use it to hijack your FTP server. We’ve dealt with a few of these cases where your system is quickly turned into a warez dump to distribute illegal copies of software, music and videos.
If you have a newer FTP client, it may already support secure FTP. Secure FTP is an FTP connection using an SSL secured network connection. All data sent, including your password, is secured. SSH has a sub-process to provide SFTP support. If your client supports SFTP, then you likely just need to toggle a setting.
SCP is secure copy. Though it achieves the same end result as SFTP it uses a slightly different method. Most Linux systems already have the scp command available. You can use it to transfer file securely from one server to another. If you are using MS Windows, then there is a great, free SCP client called WinSCP. This is an intuitive, easy to use SCP client that supports a variety of options including pausing and resuming uploads and downloads.
Securing Email
The two most popular methods for getting your email are IMAP and POP3. These protocols also have secure replacements, IMAPS and POP3S, which secure the connection using SSL. Your server likely supports these methods already. One issue with using these methods is that you have to reconfigure your email client. In MS Outlook, you can find the settings under the advanced tab. There is a checkbox that says: “This server requires an encrypted connection (SSL)”. Upon checking the box, you may notice that the port numbers change. On most systems, POP3S and IMAPS run on their own ports, 995 and 993, respectively. There are not other changes required. Checking email will proceed as it has in the past but now you will be connecting through an SSL secured connection.
When you send email, you use SMTP, simple mail transport protocol. Like POP3 and IMAP, most servers also include the ability to use an encrypted SMTP protocol. SMTP is a bit more complicated than IMAP and POP3. One issue is that there are a number of different SMTP servers that are in widespread use. Ensim uses Send Mail, Plesk uses Qmail, and cPanel uses Exim. Each of these control panels uses its own method and sometimes a unique port for using a secure SMTP connection. Newer versions of Send Mail include TLS, which I’ve not seen work well with MS Outlook but works well with Mozilla Thunderbird. Secure SMTP is typically on port 465, so in your email client you will likely need to change the setting to use this port.
An important note is that these methods do not secure your email from end-to-end. POP3S, IMAPS and SMTPS only secure the connection between your system and the server, but it is this connection in which you are transmitting your passwords, so securing it is just like abandoning telnet in favor of SSH.
Email SSL Certificates
One issue some users may have is a pop up about a security certificate. We’ve seen varying results. Some versions of MS Outlook, Eudora and Thunderbird may trigger a pop up about an SSL certificate not matching or being not trusted. Your system’s security settings may determine if this pop up appears. If it does, you may need to get an SSL certificate for your email services. One issue is that your server can only use one certificate for email. This can be problematic if you are providing virtual hosting and your clients are using mail.domain.com for their POP3 server settings. Typically, you install a certificate that matches the hostname of your server. Your clients then must use this hostname in their POP3 settings to use secure POP3 without getting the pop up. Unlike browser certificates, you can often use an inexpensive certificate like FastSSL because browser compatibility is not an issue with email. The same certificate can be used to secure your SMTP server which may also produce pop ups.
Conclusion
If you operate a server for your own use or just a few clients, switching to encrypted communication protocols should not require too many changes. Your clients may need to update their email settings and you may need to purchase an SSL certificate. Switching to SSH may require you to download Putty or purchase a commercial SSH client. Your FTP client of choice may already include SFTP support. Since you likely already have the necessary components, switching to SSL encrypted communications should be easy requiring one-time configuration changes to provide ongoing security. Hopefully newer programs will start enabling these secure settings by default.
If you are a providing mass virtual hosting, then switching may be more cumbersome. One suggestion is to stop offering FTP on new accounts and include links to programs like WinSCP. If you present a clear case for using the secure methods, you may find new clients to be very receptive. Switching access for existing clients can be problematic. For the few clients that we know that have switched, they have done so gradually. They have notified their users of the change months in advance. They then provide a probation period for users that failed to switch and finally stop providing services like telnet and FTP.
We recommend to all clients to slowly phase out clear text protocols such as telnet, ftp and pop3/imap. We would hate to see your system hacked simply because you were sending your password in plain text some 1400 times a day.