Stop Broadcasting Passwords: Why Plain FTP is Killing Your Security

If you are still running a standard FTP daemon (like vsftpd or ProFTPD) on port 21 without TLS, you aren't just managing a server; you are broadcasting your root credentials to anyone with a packet sniffer. In 2011, with the rise of public Wi-Fi hacking and sophisticated script kiddies, relying on the File Transfer Protocol designed in 1985 is not just outdated—it is professional negligence.

I recently audited a client's infrastructure here in Oslo. They were wondering why their e-commerce database kept getting injected with malware despite having strong firewalls. The culprit? A developer updating the site via FTP from a hotel lobby. Someone sniffed the cleartext password, logged in, and planted a backdoor. Game over.

The Reality of Cleartext: A "Tcpdump" Nightmare

Standard FTP sends your username, password, and data in plain text. If you run a simple tcpdump on the gateway, you can read the credentials as easily as the morning newspaper. This violates every security principle we stand for, and frankly, it puts you at odds with Datatilsynet (The Norwegian Data Inspectorate). Under the Personal Data Act of 2000, failing to secure sensitive data transfer is a compliance disaster waiting to happen.

The solution is not "FTPS" (which is a pain to firewall due to the passive port range issues). The solution is SFTP (SSH File Transfer Protocol). It runs over a single port (22), is fully encrypted, and if you are using a decent VPS provider, it's already installed.

Configuring Chrooted SFTP on Debian Squeeze / CentOS 6

One historical complaint about SFTP was that it gave users full shell access. You didn't want your web designer roaming around /etc/. Fortunately, OpenSSH versions 4.8+ introduced the ChrootDirectory directive, making it easy to lock users into their home folders.

Here is the battle-tested configuration we use on our CoolVDS instances. This works for both Debian 6 and RHEL/CentOS systems.

1. Edit your SSH Configuration

Open /etc/ssh/sshd_config. We need to replace the default sftp-server with the internal-sftp subsystem, which does not require helper files inside the chroot jail.

# Comment out the old line
# Subsystem sftp /usr/lib/openssh/sftp-server

# Use the internal subsystem
Subsystem sftp internal-sftp

2. Create the Restriction Group

Add the directives to the bottom of sshd_config to match a specific group. This tells SSH: "If a user belongs to the group sftponly, force them into SFTP mode and lock them in their directory."

Match Group sftponly
    ChrootDirectory %h
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no

3. Restart SSH

Warning: Always keep a secondary root session open in case you syntax-error yourself out of the server.

/etc/init.d/ssh restart (Debian) or service sshd restart (CentOS).

4. Permissions Architecture

This is where most admins fail. For ChrootDirectory to work, the directory owned by root must not be writable by the user. The structure should look like this:

/home/clientsite/       <-- Owned by root:root, Permissions 755
/home/clientsite/www/   <-- Owned by user:sftponly, Permissions 755

The user uploads files into the www folder. If you try to make the chroot root writable by the user, OpenSSH will refuse the connection instantly to prevent jailbreaks.

Latency, IO, and The CoolVDS Edge

Security adds overhead. Encryption requires CPU cycles. On a sluggish, oversold VPS where the host node is gasping for air, switching to SFTP might drop your transfer speeds slightly. This is simply the cost of doing business securely.

However, architecture matters. At CoolVDS, we utilize KVM virtualization rather than OpenVZ for our premium tiers. This ensures that your encryption overhead isn't fighting for CPU time with a noisy neighbor. Furthermore, our infrastructure in Oslo connects directly to NIX (Norwegian Internet Exchange), ensuring that even with the encryption overhead, your latency remains in the single digits for local transfers.

Pro Tip: If you are transferring massive backups (GBs in size), SFTP encryption can bottleneck on the CPU. In trusted internal networks (like between a web node and a backup node in the same datacenter), use netcat or unencrypted rsync over a private VLAN. But over the public internet? Never.

Conclusion

There is no excuse for using plain FTP in 2011. The tools to secure your transport layer are built into the OS. It takes five minutes to configure sshd_config correctly, protecting you from data leaks, compliance violations, and the embarrassment of a compromised server.

Don't let legacy protocols be your downfall. Audit your ports today. If you need a sandbox to test these permissions without risking your production environment, spin up a test instance on CoolVDS. Our SSD-cached storage arrays are perfect for testing high-throughput secure transfers.