Skip to content
Production FTP
step 1/5

Reading — step 1 of 5

Read

~1 min readModern Alternatives

Production FTP

If you must run FTP:

Security hardening:

  • Force FTPS (require AUTH TLS or use implicit on 990).
  • Disable cleartext FTP entirely.
  • Strong cipher suite (TLS 1.2+).
  • Per-user chroot jail.
  • No anonymous unless intentional read-only public mirror.

Authentication:

  • Local Unix users (PAM).
  • Virtual users (database-backed).
  • LDAP / Active Directory.
  • Limit by IP / fail2ban for brute-force.

Firewall config:

  • Open port 21 for control (or 990 for implicit).
  • Open passive port range (configurable, e.g. 30000-30099).
  • For active mode: open port 20 outbound from server.

Monitoring:

  • Failed logins.
  • Transfer logs (file, size, user, IP, duration).
  • Disk space.
  • Connection count + rate.

Filesystem:

  • chroot per user.
  • Quota per user.
  • Write-only "incoming" directories for uploads.
  • Disk space alerts.

Common attacks:

  • Brute force: rate limit + fail2ban.
  • Bounce attack: PORT command to scan ports on third-party IPs (filter PORT IPs to client's source IP only).
  • PORT injection: relay attacks. Modern servers reject.
  • Path traversal: chroot + sanitize paths.

Performance:

  • Single connection per session (unless parallel).
  • Concurrent transfers via multiple sessions.
  • TLS overhead: ~5-10% throughput cost.
  • Disk I/O typically the bottleneck for large files.

Migration paths:

  • Existing FTP → SFTP (sshd_config: Subsystem sftp internal-sftp).
  • FTP → S3-compatible: MinIO, Wasabi, S3.
  • FTP → HTTPS API: GitHub releases, GitLab packages, modern artifact servers.

Don't:

  • Run plaintext FTP on the internet.
  • Allow active mode without strong filter on PORT IPs.
  • Use weak ciphers.

Do:

  • Migrate off FTP when possible.
  • If stuck with FTP: FTPS + passive + chroot + limits.

Discussion

Ask a question, share an insight, or help someone who’s stuck.

Sign in to post a comment or reply.

Loading…