What firewall ports do I need to open when using FTPS?
Solution 1:
I believe the ports around 990 were for implicit SSL, which was an old non-standard way of doing FTP/SSL. The "right" way these days is explicit SSL, which means you still connect on port 21 and then negotiate SSL before sending your goodies. To support connections through a firewall, you need to use PASV mode and hard set the data ports to be used.
I believe you need at least one port per data connection you want to support. If it's just you, you're probably fine only opening a few extra ports. Specifically for me, I use 21000-21010.
In vsftpd.conf, I have these two lines (along with all the other stuff to support SSL):
pasv_min_port=21000
pasv_max_port=21010
On my firewall, I have a public static IP with one-to-one/static NAT to the internal IP and only tcp ports 21, 21000-21010 open.
Solution 2:
My understanding of FTP over SSL (ftps) is that it doesn't work well with firewalls and NAT. In an ordinary FTP session, the information about data connections is read, and for NAT modified, by the firewall in order for the firewall to dynamically open the needed ports. If that information is secured by SSL, the firewall can't read it or change it.
Using SFTP, or scp, makes the network administrator's job a lot easier - everything happens on the server's port 22, and the transaction follows the normal client/server model.
One thing not mentioned is whether or not your firewall is performing NAT and whether or not it is static NAT or dynamic NAT. If your client machine has a static address or is being statically NATed, you may not need to make any firewall changes, assuming you allow all outbound traffic and the server operates only in Passive mode (PASV).
To know exactly what ports you will need to open, you will need to either:
a) talk to the vendor to get specifics about how their system has been configured.
b) Use a protocol analyzer, such as tcpdump or wireshark, to look at the traffic, both from outside your firewall and inside your firewall
You need to find out which port is the Control Connection. You list 3, which seems odd to me. Assuming the server only works in PASV (passive) mode, you need to figure out how the server is configured to allocated DATA ports. Have they locked down the DATA channel to a single inbound port? Have they locked down the DATA channel to a small range or ports?
With these answers, you can start configuring your firewall.
Solution 3:
I know this is an extremely old thread, however..
Please note that SFTP is completely different from FTPS. ( SSH vs SSL )
FTPS worsk in 2 way. Explicit and Implicit. Explicit is less secure because after the initial handshake skips encryption during data transfers [if data encryption is maintained is configurable on server side with PROT P], while the Implicit keeps the encryption of the data after handshake too. The default Explicit FTPS port is 21. The default Implicit port is 990 ( after handshake it will switch automatically to 989 for data transmission, if not configured differently). While port 21 is generally accepted as EXPLICIT FTPS and 990 as IMPLICIT FTPS, in reality whichever port you will configure, except 990/989, will lead to EXPLICIT FTPS while ONLY 990/989 will be accepted as IMPLICIT FTPS.
So, to answer your question: - depending on the FTPS Server configuration, you'll need to open port 21 or 990/989. However, just to be sure, you should contact the FTPS Server admin and ask for directions. Also, keep in mind that for passive mode, as with every other FTP software, you'll have to open additional ports (TCP/UDP) usually something from the range 64000-65000.
Solution 4:
Basically ftps is almost useless, because you must make embarrassing requests to firewall admins. The advice to restrict ports to 10 is good. Much more, it gets pathetic.
sftp is a lot better in theory. But you need a viable sftp server, e.g. one that restricts clients to their own home directory.
Depending on the application, consider HTTPS. A file upload is really simple, and a download obviously is as well. If you're scripting the FTP anyway, it's probably going to be easier altogether to script an HTTPS file upload.
Automated FTP is a sign of a design problem. I noticed this when dealing with a total of about a dozen vendors that 'required' a place I worked to do automated FTP (for VERY important things), and when making dozens of customers do it with that same shop (a design failure for about 20 distinct uses I witnessed). It was easy to convince most app guys to use HTTPS (usually at the mention, they said "wait, there's no reason we're not just having them get it with HTTPS from the web server we're already serving them data on?"), except a few that gave responses like "well, we already have these scripts that seem to work, and no one on our team is really good with scripting so we cant really make any changes" (a team of 5-10 programmers, pretending to not understand that they can write it in a language of their choice, because they don't know how to write a trivial program from scratch.).