Comments on: Secure FTP backwards through a firewall

By: Rich

Rich — Tue, 05 Apr 2005 17:23:27 +0000

For the sake of anyone who comes along here via a search engine and finds this: We went with a ppp-over-ssh VPN. Worked like a charm.

By: pne

pne — Sun, 13 Feb 2005 22:04:35 +0000

I don’t know what Darkuncle is talking about since I kind of zoned out since I didn’t know what, exactly, “ftp-proxy(8)” or “pf(4)” do, nor what stunnel is or how it works, so I can’t comment on whether it’s the same as what I proposed or not.

However “make the data channel use predictable ports” seems less important if you use a tunnel with a fixed port number on ftp-client; then the only problem seems to be a light proxy that filters the response to PASV. SMOP.

By: Rich

Rich — Sun, 13 Feb 2005 20:50:36 +0000

These days, everything is required to do passive FTP -- PORT is historical. The second part sounds like what Darkuncle and I talked about above, or am I missing an important new detail?

By: pne

pne — Sun, 13 Feb 2005 17:27:08 +0000

Can ftp-server do passive FTP?

The first thing that came to mind when I read “communication only goes one way” (in this case, outwards through the firewall) was passive FTP.

Something like this, perhaps:

1) Set up software on broker that’ll act as an FTP proxy to re-write the answer to PASV and pass all other data through.
2) SSH out from broker to ftp-client, forwarding a port on ftp-client back to the port on broker that’s running the FTP proxy.
3) On ftp-client connect to ftp-server via the port forwarding.
4) Issue command ‘PASV’.
5) ftp proxy rewrites from, say, 10,11,12,13,123,234 to 127,0,0,1,44,55 where the last two are some fixed, prearranged port.
6) SSH out again from broker to ftp-client, forwarding this prearranged port back to whatever the ftp server said it would listen on. Meanwhile, ftp-client things the server is listening on 127.0.0.1:xyz (for xyz = prearranged port).
7) transfer data.

Seems not completely impossible to me, unless I’m missing something.

By: Rich

Rich — Sat, 12 Feb 2005 04:42:49 +0000

Something that does what (I think) ftp_proxy does but is simpler and not tied into pf looks like my best bet — the problem is really just “make the data channel use predictable ports”.

I have to take the word of the administrator of ftp-server that ssh isn’t practical — the FTP solution is temporary while a SOAP interface is developed to replace it. The firewall is the national corporate firewall, so there’s not much flexibility there.

By: darkuncle

darkuncle — Fri, 11 Feb 2005 23:57:45 +0000

it’s too bad $firewall and $broker can’t be the same machine; this would be fairly easily accomplished with ftp-proxy(8) on OpenBSD using pf(4). Although the encryption of the data and control channels would be tricky; you’d have to redirect using pf to a stunnel process that could wrap the data … probably vastly easier to just try to find some way to get sftp working on $ftp_server. If you have to have crypto, and it has to pass a firewall, using ftp is going to be nearly impossible. Or at least, certainly not worth the effort required to work around ftp’s shortcomings. Is there no way to get OpenSSH on $ftp_server and just have clients use winscp.sf.net or something? Corporate policy sure does cause us to jump through some irrational hoops sometimes …

good luck.