Technology Tip of the Month
by Deborah Healey
I have a website for my classes and personal storage ("Deborah's Attic") on a web server at Oregon State University that's set up for personal sites of faculty and students. I also maintain the website for the English Language Institute on the main Oregon State University server. Imagine my dismay to get a message saying that I needed to change my passwords immediately on both servers since they had been compromised. A hacker was trying to use the passwords to get beyond the spaces I control into other areas on the servers. Now, my passwords are not words in any dictionary, do not bear any relationship to my name or the names of any family members, and are pretty generally unguessable by normal standards. Clearly, my connection to the servers had been "snooped" by someone with the technical skill to intercept Internet transmissions.
Most people know that sending credit card and other confidential information over the web is risky unless the site is "secure" -- it's important to look for an address with https:// (the s stands for secure) or a closed lock in the bottom left corner to know that confidential information is encrypted so that it can't easily be intercepted. It's not as obvious that sending and receiving email with POP (such as Eudora or the default option in Netscape), sending information in a form on a non-secure website, using Telnet to connect to a host computer, or using a file transfer program such as WS-FTP or Fetch leaves the user vulnerable to electronic snooping.
Don't panic yet -- there's a bit more to the story. If you use a dialup line, you're much safer than if you're on a high-speed network line such as direct connection to the Internet, ADSP, or cable modem. That's because dialup lines generally give the caller a network address that's here today and gone as soon as you disconnect. A snooper may find your password, but the snooper won't be able to go anywhere with it, since there's no stable network address associated with the name and password. In the first place, you're unlikely to connect again and get the same network address; in the second place, the average user is unlikely to be connected at a predictable time each day. Then there's the bottom line -- people on dialup lines rarely have anything interesting enough to hack on their computers anyway. The effort is too great for the benefits to be derived.
If you're on a high-speed line with a permanent network number, however, you may have some legitimate concerns. Most of the time, there's little risk because English teachers are, frankly speaking, minnows in a very large Internet sea. Microsoft and IBM employees have access to much more interesting stuff than most of us do (yes, our lessons and the like are interesting to us, but really...). On the other hand, if you have an account on a university server, you could provide a gateway to opportunities for very interesting mischief. For the hacker, a university name and password are an entry point to trying out server addresses, looking for unguarded ports. Given the lack of expertise on the part of many server administrators, there are usually security holes to be found and exploited.
Even though most hackers aren't interested in ESL lesson plans, it's still possible for someone with access to your username and password to read your mail and add to or trash your website. Worse, if your name and password are used by a hacker, you're very likely to find yourself cut off from your mail and server until you show that you had nothing to do with the damage done by the hacker posing as you. Again, it's important to keep the risks in perspective -- people using small Internet service providers (Eugene FreeNet being a local example) and dialup connections are unlikely to be worth the effort. If you have access to a large server and do more than just email, however, you should be cautious.
The speed of downloads on an ADSL line is a joy: a 10MB file will download in a couple of minutes, rather than the hours it took with my 28.8 modem. That type of high-speed line also lets you have your phone line back, since it can transfer voice and data simultaneously on a single line. Once I had ADSL, I didn't want to go back to doing file transfers -- or even just looking at large web pages -- with anything else at home. At the same time, I was concerned about using Eudora, webmail, Fetch, and Telnet on my compromised high-speed line. The answer is something called Secure Shell. There are versions for Windows, Mac, Linux, and Unix machines. Several Secure Shell clients are available for Windows; check https: //www.betterbox.net/ssh/ or https://www.csri.utoronto.ca/~djast/ssh.html for information. These two sites also offer a substantial amount of background information about Secure Shell and Interet security. For Secure Shell on Unix, go to https://www.ssh.fi/sshprotocols2/download.html to download a free limited use copy. On the Mac, the choices are far more limited. I found one: F-Secure from DataFellows, which offers a one-month free trial and then costs $99 for the program. It's been worth it. DataFellows offers Windows and Unix versions, too, for $99 each. Unless you're on a Unix machine, you get what you pay for with the Secure Shell clients.
If all you want to do is Telnet, then it's very easy to set up a secure shell client. Install it, create a settings file for your server, and connect. The first time, the client will store a piece of information that will identify you to the server in future and will encrypt your information.
Here's a sample initial screen from F-Secure:
The only things I entered were my server name and my user name. The default worked fine for the rest. Getting more than Telnet set up generally takes more work, however, and unfortunately, what I really wanted to do was transfer files and protect my email.
The following is how to set up other applications on F-Secure. Other clients will use a similar process. There are two basic steps:
1) Find the port numbers for different Internet options, such as pop3 (110 in my system), the Web (usually 80), ftp-data (usually 20) and ftp-command (usually 21). If you connect with telnet and log into your server, you should be able to find these numbers in the etc/settings file. To get there, log into your server with telnet and try typing
at the prompt and press spacebar to go through, screen by screen. Write down the appropriate numbers as they go by. If you can't find that file, you'll need to ask your server administrator for the port numbers. You might try my numbers first and see if they work for you, of course.
2) Set up Tunneling/Forwarding. In F-Secure, you'll need to open the appropriate settings file, then click on Properties in the open settings dialog box. If you've already opened the settings file and closed the connection, you can select the Connection Properties option under the Edit menu. Select Forward (this may be called Tunneling in other clients), then click on Local. Click New to create a new setting.
Here's what a sample setup looks like:
The source and destination port are generally the same. The Name is whatever you choose to call this setting, mostly for your reference. The Destination Host is the address you want to connect to securely. It's important to check Allow local connections only so that this connection can't be snooped.
Once you've set up the Forwards you need, you can then open your connection via Secure Shell, then start up your other applications. The key to a secure connection, however, is one more step: connecting to the secure site that Secure Shell has set up for you. The network address of your secure site is 127.0.0.1 using F-Secure; other clients will give you the network address to connect to, if different. This means that you'll set Eudora or Netscape POP mail to connect to your login name @127.0.0.1 (for example, email@example.com in my setup); you'll start your secure web connection at https://127.0.0.1; and you'll set Fetch or other FTP client to go to 127.0.0.1. If the client won't connect to that secure location, make sure that the secure shell program is running and you've logged in.
The pursuit of security is not easy, and gets even more complicated when you want to set up secure file transfers. If you never need to move files to or from a server, you don't need to know this. If you do have a website and need to log in with a name and password to transfer files to it, then you'll have to bite the bullet on this one.
You actually have three options, but not all of them may be open to you. Your choices depend on your server and your ability to withstand non-graphical interfaces. The choices are listed in order of easiest to set up and hardest to do in the long run, to most complex to set up but easiest to use in the long run.
Option 1) Use command-line FTP on your secure shell client. This means you need to know the often obscure commands to change directories, locate files, and "get" or "put" the files you want in the format you want them. For me, the Mac file structure is just not set up to be friendly to a command line interface, and even the Windows file structure can be tricky if there are spaces in the folders and file names. This was an option to avoid if at all possible, as far as I was concerned.
Option 2) Connect to the server with anonymous ftp to upload files. Your server has to allow an anonymous ftp connection, and you need to remember the file names of everything you uploaded. Because you're using anonymous ftp, you log in as anonymous and send an email address as a password -- nothing you need to protect there -- so you can use any insecure program you like. Once the files are uploaded, you can use secure shell and telnet, then use telnet to get to the anonymous ftp site and move files from one place on the server to another. This part is another non-graphical operation. While do-able, it's not fun for the visual folks among us.
Option 3) Set up your secure shell client. This takes time to set up, but afterward, you can use whatever graphical client you like to upload and download files. It takes time because FTP is an odd sort of protocol. You need to set two ftp Forwards, one on the ftp-data port (20 in my case) and another on the ftp-command port (21 in my case). The next step is also important. You need to set your graphical ftp program, such as Fetch, to use passive ftp (PASV). Otherwise, your graphical ftp program will try to do things it can't do on this type of secure connection.
What I ended up with on my F-Secure Forward screen looks like this:
I have a pop3 and smtp setup for email with Eudora, ftp-data and ftp-command for Fetch, and webmail (web) for getting my Microsoft Exchange mail over the web. Great thanks go to my partner Steve Baker for his invaluable help in getting me through the frustration of reading instructions written for Unix programmers. From the little things like finding the etc/services file on a Unix machine to the big things like recognizing Forward as the key to what I wanted to do, the process wasn't made to be easy. I hope these instructions help you along the way.
After reading through this, you may ask yourself whether security is worth it. It's not as hard as it looks, and the peace of mind with secure high-speed transfers is wonderful.
If you have questions, comments, or for more information, contact Deborah Healey, dhealey AT uoregon DOT edu
Last updated 26 June, 2009