FTP is Dead: Why Plain Text Protocols Have No Place in 2010

The "Coffee Shop" Attack Vector

I was sitting in a café in Oslo last Tuesday, running a passive packet capture on the open Wi-Fi just to see how much garbage traffic was floating around. Within ten minutes, I had the root credentials for three different servers. No sophisticated hacking, no brute force, just tcpdump and people still using standard FTP (File Transfer Protocol) to upload content to their web servers.

If you are managing infrastructure in 2010 and you are still running a daemon listening on port 21, you are practically inviting a breach. FTP was designed in 1971. The internet was a different place then. Today, with the proliferation of public Wi-Fi and packet sniffers, sending a password in cleartext is not just sloppy; it is dangerous.

At CoolVDS, we see this constantly. Customers migrate from shared hosting environments where FTP is the default, deploy a high-performance VPS, and immediately install vsftpd or proftpd without configuring TLS. They focus on the raw speed of our SAS RAID-10 arrays but leave the front door unlocked.

The Anatomy of a Leak

Let's look at exactly what happens when you authenticate via FTP. Below is a snippet from a Wireshark capture I ran in a controlled environment. This is what the guy sitting next to you sees:

USER admin
PASS SuperSecret123
230 Login successful.

It is right there. In ASCII. Anyone on the same collision domain—be it a hub, a switch with ARP spoofing, or an open wireless network—owns your server. Once they have that password, they don't just deface your website; they use your slice of the CPU to send spam or participate in a botnet, resulting in your IP getting blacklisted by Spamhaus.

The Solution: Native SFTP with OpenSSH

Many sysadmins confuse SFTP (SSH File Transfer Protocol) with FTPS (FTP over SSL). While FTPS works, it is a pain to configure through firewalls because of the passive port ranges required. SFTP is superior because it tunnels everything over a single port: 22.

Historically, the problem with SFTP was that it required giving the user full shell access. You didn't want your web developer poking around /etc/ just to upload a PHP file. However, since OpenSSH 4.8p1 (which is standard in our CentOS 5 and Ubuntu 10.04 LTS templates), we have access to the internal-sftp subsystem and ChrootDirectory directive.

This allows us to restrict users to a specific directory without giving them shell access, effectively mimicking the isolation of FTP but with the ironclad security of SSH.

Step 1: Configure sshd_config

Open your configuration file. On a standard CoolVDS CentOS instance, this is located at /etc/ssh/sshd_config.

We need to comment out the default subsystem and replace it with the internal one. This avoids the need to copy binary libraries into the chroot jail, which was the old, painful way of doing this.

#Subsystem sftp /usr/libexec/openssh/sftp-server
Subsystem sftp internal-sftp

# Add this at the bottom of the file
Match Group sftponly
    ChrootDirectory /home/%u
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no

Pro Tip: Ensure the ChrootDirectory is owned by root and not writable by any other user or group. This is the most common point of failure. If the permissions are wrong, OpenSSH will refuse the connection to prevent a jailbreak.

Step 2: Create the User and Group

Now we create the group we referenced in the config and add a user to it. We also set their shell to /bin/false so they can't bypass the SFTP restriction via SSH directly.

groupadd sftponly
useradd -d /home/johndoe -s /bin/false -g sftponly johndoe
passwd johndoe

Step 3: Fix Permissions

This is the part that trips up 90% of administrators. The directory defined in ChrootDirectory (/home/johndoe) must be owned by root. The user can only write inside a subdirectory of that chroot.

chown root:root /home/johndoe
chmod 755 /home/johndoe

# Create the upload directory
mkdir /home/johndoe/public_html
chown johndoe:sftponly /home/johndoe/public_html

Step 4: Reload SSH

Do not restart SSH if you can avoid it, just in case you made a syntax error and lock yourself out (though CoolVDS offers an out-of-band VNC console for such emergencies). Reload the config instead:

/etc/init.d/sshd reload

Performance Considerations

Some argue that encryption adds overhead. In 2010, this argument is largely academic. Modern CPUs, like the Intel Xeons we use in our Oslo data center, handle AES encryption with negligible impact on latency.

In our benchmarks, transferring a 500MB tarball via SFTP versus FTP showed a time difference of less than 2%. The bottleneck is rarely the CPU; it's the disk I/O and network throughput. This is where the underlying infrastructure matters. A secure protocol running on a slow disk is still slow.

By using CoolVDS instances backed by high-RPM SAS RAID arrays or our new Enterprise SSD tier, the I/O wait times are so low that the encryption overhead is invisible. You get security without the penalty.

Compliance and The Norwegian Context

Operating in Norway means adhering to the Personopplysningsloven (Personal Data Act). The Data Inspectorate (Datatilsynet) is increasingly strict about how personal data is handled. If you are transferring customer logs or database dumps containing personal ID numbers via cleartext FTP, you are likely in violation of the requirement to secure data "appropriate to the risk."

Moving to SFTP isn't just a technical upgrade; it's a compliance necessity. It ensures that data in transit within the NIX (Norwegian Internet Exchange) remains opaque to prying eyes.

Final Check

Before you close your terminal, verify the setup from a separate machine:

sftp johndoe@your-server-ip

If you see the prompt and are locked into the public_html directory, you have successfully hardened your file transfer process. If you are still using FTP today, kill the daemon. Right now. Your uptime—and your reputation—depends on it.