[2026] FTP in Practice | Active & Passive Modes, FTPS, SFTP & Firewalls

Introduction

FTP (File Transfer Protocol) has been used since the 1970s for file exchange—still common in batch jobs, legacy systems, industrial gear, and large MFT workflows. It splits control and data channels and uses Active vs Passive modes, so firewall rules differ—often the source of “works locally, fails in prod.” By 2026, plaintext credentials make FTPS or SFTP the norm for anything security-sensitive. This article explains behavior, client/server configuration, and how to choose among FTP, FTPS, and SFTP.

After reading this post

• Separate control (21/tcp) from data channels
• Explain Active vs Passive and firewall/NAT impact
• Use CLI and GUI clients for upload, download, and resume
• Choose FTPS vs SFTP on security and ops grounds

---

Table of contents

1. Protocol overview
2. How it works
3. Hands-on usage
4. Security considerations
5. Real-world use cases
6. Optimization tips
7. Common problems
8. Wrap-up

---

Protocol overview

History and background

FTP dates to RFC 114 (1971); RFC 959 (1985) is the classic reference, later extended for IPv6, security (FTPS), and more. HTTP, S3, and cloud APIs displaced FTP for new greenfield systems, but mainframes, plant equipment, and legacy MFT still expose FTP.

OSI placement

FTP is an application-layer protocol over TCP (control 21, data varies by mode). SFTP is not FTP—it runs over SSH.

Core properties

Property	Description
Dual channel	Commands on control; file bytes on data.
Stateful session	Login, CWD, interactive dialogue.
Transfer modes	Stream, block, compressed (implementation-dependent).
Text commands	USER, PASS, RETR, STOR, …

---

How it works

Control vs data

• Control (default 21/tcp): Auth, directory changes, transfer setup.
• Data: Actual LIST output and file payloads.

Active mode

1. Client opens control to server 21.
2. For transfer, client advertises a local data port (PORT).
3. Server initiates data connection to the client (“active” server connect). Often fails behind client firewalls that block inbound data connections.

Passive mode

1. Control connection same as above.
2. Client sends PASV (or EPSV) and receives server IP:port for data.
3. Client connects outbound to the server’s data port. Server must allow the passive port range in the firewall. 아래 코드는 mermaid를 사용한 구현 예제입니다. 코드를 직접 실행해보면서 동작을 확인해보세요.

sequenceDiagram
  participant C as Client
  participant S as Server
  C->>S: Control connection
  C->>S: PASV
  S->>C: Data address and port
  C->>S: Data connection
  S->>C: File transfer

Common commands (conceptual)

Command	Meaning
USER / PASS	Login (plaintext—risky).
PWD / CWD	Path and cd.
LIST / NLST	Directory listing.
RETR	Download.
STOR / APPE	Upload / append.
TYPE	ASCII vs IMAGE (binary).
PASV / EPSV	Passive mode.

---

Hands-on usage

CLI client (lftp example)

Option names vary—check lftp docs and set -a.

lftp -u username,password ftp.example.com
curl -u user:pass 'ftp://ftp.example.com/pub/readme.txt' -o readme.txt

vsftpd sketch (concept)

/etc/vsftpd.conf (paths vary by distro) 아래 코드는 ini를 사용한 구현 예제입니다. 각 부분의 역할을 이해하면서 코드를 살펴보시기 바랍니다.

listen=YES
anonymous_enable=NO
local_enable=YES
write_enable=YES
local_umask=022
pasv_enable=YES
pasv_min_port=50000
pasv_max_port=50100
# pasv_address=PUBLIC_IP   # important behind NAT
ssl_enable=YES             # FTPS

Open 21/tcp and pasv_min–max in the firewall for stable Passive.

Chroot and permissions

• Dedicated system accounts and chroot to limit writable roots.
• Minimum permissions on upload directories.

---

Security considerations

Plain FTP risks

Credentials and payloads can be sniffed on untrusted networks.

FTPS (FTP over TLS)

Explicit FTPS: AUTH TLS on the control channel, then encrypt. Avoid legacy implicit 990 when possible. Keep TLS versions and certificates current.

SFTP (over SSH)

SFTP is not FTP. It runs inside SSH, with keys and encryption as first-class. Greenfield often picks SFTP.

Aspect	FTPS	SFTP
Base	FTP + TLS	SSH
Ports	21 + data range (complex)	22 (simpler)
Legacy tools	Classic FTP clients	SSH clients

---

Real-world use cases

Scenario	Notes
Legacy integration	Banks, manufacturing batch exchanges, old MFT.
Large files	Clients with resume and parallel (lftp mirror).
Anonymous mirrors	Public FTP—needs abuse controls.
Device firmware	Some devices only expose FTP—isolate networks and prefer FTPS.

---

Optimization tips

• Parallel transfers: lftp mirror -P N for many files.
• Resume: verify REST/RETR or client resume support.
• Binary mode: use TYPE I for images and zip to avoid corruption.
• Placement: reduce RTT with nearby relay servers.

---

Common problems

Symptom	Check
Passive timeouts	Open PASV range on server firewall; set pasv_address behind NAT.
Active fails only	Client inbound data ports blocked—switch to Passive.
Listing works, transfer fails	Data channel firewall or FTPS data channel TLS settings mismatch.
Mojibake filenames	Client UTF-8, server OPTS UTF8 ON support.

---

Wrap-up

FTP’s split channels and Active/Passive behavior interact tightly with firewalls and NAT, while plaintext is a legacy liability. FTPS hardens transport; SFTP or object APIs are the modern direction. Use this article for legacy FTP maintenance, Passive/NAT debugging, and roadmaps toward FTPS/SFTP.

References

• RFC 959, RFC 4217 (FTPS)
• man lftp, OpenSSH SFTP documentation