This section deals with finding a secure alternative to FTP and using Wireshark to check that it really is secure.
FTP, or "File Transfer Protocol" (see wikipedia) is a popular mechanism for downloading and especially uploading files. For the downloading it works in a similar way to the familiar HTTP protocol, except that the request is answered by an FTP server instead of a HTTP server. Many regular web browsers can handle FTP downloads as well, but there are of course many dedicated FTP clients, too numerous to list here.
The main difference with HTTP comes when you're uploading files instead of downloading them. There are two options for permissions when it comes to uploading - either the FTP server is set up to allow anonymous uploads, or it requires a username and password in order to authenticate. If anonymous access is allowed then you just need to enter "anonymous" as your username and anything you like as a password, and that's fine. For any system which restricts access, you need a valid username and a valid password to get in.
So far so good, and you can get any of the many GUI FTP clients out there to access your site. Some have more features than others, some are easier to use or more mature, you can even just ftp from the command line if you like. But there's one problem, in particular a problem with the authentication, for all of these clients. The problem is that the FTP mechanism for authentication is rubbish.
When you access an FTP server, it asks for your username and password. And then the client has to send this information back to the server, in plain text. Unbelievable, right? But it's true, your valuable authentication information is broadcast across the internet in plain sight. It's like writing a postcard to your bank with your account number and password on it. Anyone who handles the postcard on its way to the bank can read your private access details. And once they know them, they can access your FTP server.
So clearly it would be good to find an alternative means of accessing the server. And this is where SFTP comes in.
Firstly, beware because according to wikipedia this subject is a minefield. Confusing acronyms ahoy. There seem to be (at least) three possibilities of making FTP more secure:
So, we're going to only be looking at the first of these, or SFTP. Assuming that the server has been set up correctly (the server-side setup is a topic for another day), now you just need a client which supports the protocol and you're away.
There are a bunch of GUI FTP clients which support SFTP (once again, see wikipedia!), but some of them can be tricky to persuade to connect properly. Then again, some can be fussy about FTP settings too. Another alternative is using the command line sftp tool. It might not be as user-friendly as you like, but it works and with the tab autocomplete it's pretty quick. If you've ever used ftp from the command line before, sftp works pretty much exactly the same.
So you can open your connection with sftp username@ftp.website.com and it will prompt for your password. Enter this correctly and you can go to town with the commands cd (change remote directory), lcd (change local directory) and put (upload file or files). Everything seems to work fine and the uploads clearly work, but was that secure? Was that any better than using FTP? We need a way to test it.
Wireshark (see wikipedia) is a tool for analysing network packets, and lets you see what's going on on your network. We're going to use it to sniff what our FTP client is sending and therefore tell us what others could see from our traffic. In particular, our passwords.
Wireshark is already provided as standard in many distros, including Debian, so installing it is as simple as "aptitude install wireshark". And now we get a menu item under Internet. But that's only the GUI for the analysis, that's not the bit that does the packet collection.
At least on Debian, the GUI should be run as a regular user but the packet collection is a separate piece that has to be run as root. Well, in theory it should be possible to set it up so that a regular user could run it, at least for our simple scenario of capturing our own packets from our own machine, but as this is just a quick demo it's fine to run it as root.
One of the simplest ways to capture our own packets is to run dumpcap as root from a console, as this utility is included with wireshark. This is described in their man page. So to capture a minute's worth of data from our ethernet port, we can do this:
dumpcap -a duration:60 -w ~/output.pcap -i eth0
Then, once the minute is up and the file is written, you'll need to make it available to your regular user:
mv ~/output.pcap /home/user/ chmod a+r /home/user/output.pcap
Then as your regular user, start wireshark from the menu and open the file you've just saved. You can then scroll through the entries looking for interesting stuff.
After connecting via a regular FTP client (it doesn't matter whether it's a graphical one or a command line ftp tool), you can open the recorded file in Wireshark and if you scroll down a bit you'll probably see something like this:
FTP Request: USER marvin FTP Response: 331 Password required for marvin FTP Request: PASS DeliberatelyWrong
So there's the confirmation. If somebody else was capturing and listening to these packets flying backwards and forwards across the network, they'd easily see the client sending the username, the server responding with a password prompt, and the client then sending the password in clear text. That's obviously not what we want, so let's try again using sftp instead.
Doing the same thing again with the same client set up to use sftp, we see quite a different set of packets being exchanged - notice that they're not FTP packets any more. What can we see?
SSHv2 Client: Key Exchange Init SSHv2 Server: Key Exchange Init ... SSHv2 Encrypted response packet SSHv2 Encrypted request packet SSHv2 Encrypted response packet
So you can tell it's SSH, you can tell which host is being connected to, but you can no longer see the password and you can't even see the username any more. So that would seem to confirm that (as long as the encryption is working properly), the sftp is providing a much safer way of connecting to the server than ftp did.