You have most likely read over and over again articles on how insecure File Transfer Protocol (FTP) is, but have you ever taken a closer look at it? This post demonstrates how easily you can witness FTP’s vulnerability at the comfort of your home using some readily-available tools, as well as how to mitigate this threat.
FTP’s greatest weakness is security: all traffic is sent as clear text, including user names and passwords. If a third-party can get their hands on a copy of your traffic, they can compromise any resources protected with your credentials. All you need see this in action is access to an FTP server, FTP client and piece of software called packet analyser. In this demonstration I will use my Raspberry Pi as FTP server: it comes with vsftpd and OpenSSH sftp-server pre-installed with both FTP and SFTP features enabled by default. WinSCP will be used as FTP client, as it supports both FTP and SFTP connections. The sniffing software of my choosing is Wireshark – a popular, free and open-source network protocol analyser.
Observing insecure connection
First step of the procedure is setting up Wireshark to capture traffic on relevant network interface. In Capture Options, after ticking a check box against interface name, we also need to apply capture filter to discard packets that are of no interest to us in this exercise. Syntax is fairly straight-forward and only string we need to apply is ‘tcp port ftp’, which will capture all TCP traffic on port 21. If we applied no filters at all, it would be difficult to pinpoint FTP traffic among tons of other packets going to and from our client.
Once all is set, we can click Start and switch to FTP client. Fill in the usual details to make a connection – protocol to be used (FTP), host name, port, user name and password and click Connect. Since I am using WinSCP in this instance, it will also send few commands post-authentication to change remote directory etc. Once client made a successful connection, we can switch back to Wireshark, stop capturing packets and review the output.
In first couple of lines we can see TCP traffic establishing connection (SYN and ACK packets exchange) and then chatter between FTP server and client. In highlighted lines 5 and 9 we can see our user name and password being sent as plain text, line 11 confirms that credentials were correct. The fact that user have used a fairly strong password made no difference whatsoever to the security of this connection. While of course it is best practice to use hard-to-crack passwords, sending it in a form readable by everyone is not. Now that we have seen insecure connection in action, time to see what secure traffic looks like.
Observing secure connection
There is a lot of confusion around secure FTP, primarily because there are two distinctively different implementations of it and they are both referred to as… secure FTP. To get it straight, there is FTPS (FTP Secure or FTP-SSL) and SFTP (Secure FTP or SSH FTP). FTPS uses SSL certificates to secure the traffic, while SFTP establishes connection over SSH tunnel. Google is your friend*, you can look up differences between the two. If you are too lazy to do so, long story short SFTP is being a favoured protocol for several reasons, with single port setup (easier to get through firewalls) and more functionality on file permissions and attributes being some of them.
Back to our experiment, as stated at the beginning, we shall be using SFTP. Before we proceed, we need to amend Wireshark filtering options to capture relevant traffic. Let’s set our filter to ‘tcp port ftp or tcp port ssh’. While all we need is traffic on port 22, we use OR operand to capture communications on port 21 – only to prove there is nothing being transmitted on that port. Again, we can now click Start and switch to FTP client. Fill in the same details, with only differences being SFTP as protocol to be used and port number which should change automatically to 22. When ready, click Connect and observe the traffic.
As you can see, client and server are exchanging keys to secure the channel. Once connection is secured, the chatter between client and server is encrypted. Take a look at previous example and compare with this – all packets are now showing as encrypted so potential eavesdropper cannot make sense out of it without relevant keys at hand.
Secure it or not?
Before you jump the gun, you need to ask yourself a question if you have a valid reason to secure FTP traffic. For example, if you are running a public FTP share does it make sense to encrypt traffic to resources available to everyone? If your other system resources are protected with the same credentials that will be used to access FTP service it probably makes sense to protect those. Security comes at the cost of longer transfer times due to encryption overhead. You need to make an educated decision whether your system will benefit from enhanced security or not.
*The kind of fried who is always there for you, but also happens sit on a tree branch outside of your window to stalk you at 3 AM.