FTP in Practice | Active & Passive Modes, FTPS, SFTP & Firewalls
이 글의 핵심
FTP uses separate control and data channels and Active/Passive modes—plain-text by design; FTPS and SFTP address security; firewalls make or break deployments.
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
- Protocol overview
- How it works
- Hands-on usage
- Security considerations
- Real-world use cases
- Optimization tips
- Common problems
- 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
- Client opens control to server 21.
- For transfer, client advertises a local data port (PORT).
- Server initiates data connection to the client (“active” server connect).
Often fails behind client firewalls that block inbound data connections.
Passive mode
- Control connection same as above.
- Client sends
PASV(orEPSV) and receives server IP:port for data. - Client connects outbound to the server’s data port.
Server must allow the passive port range in the firewall.
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)
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 Nfor 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