rich text

Secure FTP backwards through a firewall

Hoping the lazyweb can come up with a reasonably elegant solution to
a securing-FTP problem I’ve run into.

I have a setup like so: 

   [ftp-server]---[broker]---|firewall|====[ftp-client]
   ^^^^^^^^^^^^^^^^^^^^^^^^^^          ^^^^^^^^^^^^^^^^
            intranet                        internet

I need to establish an FTP session from the ftp client to the ftp
server. —- is intranet, ==== is internet. broker is a machine
under my control. firewall will allow any outgoing connection and
will not allow any incoming connection. The FTP control and data channel
must not travel over the Internet plaintext, but plaintext from
broker to ftp-server is acceptable.

Using FTP is part of the specification. ftp-server will
only accept an FTP connection.

What can I do to make this work? In any circumstance other than FTP,
I’d ssh from broker to ftp-client and set up a reverse
(-R) tunnel from ftp-client back to ftp-server, but that
won’t work with FTP because of the data channel.

The less-than-elegant solutions I’ve come up with are:

  1. SSH out from broker to ftp-client, forwarding a port
    on ftp-client back to port 22 on broker. On
    ftp-client, ssh back through that tunnel back to broker
    with ‘ssh -D’, which sets up a SOCKS proxy tunnel in the right direction
    (beginning at ftp-client and connecting out from broker)
    Then use tsocks to SOCKS-ify the ftp client, and connect in passive mode
    “directly” to ftp-server from ftp-client, letting tsocks
    handle setting up the data channel’s tunnels as necessary.

  2. Build a ppp-over-ssh VPN between broker and
    ftp-client, initiated from broker.

Anything obvious I’m missing?

Rich

, , ,

6 responses to “Secure FTP backwards through a firewall”

  1. 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.

  2. 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.

  3. 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.

  4. 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?

  5. 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.

  6. 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.