Console Login
Home / Blog / Security & Compliance / Port 21 is Dead: Securing File Transfers in a Hostile Network Environment
Security & Compliance 9 views

Port 21 is Dead: Securing File Transfers in a Hostile Network Environment

@

Stop Broadcasting Your Root Password to the World

It is 2011. We have fiber connections, multicore processors, and reliable virtualization. Yet, for some reason, I still see developers FTPing into production servers from open Wi-Fi networks in Grünerløkka.

Let's be brutally honest: if you are using standard FTP (File Transfer Protocol) on Port 21, you are transmitting your username, password, and data in clear text. Anyone with a copy of Wireshark and a promiscuous network card at the NIX (Norwegian Internet Exchange) or on your local café router can harvest your credentials in seconds.

With the Personopplysningsloven (Personal Data Act) strictly enforced by Datatilsynet here in Norway, a breach caused by such negligence isn't just an IT problem; it's a legal nightmare.

The Solution: SFTP (SSH File Transfer Protocol)

Many confuse SFTP with FTPS. They are not the same.

  • FTPS is FTP over SSL (like HTTPS). It requires messy port ranges for passive mode and often breaks behind strict corporate firewalls.
  • SFTP runs entirely over the SSH protocol (Port 22). One port, strong encryption, and it comes installed by default on every Linux server.

Moving to SFTP is the single highest ROI security upgrade you can make today. It requires zero hardware investment, just a few minutes of configuration.

The "Jail" Problem

The main argument I hear against SFTP is: "But I don't want to give my web designers shell access! I just want them to upload files."

Historically, this was a pain. You had to use complex patches or third-party shells like rssh. However, with the recent versions of OpenSSH (starting from 4.8p1, standard in Debian 6 and RHEL 5.2+), we have the ChrootDirectory directive. We can now lock users into their web directories without giving them a terminal.

Implementation: Creating a Chrooted SFTP Jail

Here is the battle-tested configuration I use on CoolVDS slices running CentOS 5 or 6. This setup restricts a group of users to their specific directories.

1. Configure OpenSSH

Open /etc/ssh/sshd_config with vim/nano. Find the subsystem line and change it to use the internal helper:

# Old line (comment this out)
# Subsystem sftp /usr/libexec/openssh/sftp-server

# New line
Subsystem sftp internal-sftp

At the bottom of the file, add the matching rules. This tells SSH: "If a user belongs to the 'webmasters' group, force them into SFTP and lock them in their home folder."

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

2. Permissions Architecture

This is where most people fail. For ChrootDirectory to work, the directory path up to the chroot point must be owned by root and not writable by the user or group.

# Create the group
groupadd webmasters

# Create the user
useradd -g webmasters -d /var/www/vhosts/client1 -s /sbin/nologin client1
passwd client1

# Fix permissions (CRITICAL STEP)
# The chroot root must be root:root
chown root:root /var/www/vhosts/client1
chmod 755 /var/www/vhosts/client1

# Create a writable folder inside
mkdir /var/www/vhosts/client1/html
chown client1:webmasters /var/www/vhosts/client1/html

Now, when 'client1' connects via FileZilla, they land in their folder. They cannot see /etc, they cannot run commands, and crucially, their traffic is encrypted with AES.

Performance: Latency Matters

Encryption adds CPU overhead. In a shared hosting environment where hundreds of users fight for CPU cycles, SFTP transfers can stall. This is why "cheap" VPS providers throttle your connection.

At CoolVDS, we don't oversell our cores. We use KVM (Kernel-based Virtual Machine) virtualization which guarantees your slice gets the CPU time it needs to handle encryption/decryption on the fly. When you are transferring gigabytes of backups or media assets, that dedicated processing power translates directly to transfer speed.

Pro Tip: If you are managing servers from Oslo or Bergen, test your latency. Our infrastructure is located directly in local data centers, keeping ping times to major Norwegian ISPs under 10ms. Low latency makes the SSH handshake feel instant.

The Verdict

There is no excuse for using plain FTP in 2011. It violates best practices, it endangers client data, and it puts you at odds with privacy regulations.

If you need a sandbox to test this configuration without risking your production environment, spin up a CoolVDS instance. We offer pure root access and high-performance RAID storage that eats I/O for breakfast. Secure your transport layer today, before you become tomorrow's security headline.

/// TAGS

/// RELATED POSTS

Automating Server Hardening: A CTO’s Guide to Surviving Datatilsynet without Ulcers

Manual security checklists are a liability. Learn how to automate compliance using Ansible and OpenS...

Read More →

The Perimeter is Dead: Architecting 'Zero Trust' Security on Linux in 2015

The 'Castle and Moat' security strategy is failing. Learn how to implement a Zero Trust architecture...

Read More →

Automating Compliance: How to harden your Norwegian VPS without losing your mind

Manual security audits are a liability in 2015. Learn how to use Ansible and KVM isolation to satisf...

Read More →

Hardening the Stack: Defending Norwegian Web Apps Against the OWASP Top 10 (2012 Edition)

It is 2012, and SQL Injection is still king. A battle-hardened guide to securing LAMP stacks, comply...

Read More →

Paranoia is a Virtue: The 2012 Guide to Linux Server Hardening in Norway

Following the massive security breaches of 2011, default configurations are no longer acceptable. Le...

Read More →

Locking Down Your Linux Box: Essential Server Hardening Survival Guide (2011 Edition)

Stop relying on 'security by obscurity'. A battle-hardened guide to securing your Linux VPS against ...

Read More →
← Back to All Posts