At this point, we can say that using telnet as a means of accessing servers is effectively dead. It took awhile, but the security concerns associated with it were finally elevated to the point where everyone finally made the choice to move to SSH. Why did we stop there? SSH provides one of the most secure methods of accessing a system and its services that is available anywhere. In addition, as you will see in this article, it can be used to access services that are traditionally not secure and should really never be used without it. Let’s dive in.
What Have I Got to Lose?
In short, everything. Do you use FTP to access your server to transfer files? Your password is transmitted in pure text. Do you browse HTTP to or from your server? Anyone listening in on your traffic between you and your destination can reassemble your entire browsing session. Do you use VNC to access your server? Your connection can be remotely monitoring and all traffic back and forth can be easily sniffed for sensitive information, including account names and passwords.
Then why do we do it that way? As we have no doubt heard, human beings do not like change. Using these tools is normal, securing them is changing how people work and that is always met with resistance and difficulty. Let’s see how a few simple things can eliminate some major security concerns.
Transfer and Copy
Strangely enough, some administrators do not realize how insecure some of their daily activities are. One of the easiest ways to eliminate a large portion of your risk in accessing public servers is not to use FTP or RCP. As we mentioned, these utilities are not secure and passwords are transmitted as plain text and can be easily monitored and mined for that information. What makes this so simple is that since SSH is likely already running, everything you need to secure those activities is as well.
FTP can be replaced by SFTP (FTP over SSH) and runs over a single port (whereas sometimes you need to open two ports in the firewall to allow normal FTP). RCP can be replaced by SCP (copy over SSH) and again, runs on a single port. In fact, since these are all SSH utilities, you only need ONE port (Port 22) open to allow all three to work.
Remote X Commands
You need to run that administration tool for your server widget and it has no command line facility (for shame)? You don’t need to run a full XWindows client (or VNC) then. If you have SSH running, you can use a simple command line switch to “tunnel” X commands to display on your local desktop, like so:
ssh -Y -l username servername
Note that in order for the remote GUI components to display on your local system, you have to have an XWindows server running on your local system. If you are running any Linux distribution on your desktop, you are all set as long as you are in Gnome/KDE/Unity/etc., it will just work and display the command. If you are on Windows, you can run CygWin or, if I can make a recommendation for a wholly contained SSH utility with extra tools and a built in XWindows Server with no configuration needed, MobaXterm. This works wonderfully for remotely running GUI commands and displaying them locally and securely.
The Whole Enchilada
So you need the whole desktop? OK, you can use SSH port redirection to secure your VNC access. We will make a few assumptions:
- VNC Server is already installed and configured
- Any firewalls that control incoming/outgoing access already are configured to allow Port 22 IN/OUT
- Your local system has a VNC client installed
- VNC Server is configured on Port 5901 (although if different, just swap out the example with your configuration)
With the above in mind, on your client system, execute the following command:
ssh -p 12345 -L 5901:127.0.0.1:5901 remotehost
What this does is create a listener for SSH on your local system port ‘12345’ (substitute whatever you want there) that will redirect local and remote port 5901 connection traffic to SSH. Voila! If you now open your local VNC client and connect to localhost, it will now ‘tunnel’ the connection over SSH and ‘redirect’ those unsecured ports to your secure and encrypted SSH client.
Risk, personal and professional, is something we all have to deal with every day in our increasingly online world. Many times, protecting ourselves and our company’s assets is as simple as changing some bad habits. As we see here, securing ourselves from easily exploitable security hacks involves very little effort on our part. Each of these tasks involved less than two minutes of actual work to make security a part of each activity. Once set up and in place, it adds nothing to the use of the tools but can protect you from the loss of time, money and possibly, employment. Let me know how you use SSH tunneling or port redirection in the comments below and good luck!