This page gives a detailed description on what TCP activity goes on during a FTP session. If you are looking for answers to connection problems caused by routers and firewalls, you should look here. You can also take a look at slacksite.
Whenever an FTP client creates a connection to an FTP server at port 21, and starts to request data, the server will create a data link back from it's own port 20 to the port specified in the original connection by the client through a PORT command (non-passive connection, the most usual).
However, the client can instead of sending a PORT command, send a PASV command, which means the server is to send a message back to the client with a listening port number, so the client can itself create the data link (passive connection).
This gives in all 4 different combinations to take into account when configuring a port oriented firewall:
1) FTP server doing non-passive connection.
2) FTP server doing passive connection.
3) FTP client doing non-passive connection.
4) FTP client doing passive connection.
The easy way is to simply allow FTP servers and clients unlimited access through your firewall, but if you like to limit their access to "known" ports, you have to understand the 4 different scenarios.
1) The FTP server should be allowed to accept TCP connections to port 21, and to make TCP connections from port 20 to any (remote ephemeral) port.
2) The FTP server should be allowed to accept TCP connections to port 21, AND to accept TCP connections to any ephemeral port as well!
3) The FTP client should be allowed to make TCP connections to port 21, and to accept TCP connections from port 20 to any ephemeral port.
4) The FTP client should be allowed to make TCP connections to port 21, and to make TCP connections to any other (remote ephemeral) port as well!
Schematically:
Non Passive
Passive
An ephemeral (or dynamic) port is a temporary, short lived port, assigned to the application by the IP stack, taken from a specified pool. Mike Gleason has a wonderful page describing this principle in relation to FTP and firewalls as well. The range of ports used as ephemeral ports is both rather large, and can vary from system to system, both adding to the complexity of configuring a firewall correctly. Whenever an application makes a TCP connection, it is (usually) assigned a port by the IP stack as a "return address", meaning a TCP connection can have any port as its origin, and that is not a problem for firewalls at all, as they mostly check the destination port to figure out what to do. When FTP is involved, ephemeral ports are used as destination ports too, and that complicates the matter drastically.
If you have an FTP server, you should configure both case 1) and 2).
1) is easy enough, it is case 2) that needs consideration.
It should be obvious that you trust your FTP server not to do any hanky panky,
so allowing it to accept TCP connections to any ephemeral port should NOT be a
problem.
(In windows, the ephemeral port range is by default 1024-5000, but the upper
range can be changed.)
Sometimes, the FTP server can itself be assigned a range to use for PASV
connections, as is the case with
Cerberus that I am using.
This makes it possible to define a range of ports that are not too difficult
to configure in the firewall without any problems.
When configuring this range, you must be carefull not to choose too narrow a
range.
First of all, several ports can be used by the same connection, second, you
should be able to handle several clients at the same time, and third, an
ephemeral port has a rather long latency period (minutes), before Windows
allows that port to be reused, so you can very quickly run out of ports!
Make sure you select a port range of at least several hundred ports.
If you are having problems downloading and uploading to the server, but not
connecting, this range is the first thing to check, if you are sure your
firewall is configured correctly.
If your server is behind a router, you will have to configure the router as well. Note that routing port 21 is not enough, the chosen range of ports for PASV connections must also be routed correctly. Of course, all outgoing connections must be possible as well.
You probably also want to be able to act as an FTP client. This time, both case 3) and 4) pose problems: In case 3), you want to allow any incoming connection to your FTP client from port 20. This sounds acceptable, but in some cases could be very dangerous, as we shall see in a moment. In case 4), the FTP client should be allowed to do connections to any port (returned from an FTP server), and this also sounds acceptable, but again, it may not be, as we shall see.
There are 3 basic cases, that need to be configured.
a) You use a simple FTP client program.
b) You use a browser like Internet Explorer as FTP client.
c) You connect through a proxy server running
ProxyPlus, for instance, like I
am myself.
In case a), it is not a problem to allow it to accept connections on any port from port 20. There is of course a risc of a hacking attempt from port 20, but it requires a very lucky punch to hit your port while it is active, and even more luck to actually fool the FTP program, so I consider that risc remote indeed. But you also need to allow the client to make TCP connections to any other port. Again, we must assume you trust your FTP client, so this should not be a problem either.
Case b), and the trouble begins... Again, the chance of someone finding an open port waiting for connections from port 20 is remote (case 3), but do you trust the Internet Explorer or any other browser to allow it to connect to just any port (case 4)? Especially in these days, when browsers are running ActiveX components and scripts of all kinds. You might argue, that any malicious script or component would of course choose to report back on port 80, as this port is of course always open for the browser to connect to. Still, I don't like the idea, so think about it before allowing your browser to do passive connection. (In Internet Explorer, this can be configured in the Options dialog, Advanced, Browsing.) Lucky for me, I am using ProxyPlus as a proxy, so my browser cannot connect to just any machine, and it is not a big problem with Kerio and Tiny personal firewall to configure it to ask for accept on new connection types. That way I can accept the connection explicitly, whenever I need to do FTP, which is not often, without giving the firewall any definite rule.
Case c) is the really difficult one!
The proxy server need to be acting as an FTP server to the clients, but that
is not a big problem as clients have known addresses, so these addresses can
just be given the required permissions.
But on the outside, the job is not all that simple.
Case 3) requires it to accept connections on any port from port 20, but as my
proxy server has a lot of other ports open for other cases, the chance of a
hacking attempt against it from a port 20 is much higher, opposed to the case
of the client, which only had "stupid" ports open, waiting for connections
from port 20.
The ProxyPlus application is also offering a LOT of other services that could
be abused.
Of course, I have configured my proxy to only perform services when requested
from "secure" clients, but I don't like the idea of just opening all ports!
Also, only the ephemeral port range is relevant, but that range does indeed
include ports actually used for some of the proxy server's actual services.
One way to do it is to create rules DISALLOWING connections from the outside to these sensitive ports BEFORE the rule allowing connections to any ephemeral port. Another way is to reconfigure the proxy server's service ports to fall outside the ephemeral port range, so the dangerous rule allowing connections does not interfere with the real service ports.
If you are behind a router, you can choose to route the entire ephemeral port range back to your client machine, or you can choose to do PASV FTP connections, which does not require any odd incoming ports open, but only outgoing connections.
I hope this discussion has given you enough information to decide for yourself how to do it.
Last revised: 2006-03-21
·