FileZilla Server: Require Explicit FTPS on Control and Data Channels

FTP sends usernames, passwords, and file contents in cleartext unless the session is upgraded to TLS. If you operate FileZilla Server on a network where clients connect over the internet or an untrusted LAN, plain FTP exposes credentials to passive sniffing. The practical takeaway is to enable explicit FTP over TLS (FTPS), require TLS for both the control connection and data transfers, fix a passive port range for firewalls, and confirm that clients without TLS support are rejected.

Requirements

• Encrypt the FTP control channel, which carries commands and credentials.
• Encrypt the data channel, which carries directory listings and file transfers.
• Use explicit FTPS, meaning the client connects on the standard FTP port and upgrades with the AUTH TLS command, rather than implicit FTPS on a separate port.
• Present a server certificate that clients can validate, or accept the operational cost of users manually trusting self-signed certificates.

Smallest suitable design

In the FileZilla Server admin interface, enable FTP over TLS and select explicit mode. Require TLS for data connections so the server does not fall back to cleartext listings or transfers. Bind passive data connections to a narrow port range, for example 50000-50100, and advertise a stable external IP address if the server sits behind NAT. This is the smallest configuration that meets the requirement without adding a separate implicit FTPS port or a proxy.

Setting	Example value	Purpose
FTP over TLS	Enabled	Turns on TLS support
Type	Explicit FTP over TLS (AUTH TLS)	Upgrades port 21 instead of requiring a separate implicit port
Require TLS for data connections	Checked	Prevents cleartext data channels
Certificate file	/path/to/server.crt	Server identity presented during handshake
Passive port range	50000-50100	Firewall-friendly data connections
External IP	203.0.113.10	Correct PASV response behind NAT

Replace paths and IP addresses with values for your environment. The port range is an example, not a required value.

Trust and data boundaries

The server presents its certificate during the TLS handshake on the control connection. The client must validate the hostname and certificate chain. If the certificate is self-signed or issued by an internal CA the client does not trust, the client shows a warning. Manually accepting that warning shifts the trust decision to the end user and weakens the security boundary. The data channel is a separate TCP connection initiated in passive mode; requiring TLS on it protects the file contents after the control channel is already encrypted.

Operational checks

Check the control channel upgrade

Run FileZilla Client on a workstation. No administrative permissions are required for the client. Set the connection to require explicit FTP over TLS and connect to the server on port 21. In the client log, expect the server to advertise TLS support and the client to issue AUTH TLS. The log should show a TLS handshake on port 21 before any login command succeeds.

Check data channel protection

After login, request a directory listing or download. The client should issue PBSZ 0 and PROT P, and the server should acknowledge them. The listing and transfer then occur over a TLS-protected data connection from the passive port range. If the log shows a cleartext listing or a PROT C command, the data channel is not encrypted.

Confirm plaintext is rejected

Attempt a connection with TLS disabled. The server should reject cleartext authentication or the client should fail before login completes. If plain FTP succeeds, the server is allowing a downgrade and the requirement is not enforced.

Server-side configuration changes are made in the FileZilla Server admin interface on the server host and require administrator privileges. Review the server log from that interface for failed TLS negotiations.

Failure modes

• Clients that only speak plain FTP cannot connect once TLS is required.
• Expired or self-signed certificates produce client warnings or hard failures, depending on client settings.
• Passive data connections fail if the firewall blocks the configured port range or if the server advertises an incorrect external IP behind NAT.
• Certificate hostname mismatches cause validation failures even when TLS is otherwise configured correctly.

Conditions that change the design

• You must support legacy FTP-only clients that cannot be upgraded.
• You require server-to-server FXP transfers, which may behave differently with enforced TLS on both ends.
• The server is behind NAT without a stable public IP for passive mode, making the external IP advertisement unreliable.
• You need implicit FTPS on port 990 instead of explicit mode on port 21.

Limitations and rollback

This design assumes FileZilla Server is administered through its GUI and that clients can be configured for explicit FTPS. Behavior can differ between FileZilla Client and Server versions, so verify against your installed release rather than assuming identical defaults.

Rollback

Enabling TLS changes server state. To roll back, open the FileZilla Server admin interface, clear Require TLS for data connections, and change the type back to Allow explicit FTP over TLS or disable FTP over TLS entirely. Restart the service if the interface requires it. Existing client configurations that expect TLS will fail until they are changed back to plain FTP.

Practical verification after rollback

Confirm a plain FTP client can log in and list a directory. Confirm the server log no longer shows TLS handshakes on port 21 for new connections.