File Transfer Protocol (FTP)

FTP operates at the application layer and separates what almost no other protocol separates: commands travel over one connection and files over another. The control channel opens against port 21 and carries authentication and commands, such as listing a directory, creating a folder or requesting a file. File contents do not go through it.

A second connection carries the data, and there are two ways of opening it. In active mode the server connects back to the client, traditionally from port 20. In passive mode the client connects out to a high port the server nominates. This is not a textbook detail: active mode requires inbound ports open on the client side, which is why it sits badly with any modern firewall.

That two-channel design explains much of its operational trouble. A firewall that only sees the control channel does not know which port will be negotiated for data, so it either inspects the protocol or ends up with rules wider than anyone wanted.

It does not encrypt. Not the credentials, not the content. Anyone with visibility of the path, which includes a shared wireless network or one compromised machine on the same segment, reads the username and password as typed and takes the files along the way. It is the textbook argument for encryption in transit.

It does not protect integrity either. Without encryption there is no way to detect that somebody has altered what crosses the wire, so an adversary in the middle can modify a file in flight. When what moves is a backup, an installer or a configuration file, that stops being a confidentiality problem and becomes a way in.

Its authentication is what it always was: a username and a password, no second factor, nothing to slow repeated attempts. This is legacy authentication by the book, which is why it holds up poorly against brute force or a password spraying campaign aimed at predictable usernames.

Then there is anonymous access, which the protocol supports and which plenty of installations leave enabled without meaning to. An anonymous FTP server with write permission is a public drop box sitting inside your network.

They get confused constantly because the names look alike, and they share neither their design nor their ports.

FTPS is FTP with TLS wrapped around it. It is still the same protocol, with its two channels and its port negotiation, inside encryption. It solves confidentiality and inherits every networking inconvenience of the original, including the part that makes firewalls suffer.

SFTP is a different protocol altogether. It is not FTP pushed through a tunnel: it is an SSH subsystem travelling over the same connection and the same port as an ordinary SSH session. One channel, encrypted from the first byte, with the option to authenticate by key rather than by password. It is the sensible default, and it also means its exposure is exactly the exposure of SSH, no more and no less.

If a short rule helps: SFTP wherever possible, FTPS when the other end accepts nothing else, plain FTP never.

First, whether it is somewhere it should not be. An FTP service published to the internet turns up during reconnaissance before almost anything else, because the banner on port 21 announces which software and which version is answering, and that is enough to check whether the version carries a known CVE.

Then anonymous access and permissions. If you can get in without credentials, the next question is whether you can also write, and whether what you write lands somewhere that something else executes later. That chain is the usual route from a badly configured FTP server to remote code execution.

And on an internal test, listening. If FTP is used between machines on the same network and somebody is already inside, the credentials are collected without exploiting anything at all: you only have to be on the path. What usually comes out is a service account reused elsewhere, which is what was actually being looked for.

Nobody keeps an FTP server for pleasure. It survives because some process depends on it, and that process is almost always an old one nobody wants to touch. So the first job is finding who genuinely uses it, from logs rather than from assumptions.

Moving to SFTP is usually straightforward for what people do and considerably less so for what machines do, because the way authentication works changes and keys have to be managed. That work belongs to secrets management, and skipping it means swapping a plaintext password for a private key stored in the same place the password was.

While the migration runs, what reduces the damage is the network: take the service off the internet, restrict it by source, put it behind segmentation that isolates it from everything else, and control what leaves with egress filtering. None of that fixes the protocol. All of it reduces who you are offering it to.

An external pentest looks at what your organisation publishes towards the internet, and an exposed FTP service is among the findings that appear on the first pass. What gets delivered is not that the port is open, which any scanner will tell you: it is what can be done with it, proven and reproducible.

And when the FTP server lives indoors, the question moves with it and gets answered from inside the network, which is what internal pentesting is for.