Now that I’ve had (just over) a month to settle into my new role here at UK hosting company 34SP.com as a Systems Administrator, it would be quite fitting that I should be writing a highly technical, complex entry on the company web blog, particularly when you consider the content of my second-life as a 34SP.com customer.
However, as it happens, I’m going to start with a relatively simple topic that has application to all accounts including reseller hosting and VPS. I’m going to talk specifically about SFTP, or the SSH File Transfer Protocol.
But What’s Wrong with FTP?
Many of you will have noticed, and indeed some of you may have even been the victim of, hacks to your website hosting by attackers logging-in via FTP and defacing your website for what is usually profitable gain. It’s unfortunate that there are still a modicum of support requests from clients who have fallen foul of such attacks.
These attacks aren’t simply limited to 34SP.com accounts, nor are they limited to the use of one particular server Operating System or configuration. Whilst many can often be quick to demonise the use of overly-simple passwords (i.e. dictionary words, words with trailing numbers, passwords consisting of numbers) due to their inherent vulnerability to brute-force or dictionary attacks, it isn’t always the case that a user falling victim to an attack had a particularly weak password.
The reality today is that brute-forcing requires far too much effort for an attacker. Who would really want to wait for a script to try two million passwords, only to find out that none of them worked? Yawn! I don’t think I’d waste my time doing that… And of course neither would any self-respecting attacker, particularly when there’s an easier option to hand.
Ignoring the probability of any infection of a user’s local machine with malicious software, or the susceptibility of the user to social engineering attacks (which in themselves prevent far more serious ramifications than FTP security) the possibility also remains for attackers to intercept information that is transmitted across the Internet in plain text. It is for this very reason, that HTTP’s secure alternative, HTTPS, is widely used across the web for mediating secure transmission of information to and from such systems as control panels and e-commerce sites. Of course, nobody would wish their credit card details to be transmitted across a shared medium, for all to see. So why would you want the login details to your website transmitted in a similar fashion?
So How Can I Protect My FTP Traffic?
FTP, like HTTP, transmits all data between the client and server without any form of encryption, which in the case of an FTP login command, also includes your private username and password. Unfortunately FTPS (or FTP-SSL) is seldom used in practice due to the requirements (and cost) of maintaining signed SSL certificates. Whilst the benefits are routinely accepted for the use of HTTPS, this practice is less than desirable when considered as a global replacement for every single FTP connection.
SFTP works quite differently: it relies upon the SSH (Secure SHell) protocol to create a secure ‘tunnel’ with which to transmit FTP traffic. Similarly, SCP operates in the same way, but does so with reduced capabilities for the user. The security of SSH is provided by RSA public/private keypairs, as opposed to requiring costly SSL certificates. This reduces the complexity in setup and reduces the cost of deploying a secure FTP service, whilst thankfully maintaining a level of security that would thwart the persistent of traffic-intercepting attacks.
Great! But How Do I Use It?
Given the longstanding acceptance of FTP as the de-facto standard for publishing files to web space, there are a great many hurdles to overcome in the road towards the widespread adoption of secure file transfer methods. Education is one such hurdle: many, many users are unaware of the dangers involved in the transmission of insecure data, or even that secure alternatives exist.
Similarly, the Plesk Server Admin (as of version 8.6.0) doesn’t support SFTP natively. However, the demand of such features led to the deployment of an in-house extension, enabling all of our Linux/UNIX-based hosting servers to provide simultaneous SFTP and SCP access alongside traditional FTP. By providing ‘shell’ access with a limited set of allowed commands, access to your web space via secure file transfer protocols can be implemented without any particularly difficult modifications to the standard features of Plesk.
In order to take advantage of SFTP (and SCP) you will need to obtain a SFTP/SCP-compatible client: as an example, WinSCP is a free and intuitive client for Windows users.
The only caveat to this feature at present, is that it is still controlled by the FTP lock, so if you decide to disable FTP access on a particular domain; SFTP and SCP will no longer be available until FTP access is re-enabled. Similarly, it is not currently possible to disable FTP whilst retaining only SFTP access, though hopefully this is something we’ll be able to look towards implementing in the future.
So Now There’s No Chance That My Sites Will be Hacked?
Not exactly. Secure file transfer protocols serve only as a compliment to the continued use of strong (and secure) passwords. Similarly, if a user’s own system is compromised, then neither SFTP or SCP will be able to protect a user from an attacker. But when the final weakness is the FTP protocol itself, then it would appear that the time to switch to the widespread use of a more secure protocol would be a very prudent idea. Not just for the security of your own data, but for the good of the Internet as a whole.