What Makes an FTP Server Secure: The Checklist Behind the Label

The partner's security questionnaire arrives as a spreadsheet with two hundred rows. Row 47 asks: "Is your FTP server secure? (Yes/No)." There is no row 48 asking what that means. Everybody types Yes. I have typed Yes. The question is built so that the only wrong answer is an honest one.

This article is the missing row 48. "Secure FTP server" is a label, and labels are free. What sits behind the label is a short list of things a server either does or does not do, and each one can be checked. The article sorts out the vocabulary first: secure FTP, SSL FTP, FTPS, FTPES, and SFTP. Then it lists the seven things a secure FTP server must do, explains the "does not support FTP over TLS" warning, and ends with a checklist to copy and commands that test your own server from outside.

It is part of our Hardening File Transfer Servers series. The series is the full program. This is the one-page version for the day somebody asks whether the server is secure and expects an answer with evidence in it.

What "Secure FTP" Actually Means

Plain FTP has no encryption at all. The user name, the password, and every file cross the network as readable text. Anyone positioned between the client and the server can read all three. "Secure FTP" is the general wish to stop that, and three quite different technologies get sold under the name.

So what is SSL FTP? It is FTPS. SSL, the Secure Sockets Layer, was the original encryption layer for web traffic. TLS, Transport Layer Security, is its replacement. SSL itself is obsolete and should be switched off everywhere, but the name stuck to everything TLS touches. "FTP with TLS/SSL," "SSL on FTP," and "FTP server SSL" settings all refer to the same thing: FTP commands and data travelling inside TLS.

"SSL SFTP," on the other hand, describes nothing. SFTP does not use SSL or TLS. It runs inside SSH, which has its own encryption and its own way of identifying the server. People say "SFTP SSL" when they mean either SFTP or FTPS and are not sure which. It is worth asking, because the two need different ports, different firewall rules, and different client settings. The comparison is in SFTP vs FTPS.

The last row of the table is the one to be careful with. A VPN protects the traffic between its two ends. Inside each network the FTP session is still plain text, and the server still accepts unencrypted logins from anything that can reach it. That is a secured path to an insecure server. Both FTPS and SFTP, properly configured, are legitimate ways to run a secure FTP site. The tunnel is a way to postpone the question.

FTPS vs FTPES: Explicit and Implicit

FTPS comes in two styles, and the difference is when the encryption starts.

• Explicit FTPS, also written FTPES, uses the normal FTP port, 21. The client connects, sends the command AUTH TLS, and the connection switches to encryption before any user name or password is sent.
• Implicit FTPS uses a separate port, 990. The TLS handshake happens the instant the connection opens, before a single FTP command.

Why is FTPES usually preferred over implicit FTPS? Explicit mode is the one written into the published standard for FTP over TLS. Implicit mode was an early approach that never became a standard, and it survives because so much older software still expects it. Explicit mode also needs no extra port. Most servers and clients treat explicit as the default and offer implicit for compatibility.

Explicit mode has one weakness, and it is a configuration matter, not a design flaw. Because the connection starts unencrypted, a server can be set to allow TLS without requiring it. A client that never sends AUTH TLS then logs in as plain FTP, on the same port, to the same server that the questionnaire calls secure. The setting that fixes this is usually named "require TLS" or "require SSL." Allowing encryption is a courtesy. Requiring it is a control. The two styles are compared in detail in explicit versus implicit FTPS, and building one is covered in how to set up an FTPS server on Windows.

"This Server Does Not Support FTP over TLS"

Many administrators first meet all of this through a warning in their FTP client. The wording varies. A widely used open-source client says "Insecure server, it does not support FTP over TLS." Others say "this server does not support FTP over TLS" or report that AUTH TLS was rejected.

The warning means exactly what it says. The client asked to encrypt the session, and the server answered that it does not know how. If you continue, the password goes out as plain text. Work through the causes in this order:

1. TLS is not enabled on the server. The FTP service is running as plain FTP only. Enable FTPS in the server settings.
2. No certificate is assigned. Many servers will not offer TLS until a certificate is selected for the FTP service.
3. The server offers only implicit FTPS on port 990, and the client is trying explicit on port 21. Match the client's encryption setting and port to the server.
4. You have reached a different service. An old plain-FTP server may still be answering on that address, or a NAT rule may forward port 21 somewhere unexpected.
5. A firewall or inspection device between you and the server is interfering with the AUTH TLS command. Test from a different network to confirm.

If the server is yours, fix it before anyone logs in again. If it is a partner's, send them the exact wording and do not click "always trust this server." That checkbox is how a temporary exception becomes a permanent one.

The Seven Things a Secure FTP Server Must Do

Encryption is the first requirement and the only one most people check. An encrypted FTP server with a shared password, no logging, and access to the whole disk is a well-wrapped problem. These are the seven properties to look for, in the order an attacker would test them.

1. Encrypt every connection, and refuse the ones that are not

The server offers FTPS, SFTP, or both, and plain FTP is turned off or TLS is required. For FTPS, encryption has to cover the data connection as well as the control connection. A session can encrypt the login and still send the files in the clear unless the server insists on protected data connections. The background is in encryption in transit.

2. Use current encryption, and prove the server's identity

Old protocol versions and weak ciphers are disabled, leaving current TLS for FTPS and current algorithms for SSH. An FTPS server presents a certificate issued for its host name by a certificate authority the client trusts. An SFTP server has a stable host key whose fingerprint you have given to partners. Encryption without identity means the client is talking privately to it knows not whom. The settings are covered in hardening FTPS.

3. Know exactly who is logging in

Every person and every partner system has its own account. Anonymous login is off. Passwords are long, or better, SFTP accounts use SSH keys, and administrators use a second factor. A shared account makes every later control weaker, because the log can only say that "the account" did something. See authentication for file transfer.

4. Confine each account to its own folder

A logged-in user sees a home folder and nothing above it, with only the permissions the job needs: upload-only for one partner, read-only for another. This is the control that decides how bad a stolen password is. Without it, one partner's credentials open every partner's files. The detail is in account isolation and jails on transfer servers.

5. Resist guessing

Any server on the internet receives password guesses within hours of going live. This is not personal. A secure server locks or delays accounts after repeated failures, blocks addresses that keep trying, and where partners have fixed addresses, accepts connections only from those. Brute-force protection covers the options.

6. Record what happened

The server logs every login, failed login, upload, download, and deletion, with the account, the source address, and the time. The logs are kept long enough to answer a question asked months later, and somebody can actually find them. An incident without logs is a rumor. See transfer logging and audit.

7. Stay patched and stay small

The server software and the operating system receive security updates on a schedule. Protocols nobody uses are switched off, and the login banner does not announce the product and version to every scanner. A server that offers less has less to defend. See patching file transfer servers without breaking partners and server banners and information leakage.

A Secure FTP Server on Windows

On Windows the seven requirements stay the same, and the platform decides how you meet them. The FTP service built into Windows provides FTPS and uses Windows accounts. It does not provide SFTP, so a partner who asks for SFTP needs either the OpenSSH server feature or a dedicated product alongside it. Folder confinement comes from the service's user isolation setting plus NTFS permissions, and lockout comes from the Windows account policy. Each control exists. They live in four different tools.

A dedicated Windows secure FTP server gathers them into one place. Sysax Multi Server, for example, offers FTPS, SFTP, and HTTPS from one service and one set of accounts. Its security settings can disable outdated SSL and TLS versions and weak ciphers, and include a FIPS 140-2 mode. It can block addresses automatically after repeated login failures, restrict connections by address, and require a second factor at login, including through RADIUS. Activity is logged to a file and to a log database. The point of listing these is not the product. It is that each of the seven requirements should map to a named setting you can show somebody.

Whichever route you take, two Windows habits matter. Run the service under an account with only the rights it needs, not as a full administrator. And keep transfer accounts separate from the accounts people use to log on to Windows itself, so that a leaked FTP password is only an FTP password. The operating system side is covered in OS-level hardening for file transfer servers. The installation steps are in how to set up an FTP server on Windows and how to set up an SFTP server on Windows.

Secure FTP Software, Tools, and Sites: Sorting the Words

Searches for this subject use four terms almost interchangeably. They are different things:

• A secure FTP server is the software that holds the files and accepts connections. This article is about that.
• Secure FTP software may mean a server or a client. Check which before comparing products, because the lists do not overlap.
• A secure FTP tool usually means a client: the program a person or a script uses to connect. Secure FTP tools matter as much as the server. A client that skips certificate checks or accepts any host key undoes the server's work from the other end.
• A secure FTP site is what a partner gives you: a host name, a protocol, and an account on their server.

The client half deserves one more sentence. The server can require encryption, but only the client can verify who it is encrypting to. If your users are trained to click through certificate and host key warnings, the server's identity counts for nothing.

The Checklist to Copy

This is the checklist to run against a server before calling it secure, and to attach to the questionnaire instead of the word Yes.

SECURE FTP SERVER CHECKLIST            Server: ____________   Date: ________

ENCRYPTION
[ ] Plain FTP disabled, or TLS required on port 21 (not merely allowed)
[ ] FTPS data connections must be encrypted
[ ] Obsolete SSL/TLS versions and weak ciphers disabled
[ ] Certificate valid, issued for the host name, expiry date recorded
[ ] SFTP host key fingerprint recorded and sent to partners; key backed up

IDENTITY
[ ] One account per person or partner system; no shared logins
[ ] Anonymous access disabled
[ ] Password policy enforced, or SSH keys required
[ ] Second factor on administrator access

ISOLATION
[ ] Every account confined to its home folder
[ ] Permissions per account limited to what the job needs
[ ] Service runs under a least-privilege account

RESISTANCE
[ ] Lockout or delay after repeated failed logins
[ ] Automatic blocking of repeat-offender addresses
[ ] Source address restrictions where partners have fixed addresses
[ ] Only the required ports open on the firewall

EVIDENCE
[ ] Logins, failures, uploads, downloads, deletions logged with account and address
[ ] Logs retained for the agreed period and stored off the server
[ ] Someone reviews failed logins on a schedule

MAINTENANCE
[ ] Server software and operating system on a patch schedule
[ ] Unused protocols and features disabled
[ ] Banner does not reveal product and version
[ ] Checklist re-run after every upgrade

How to Verify It from Outside

A checklist filled in from the configuration screen records what you believe. A test from outside records what is true. From a machine beyond your firewall, curl can check the most important line in two commands.

First, confirm that an encrypted login works and see what the server presents:

curl -v --ssl-reqd --user ftp_acme ftp://ftp.example.com/

In the output, look for the AUTH TLS exchange, the TLS version that was agreed, and the certificate's subject and expiry date. The host name on the certificate should be the one you typed.

Second, confirm that an unencrypted login is refused:

curl -v --user ftp_acme ftp://ftp.example.com/

This one should fail. A correctly configured server rejects the session as soon as the client tries to log in without TLS, before the password is sent. If this command returns a directory listing, the server is accepting plain FTP, whatever the first test showed. For SFTP, sftp -v prints the host key fingerprint and the algorithms agreed, which you can compare against your records.

Meridian Parts ran the second test for the first time during an audit. Their server had offered FTPS for years, and the questionnaire answer had always been Yes. The plain login worked. The FTP site had been created with encryption allowed, not required, and one partner's nightly script had never been told to use it. It had been sending the same password in clear text every night for two years. Nobody had done anything wrong on purpose. Meridian switched the setting to required, the partner's script failed that night, and the partner added one line to it the next morning. The whole repair took a day, after two years of the box being ticked. The routine for repeating these checks is in verifying server hardening. Where health information is involved, HIPAA-compliant SFTP and PGP encryption maps these controls to that rule.

The Version to Tell a Colleague

"Secure FTP" means FTPS, which is FTP inside TLS, or SFTP, which is a separate protocol inside SSH. SSL FTP is an old name for FTPS, and FTPES is its explicit style on port 21. A secure FTP server does seven things: it requires encryption, proves its identity, gives each user their own account, confines each account to its folder, resists password guessing, logs everything, and stays patched. Test it from outside by confirming that an encrypted login works and a plain one is refused.

For the full program behind this page, start with a hardening program for file transfer servers. If plain FTP is still running somewhere because a device or a partner needs it, why plain FTP has to go covers how to make the case. The ports each secure protocol needs are listed in ports for FTP, FTPS and SFTP.

Frequently Asked Questions