Console Login
Home / Blog / Security & Compliance / FTP is Dead: Securing Your Data Transfer with SFTP on Linux
Security & Compliance 9 views

FTP is Dead: Securing Your Data Transfer with SFTP on Linux

@

Stop Using Port 21: The Case for SFTP in 2011

It is 2011. Why are we still having this conversation? I sat in a coffee shop in Grünerløkka last week, running a simple packet capture on the open Wi-Fi just to test the waters (strictly ethical, of course). Within ten minutes, I saw three different developers logging into their production servers using standard FTP. I saw their usernames. I saw their passwords. I saw the directory structure of their web roots.

If I saw it, anyone with a copy of tcpdump or Wireshark saw it. If you are managing servers for clients in Norway or the EU, relying on plain text FTP isn't just lazy systems administration; it is negligence. Under the Norwegian Personal Data Act (Personopplysningsloven) and the EU Data Protection Directive (95/46/EC), you have a duty to secure data in transit.

It is time to kill vsftpd on port 21 and move to SFTP. Here is how you do it correctly, without breaking your workflow.

The Problem with FTP (and FTPS)

Standard FTP was defined in 1985 (RFC 959). It was never designed for the hostile internet of 2011. It sends authentication credentials in cleartext.

Some of you might argue: "But I use FTPS (FTP over SSL)!"

FTPS is a firewall nightmare. Because FTP uses a control channel and a separate data channel, you end up having to open a massive range of passive ports (often 30000-50000) in your iptables configuration. It complicates NAT traversal and bloats your firewall rules.

The Solution: SFTP (SSH File Transfer Protocol). It runs over a single port (TCP 22), it is encrypted by default, and it uses the same rock-solid OpenSSH daemon you are already using to manage your server.

Tutorial: Configuring Chrooted SFTP on CentOS 5/6 & Debian Squeeze

The main objection to SFTP has always been: "I don't want to give my web designers full shell access."

Since OpenSSH 4.8+, we have the ChrootDirectory directive. This allows us to lock users into a specific folder so they can transfer files but cannot snoop around /etc/ or run shell commands. This is the standard configuration we deploy on all managed CoolVDS instances.

Step 1: Create the SFTP Group

First, create a group for these users. Do not add them to the wheel or sudo groups.

# groupadd sftponly

Step 2: Configure sshd_config

Edit your SSH configuration. Always back it up first.

# cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak # nano /etc/ssh/sshd_config

Find the line referring to the sftp subsystem (usually Subsystem sftp /usr/lib/openssh/sftp-server) and comment it out. Replace it with the internal-sftp command, which is required for chrooting without copying binaries/libs into the jail.

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

At the very bottom of the file, add the following block. This tells SSH: "If a user belongs to the sftponly group, lock them in their home directory and deny shell access."

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

Step 3: Permissions Architecture

This is where 90% of SysAdmins fail. For ChrootDirectory to work, the directory must be owned by root and not writable by any other user.

Let's say you are setting up a user webdev for a site hosted at /var/www/coolsite.

# useradd -g sftponly -s /bin/false -d /var/www/coolsite webdev
# passwd webdev
# chown root:root /var/www/coolsite
# chmod 755 /var/www/coolsite

Now, the user cannot write to the root of coolsite. You need to create a subdirectory for them to upload content, usually public_html.

# mkdir /var/www/coolsite/public_html
# chown webdev:sftponly /var/www/coolsite/public_html

Step 4: Restart SSH

Always verify your config syntax before restarting, or you might lock yourself out of the server.

# sshd -t # service ssh restart
Pro Tip: If you are managing high-traffic sites, latency during the SSH handshake can be annoying. In your sshd_config, set UseDNS no to prevent the server from trying to resolve the client's hostname. On CoolVDS nodes, which are optimized for low latency to the NIX (Norwegian Internet Exchange), this makes logins instantaneous.

Why Infrastructure Matters

You cannot implement this level of granular security on standard shared hosting. They won't let you touch the sshd_config file. You need your own environment.

However, not all Virtual Private Servers are created equal. Many budget providers use older OpenVZ kernels that have issues with chroot environments or iptables modules due to the shared kernel architecture.

This is why at CoolVDS, we prioritize full virtualization (KVM/Xen) and enterprise-grade RAID-10 SSD storage. When you are performing cryptographic handshakes for hundreds of SFTP connections, CPU stealing from "noisy neighbors" on oversold platforms becomes a bottleneck. You need dedicated resources to keep the handshake fast and the transfer saturating the port.

Final Thoughts

The "Datatilsynet" does not accept "we have always done it this way" as an excuse for a data breach. Moving to SFTP is a low-effort, high-reward change that drastically reduces your attack surface.

Disable port 21 today. If you need a sandbox to test your new SSH configurations without risking your production box, spin up a CentOS instance on CoolVDS. It takes less than 60 seconds.

/// 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