FTP is Dead: Why Smart SysAdmins in Norway are Locking Down Port 21

If you are still running a standard FTP daemon on your production servers, you might as well print your root password on a flyer and hand it out at Oslo Central Station. It is August 2011, and the days of transmitting credentials in cleartext are over. Yet, I still see legacy hosting providers in the Nordic region offering default FTP access as a "feature."

It is not a feature. It is a liability. In an era where packet sniffing is trivial—tools like Wireshark and tcpdump are standard in every script kiddie's arsenal—relying on the File Transfer Protocol (RFC 959) is negligent. I recently audited a client's infrastructure after a breach; the attacker hadn't used a zero-day exploit. They simply sat on the same unencrypted public Wi-Fi node as the developer and sniffed the FTP login sequence. Game over.

For those of us managing critical infrastructure, specifically here in Norway where the Personopplysningsloven (Personal Data Act) and Datatilsynet enforce strict handling of sensitive data, moving to SFTP (SSH File Transfer Protocol) isn't optional. It is the baseline.

The Anatomy of a Disaster: Why FTP Fails

Standard FTP operates on a dual-port basis (Command and Data), but its fatal flaw is authentication. When you connect to ftpd, your username and password are sent as plain ASCII text strings.

Here is what a hacker sees when you log in via FTP using a simple `tcpdump` on the gateway:

# tcpdump -A -n -i eth0 port 21
14:22:11.98231 IP 192.168.1.105.5432 > 85.x.x.x.21: Flags [P.], seq 1:14, ack 1, win 65535, length 13
USER admin

14:22:12.18231 IP 192.168.1.105.5432 > 85.x.x.x.21: Flags [P.], seq 14:25, ack 1, win 65535, length 11
PASS Secret123

There it is. Secret123. No decryption required. If you are managing a high-traffic e-commerce site or handling customer databases, this is unacceptable.

The Solution: Native SFTP with OpenSSH

Unlike FTPS (FTP over SSL), which can be a nightmare to configure through firewalls due to ephemeral port ranges, SFTP uses the SSH protocol. It runs over a single port (usually 22), is fully encrypted, and requires no complex NAT traversal configurations.

Many admins hesitate to switch because they believe SFTP gives users full shell access. In older versions of OpenSSH, this was a valid concern. However, with the recent improvements in OpenSSH 5.x (standard in Debian 6 Squeeze and CentOS 6), we can now use the internal-sftp subsystem to chroot users to their home directories without giving them a shell.

Configuration: Creating a Chrooted SFTP Jail

Let's configure a secure file transfer environment on a CentOS 6 or Debian 6 server. This setup ensures that the user can transfer files securely but cannot run commands or snoop around /etc/.

Step 1: Edit the SSH Daemon Config

Open /etc/ssh/sshd_config with your preferred editor (vi or nano):

vi /etc/ssh/sshd_config

Find the line referring to `sftp-server` and replace it with `internal-sftp`. Then add a `Match Group` block at the very end of the file:

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

# Rules for sftp-only users
Match Group sftponly
    ChrootDirectory %h
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no

Step 2: Create the User and Group

Now we create the group and a user, ensuring they don't have a valid login shell:

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

Step 3: Fix Permissions (Crucial!)

For ChrootDirectory to work, the directory owned by root must not be writable by the group or others. This is where most setups fail.

chown root:root /home/clientsite
chmod 755 /home/clientsite

# Create a writable directory inside for uploads
mkdir /home/clientsite/public_html
chown webmaster:sftponly /home/clientsite/public_html

Step 4: Reload SSH

service ssh reload
# Or on RHEL/CentOS:
service sshd reload

Pro Tip: Always keep a secondary SSH session open when modifying `sshd_config`. If you make a syntax error and restart the service, you could lock yourself out of the server. Run `sshd -t` to test the configuration file before reloading.

Latency, Encryption, and Performance Overhead

Transitioning to SFTP does introduce a slight CPU overhead due to the encryption/decryption process. On legacy hardware or overloaded shared hosting, this can bottleneck transfer speeds. This is why the underlying architecture of your VPS matters.

At CoolVDS, we don't oversell our CPU cores. When you initiate an encrypted handshake, you need raw integer performance. Our infrastructure is built on enterprise-grade hardware with RAID-10 SSD storage (Solid State Drives). While traditional SAS drives struggle with the random I/O often generated by multiple concurrent SFTP sessions, SSDs handle this with near-zero latency.

The Norwegian Advantage

For developers targeting the Norwegian market, network topology is key. Using a generic US-based host adds 100-150ms of latency to every packet. Because SFTP is an interactive protocol (it acknowledges packets frequently), high latency kills throughput speeds drastically compared to streaming protocols.

CoolVDS servers are peered directly at NIX (Norwegian Internet Exchange) in Oslo. This ensures that your SFTP sessions—and your HTTP traffic—benefit from sub-millisecond routing within the country. Furthermore, hosting data within Norway simplifies compliance with the Personal Data Act (Personopplysningsloven), keeping the Data Inspectorate (Datatilsynet) happy.

Conclusion: Close Port 21 Today

There is no excuse for running unencrypted file transfers in 2011. The tools are mature, the bandwidth is available, and the security risks are too high to ignore. By implementing the configuration above, you secure your clients' data and professionalize your workflow.

Security requires resources. Don't let slow mechanical hard drives or congested networks bottleneck your secure transfers. Experience the difference of pure SSD performance and local peering.

Ready to lock down your infrastructure? Deploy a secure, high-performance Linux VPS instance on CoolVDS in under 60 seconds.