[ftpext] Firewalls & FTP over TLS.

["Alun Jones" <[e-mail]>]

I frequently find I have a hard time selling my FTP server into environments
that are looking for a secure and standard file transfer server.

 

Not because it's not a good and standard implementation of FTP over TLS -
I've found it to work very well with numerous clients.

 

The failure is twofold - one, because the perceived "standard" for this is
SFTP, and two, because of the headache of getting FTP (and particularly FTP
over TLS) to work through a firewall.

 

The "SFTP is a standard" complaint is galling, because of course, SFTP is
not a documented standard, and pretty much requires reverse engineering in
order to make it work. I've been trying to push this message - that SFTP is
flakey compared to FTP over TLS simply because SFTP essentially relies on
each server / client author making tweaks to have it work with those they
test with, rather than coding to a unified standard like FTP over TLS. Maybe
that's not a problem for those of you with SFTP capabilities in your
servers, but personally, I don't find that I want to implement an
undocumented standard.

 

The "Can't make FTP over TLS work through a NAT / firewall" is irritating
too, partly because it seems to be mostly true. In MODE S, TYPE I transfers,
the PORT command or PASV response have to be filtered and altered to open a
port and/or change the IP address to make the connection work. The
alternative is to open a wide swath of ports at the firewall, which security
teams shy away from, and in many companies, outright prohibit.

 

Again, SFTP wins out here, because it works over one port, and one port only
- although opening up port 22 (SSH) essentially says "allow anything",
because SSH is used as a tunnel for multiple random protocols as well as SSH
and SFTP. It would be really nice if FTP could work over predictable port
numbers, especially if they were already opened by the firewall's usual
operation.

 

Well, I've said it before, and got absolutely no response, so I'm asking
again - why don't we use the default port as defined in RFC 959 and before?

 

An FTP (or FTP over TLS) client connecting from port U to port L and sending
a RETR or STOR command (or equivalent) without a PORT or PASV (or EPRT,
EPSV, etc) command will cause the server to connect from server port L-1 to
client port U, and because of the nature of firewalls, they will generally
have opened a hole (server:any => client:U) already.

 

Great, that works for the first transfer, because in MODE S, you close the
TCP data connection to indicate the end of a transfer, and can't open a new
socket (server:L-1 => client:U) for another two to four minutes.

 

Again, there's already an RFC 959 way of getting around this - instead of
using MODE S, use MODE B. Then, although there's a slight penalty in terms
of the chunk markers and restart markers, there's no issue with closing and
re-opening connections in rapid-fire transfers of small files or directory
listings, and it gets through a firewall and a NAT quite happily without
having to provide external IP address mappings, UPNP, or large firewall
holes.

 

While I've been able to test this with my own crappy test client (WFTPD
Client hasn't had enough work put into it to be really good), it would be
great to see this supported across multiple FTP clients and servers. IIS FTP
server already supports MODE B, but I don't really have any idea as to how
wide-spread support for MODE B is, or what features clients and servers
expect to see, or get confused by. I know that one failing in my own server
is a lack of support for restart markers (although it currently works if you
specify byte counts, as if it was in MODE S).

 

Another thing that needs discussing for MODE B support is how ABOR should
work - that's not exactly clear, either.

 

So, who else supports MODE B for firewall / NAT traversal?

 

Alun.

~~~~