In <9210041837 .
ZM5382 @
shield .
eng .
pyramid .
com>, Mark Frost writes:
> Pardon my ignorance but how exactly does on to proxy ftp? If I understand
> what it is correctly it allows one to do ftp "through" a host. (Please
> correct me if I'm wrong). Somehow I haven't got the sense of what's
> involved to set this up from the ftp man page.
If I understood the question, you're asking specifically about the
'proxy' command available in later versions of ftp (like those
distributed with 4.3bsd). Brent (below) answered your question about
how to setup a true proxy feature to ftp through a firewall.
If you were referring to the 'proxy' command noted in the ftp man
page: The proxy feature already built into ftp is not a "true" proxy --
it requires that the two endpoints (the primary and secondary FTP
servers you have open) be able to send IP packets directly to EACH
OTHER. Most firewall setups do not allow FTP packets to pass through on
the standard FTP ports, so this proxy feature is useless to most sites
that are truly firewalled.
Most site administrators have realized this, and have done some
degree of router filter hacking, FTP client or server hacking, or some
combination of those to allow users to FTP out from their site.
While I'm here, I have a point or two to add to Brent's reply...
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Then in <9210050316 .
AA09277 @
mycroft .
GreatCircle .
COM>, Brent Chapman replies:
> mfrost @
shield .
eng .
pyramid .
com (Mark Frost) writes:
>
> # Pardon my ignorance but how exactly does on to proxy ftp? If I understand
> # what it is correctly it allows one to do ftp "through" a host. (Please
> # correct me if I'm wrong). Somehow I haven't got the sense of what's
> # involved to set this up from the ftp man page.
>
> You understand correctly. The reason you can't find anything on it in
> the standard FTP man page is that it's not a standard feature of FTP.
>
> To do proxy FTP, you run a custom FTP client on your internal
> machines. This custom client has been modified so that, no matter
> where you tell it you want to connect to, it connects to your proxy
> machine, and tells the proxy machine where you want to connect to.
> The proxy machine then connects to the ultimate destination, and plays
> pass-through on the data. Sort of like making a long-distance phone
> call in the days before direct long-distance dialing.
While there are advantages to a custom FTP client, it's also an
option to run a proxy FTP server that will work with a standard FTP
client. In fact, after working within a firewalled environment for
several months, I finally got the hacking urge to do just that. After a
few months of testing, user feedback has been very positive.
From the user's point of view, here's how it looks:
$ ftp -n proxy_server proxy_port
[FTP connects to the Proxy Server, which is sitting on a
different TCP port number than a regular FTP server. The FTP
client thinks it's talking to a real FTP server at this point,
but it's not. The -n is to tell it not to authenticate since
it's not talking to a real server yet.]
ftp> quote open real.internet.host.domain
[The Proxy Server connects to 'real.internet.host.domain', and
then enters a total pass-through mode. At this point, the
client thinks it is directly connected with the server, and
the server thinks it is directly connected with the client.]
ftp> user ftp
[The user must authenticate now that a real server is
connected.]
Password:<your e-mail ID>
[The user enters the password, and is then finally connected
and ready to issue FTP commands.]
ftp> dir, get, put, etc.
[Standard FTP interchange of commands such as dir, get, put.]
ftp> quit
[The Proxy Server sees the final QUIT and closes connection to
the server.]
I've even developed an 'expect' wrapper that will proxy out to a
host and log me in as anonymous. This means I can run one easy command
on a machine behind the firewall and get connected/logged-in to an FTP
server. Rather convenient, eh?
In the next round of changes I'm going to make, I think I can even
work around the need to use 'ftp -n' making it much more convenient
without the expect wrapper.
> I'm not a big fan of proxy TELNET and FTP systems for several reasons.
> The first is what you've already hit upon: they're not a standard part
> of the operating system. This means you've got to install custom
> client programs (replacements for "ftp" and "telnet" that know how to
> talk to the proxy server) on all your internal machines that want to
> use the net. If proxy version of your client programs aren't
> available (which is usually the case for Mac and PC client programs),
> you're just out of luck.
This problem is the biggie fixed by setting up a proxy server that
will work with a stock (standard) FTP client.
> The second reason I'm not a big fan of proxy systems is that they add
> complexity and give you more exposure to single-point-failures (the
> proxy server going down), unless they're smart to know about multiple
> servers (I doubt most of them are, but I don't know).
Agreed. And as long as we have firewalls, the machines that have
access behind and in front of the firewall will be a scarce resource,
and loading is certainly a hot issue there.
> Finally, I've yet to have anybody ask for anything both reasonable and
> significant that can be done with a proxy telnet/ftp setup that can't
> be done with a carefully and properly constructed packet filtering
> setup. I'm sure that there _are_ examples, but in the several
> firewall systems I've built for clients in the last couple of years
> and the several more I'm currently building, the advantages of packet
> filtering have far outweighed the advantages of proxy services.
The security people where I work have never had the least bit of
interest in allowing TCP connections from the outside world all the way
through the firewall to end-user nodes. Period. In our environment,
this completely rules out packet filtering on a router since (if I'm
not mistaken) FTP requires the server to make a TCP connection back on
a port that the FTP client determines dynamically. The only way I could
think of to make this work via a packet filter would be to somehow tell
the FTP client to have the server always connect back on a (single)
predetermined port, and get the networking folks to permit connections
on that one TCP port through the firewall.
If anybody has any ideas on this or how secure outgoing proxy FTP
via router packet filters might be accomplished, I'd like to hear it.
> There are several proxy services that work, and work to such a degree
> that folks don't even think of them as proxy services; I'm talking
> about things like SMTP, NNTP, NTP, and DNS. People _expect_ servers
> running these protocols to proxy for other servers and clients (though
> most of them don't do it synchronously). I'm not opposed to proxy
> systems per se, just proxy systems for protocols that weren't designed
> for such use, and for which appropriate clients aren't widely available.
Most of the users I've worked with on my proxy FTP service felt
that FTP was the only highly used remaining "popular" protocol that
needed to be proxy-ized.
BTW, I'm still testing, and am not quite ready for a widespread
release of the software yet. It currently looks like a typical net
software package (a shar containing a couple C files, Makefile, README,
and man page). Installation is simply adding the pftp service to
/etc/services, and adding the code to invoke it in /etc/inetd.conf.
If any of you have issues with the potential ramifications of
making Proxy FTP widely available, please let me know so I can factor
that in. Please note that regular users will be able to compile and run
this code themselves on a firewall and use it without needing any
privs.
I would like to apply for a "standardized" reserved TCP port number
(<1024) for proxy FTP, but I don't know where to apply. Can somebody
point me in the right direction?
...Marc...
--
Marc Frajola, marc @
escargot .
rain .
com | Work: Mentor Graphics, Inc.
Phone: (503) 244-5499 [Portland, OR] (Home) | (503) 685-4817
Follow-Ups:
References:
|
|
