Console Login
Home / Blog / Security & Compliance / Stop Broadcasting Passwords: Why Norwegian Sysadmins Must Kill FTP for SFTP
Security & Compliance 9 views

Stop Broadcasting Passwords: Why Norwegian Sysadmins Must Kill FTP for SFTP

@

Stop Broadcasting Passwords: Why Norwegian Sysadmins Must Kill FTP for SFTP

It is late 2011. We have access to robust encryption standards. We have dual-core smart phones. Yet, for some inexplicable reason, I still see vsftpd listening on port 21 across hundreds of servers in the Norwegian IP space. If you are still using standard FTP (File Transfer Protocol) to manage your web server, you aren't just "old school"—you are actively broadcasting your root or user credentials to anyone with a packet sniffer.

As a sysadmin who has spent too many nights mitigating intrusions, I have zero tolerance for plaintext protocols. Here is the reality: if you FTP into your server from a coffee shop in Grünerløkka, the guy sipping a latte two tables over running Wireshark just stole your credentials. Game over.

Today, we are moving to SFTP (SSH File Transfer Protocol). It runs over SSH, it is encrypted by default, and it keeps Datatilsynet (The Norwegian Data Protection Authority) off your back.

The Anatomy of a Disaster: FTP vs. SFTP

Many developers confuse FTPS (FTP over SSL) with SFTP. While FTPS patches the security hole, it is a firewall nightmare because it requires opening a range of passive ports. SFTP is superior because it uses the SSH protocol. If you can SSH into your server, you can SFTP into it. One port (22). One rule.

Here is the breakdown of why I refuse to deploy anything but SFTP on CoolVDS infrastructure:

Feature Traditional FTP SFTP (SSH)
Encryption None (Plaintext) Full (AES/Blowfish)
Ports 21 + Passive Range (messy) 22 (clean)
Compliance Fails Data Protection Act Industry Standard

The "War Story": The tcpdump Wake-Up Call

Two months ago, a client migrated a legacy Magento store to us. They insisted on keeping FTP active for their external design agency. I set up a simple listener on the gateway just to prove a point.

tcpdump -i eth0 port 21 -w capture.pcap

Within 48 hours, we didn't just capture the legitimate traffic; we saw brute force attempts from botnets that specifically target port 21 banners. But worse, when the legitimate designer logged in, we captured the password in clear text. If I could see it, so could any compromised router between Oslo and their office. We switched them to SFTP that afternoon.

Configuration: Chrooting SFTP on CentOS 6 / Debian Squeeze

The common complaint is: "But I don't want to give my web designers full SSH shell access!" Valid point. You don't want a frontend developer running rm -rf / by accident.

The solution is using the internal-sftp subsystem in OpenSSH to jail (chroot) users to their home directory. This allows file transfer but denies shell access. This works beautifully on the standard OpenSSH 5.3+ found in RHEL/CentOS 6.

Step 1: Edit your SSH Config

Open /etc/ssh/sshd_config. Comment out the default subsystem line and add the following:

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

Step 2: Create the Match Block

At the very bottom of the file, add a rule for a specific group. Let's call it filetransfer.

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

Step 3: Permissions Management

This is where most people fail. For ChrootDirectory to work, the directory must be owned by root and not writable by anyone else. The user can then upload to a subdirectory inside.

# Create the group
groupadd filetransfer

# Create user
useradd -G filetransfer -d /home/webdev -s /sbin/nologin webdev
passwd webdev

# Fix permissions (CRITICAL)
chown root:root /home/webdev
chmod 755 /home/webdev

# Create the upload folder
mkdir /home/webdev/public_html
chown webdev:filetransfer /home/webdev/public_html

Now, when webdev logs in via FileZilla or WinSCP, they are locked inside their home folder. If they try to SSH via Putty, the connection closes immediately. Secure, compliant, and functional.

Pro Tip: On CoolVDS KVM instances, we recommend disabling password authentication entirely and using SSH keys for your root user, while keeping password auth for these chrooted SFTP users if absolutely necessary. You can use Match User root to enforce PasswordAuthentication no specifically for the administrator.

Latency and The Norwegian Context

Why does this matter specifically for us in the Nordics? Speed. SFTP is an interactive protocol. It sends acknowledgments for packets. If you are hosting your VPS in a budget datacenter in Texas while your dev team is in Bergen, the latency (RTT) will make listing a directory with 1,000 files painfully slow.

This is why physical proximity matters. Hosting on CoolVDS, with our presence at NIX (Norwegian Internet Exchange), ensures your latency to major Norwegian ISPs (Telenor, NextGenTel) is often under 10ms. When you are tunneling file transfers over SSH, that low latency translates to a snappy, "local-feel" experience, even when moving large media files.

Compliance is Not Optional

Under the Norwegian Personopplysningsloven (Personal Data Act), you are responsible for securing the processing of personal data. If you are transferring customer logs or database dumps via standard FTP, and that data is intercepted, you are in violation of the principles of data security. Datatilsynet does not look kindly on negligence.

Don't wait for a security audit to fail. Kill port 21 today.

Ready to lock down your infrastructure? Deploy a CoolVDS SSD VPS instance today. We offer pre-hardened CentOS and Debian templates so you can start with a secure foundation.

/// TAGS

/// RELATED POSTS

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 →

Fortifying the Castle: Essential Linux Server Hardening for 2012

With the rise of LulzSec and automated botnets in 2011, default configurations are a death sentence....

Read More →
← Back to All Posts