Stop Broadcasting Your Passwords: The End of FTP
If you are still using standard FTP (File Transfer Protocol) in 2010, you are essentially broadcasting your root passwords and customer data to anyone with a packet sniffer. It doesn't matter how strong your iptables rules are or how complex your password is. If it travels over port 21, it travels in plain text.
I recently audited a client in Oslo who couldn't understand how their e-commerce platform was compromised. They had strict firewalls, decent patching policies, and locked-down SQL injection vectors. The culprit? A freelance developer updating the public_html folder from a coffee shop using standard FTP. A script kiddie running a simple sniffer on the same open Wi-Fi network captured the credentials in milliseconds.
At CoolVDS, we see this too often. It is time to retire FTP. The alternative isn't FTPS (which is a nightmare to firewall due to the passive port range issues); the answer is SFTP (SSH File Transfer Protocol).
The Danger of Cleartext
To demonstrate why FTP is unacceptable for professional hosting, let's look at what happens on the wire. If I run tcpdump on a server while someone logs in via FTP, this is what I see:
# tcpdump -i eth0 -A port 21
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
14:22:11.842132 IP 192.168.1.10.3421 > server.coolvds.net.ftp: Flags [P.], seq 1:14, ack 1, win 65535, length 13
E..5..@.@......
...=...P.!.Y....USER admin
14:22:11.842245 IP 192.168.1.10.3421 > server.coolvds.net.ftp: Flags [P.], seq 14:26, ack 1, win 65535, length 12
E..4..@.@......
...=...P.!.f....PASS s3cr3t123
There it is. PASS s3cr3t123. Clear as day. Under the Norwegian Personal Data Act (Personopplysningsloven) and Datatilsynet regulations, allowing this kind of vulnerability when handling customer data is negligence.
The Solution: Native SFTP Chroot with OpenSSH
Historically, locking users to their home directories via SSH/SFTP was painful. You had to use rssh or set up complex chroot jails copying /bin/bash and libraries. However, recent versions of OpenSSH (starting with 4.8, and standard in our Ubuntu 10.04 LTS and CentOS 5.5 images) introduced the internal-sftp subsystem.
This allows us to handle SFTP requests in-process without needing a shell executable, making it secure, lightweight, and easy to configure.
Step 1: Configure sshd_config
First, backup your config. Then, edit /etc/ssh/sshd_config. We need to tell the SSH daemon to use the internal subsystem and define a match block for our file-transfer users.
# /etc/ssh/sshd_config
# Comment out the default subsystem line:
# Subsystem sftp /usr/lib/openssh/sftp-server
# Use the internal subsystem instead:
Subsystem sftp internal-sftp
# Configuration for sftp-only users
Match Group sftponly
ChrootDirectory %h
ForceCommand internal-sftp
AllowTcpForwarding no
X11Forwarding no
Pro Tip: TheChrootDirectory %hdirective tells SSH to change the root directory to the user's home folder. TheForceCommand internal-sftpprevents them from getting a shell prompt. If they try to SSH in normally, the session will close immediately. This is crucial for security on a production VPS.
Step 2: Permissions Architecture
This is where most sysadmins fail. For ChrootDirectory to work, the directory must be owned by root and not writable by any other user or group. The user is then locked inside, so you need a subdirectory for them to actually write files to.
Here is the exact command sequence to set up a user named webdev:
# Create the group
groupadd sftponly
# Create the user with no shell access
useradd -d /home/webdev -g sftponly -s /bin/false webdev
# Set the password
passwd webdev
# Fix permissions for the Chroot (MUST be root:root and 755)
chown root:root /home/webdev
chmod 755 /home/webdev
# Create the writable content directory
mkdir /home/webdev/public_html
chown webdev:sftponly /home/webdev/public_html
chmod 755 /home/webdev/public_html
Step 3: Restart and Verify
Reload the SSH daemon to apply changes:
# On CentOS / RHEL
service sshd reload
# On Debian / Ubuntu
/etc/init.d/ssh reload
Why Hosting Architecture Matters
You might ask, "Why can't I do this on my cheap shared hosting plan?" The answer is simple: Shared hosting providers rarely give you root access to modify sshd_config. They cram thousands of users onto a single kernel.
This is why serious teams in Norway move to Virtual Dedicated Servers. On a CoolVDS instance, you have your own isolated OS environment. We use Xen virtualization (and are testing KVM), which guarantees that your resources are yours. When you edit network configurations or security policies, you aren't restricted by a control panel's limitations.
Performance Considerations
Encryption adds CPU overhead. Years ago, this was a bottleneck. Today, even our entry-level VPS nodes run on enterprise-grade hardware with powerful multi-core Xeon processors and high-speed RAID-10 SAS storage. The latency overhead of SFTP encryption is negligible compared to the security benefits.
| Feature | FTP | SFTP (CoolVDS Standard) |
|---|---|---|
| Encryption | None (Cleartext) | Full (SSH2) |
| Firewall Ports | Complex (20, 21 + Passive Range) | Simple (Port 22 only) |
| Compression | Optional/Rare | Built-in (zlib) |
| Compliance | Fails Datatilsynet Stds | Compliant |
Client Configuration
For your developers, switching is seamless. In FileZilla, simply change the "Server Type" from FTP to SFTP. In WinSCP, it defaults to SFTP.
Remember, latency matters. If your target audience is in Scandinavia, hosting your data in the US or Asia introduces significant lag, making file transfers sluggish. Our data center is connected directly to the NIX (Norwegian Internet Exchange), ensuring your SFTP sessions are snappy and responsive.
Final Thoughts
Security is not about convenience; it is about discipline. Moving from FTP to SFTP is one of the lowest-hanging fruits in server hardening. It costs you nothing but a few minutes of configuration, yet it eliminates a massive vulnerability class.
Don't wait for a data breach to upgrade your infrastructure. If you need a sandbox to test these configurations without risking your live environment, spin up a CoolVDS instance. With full root access and high-performance I/O, you can build a security fortress that actually performs.