At 19:51 14/10/00 -0400, Marcus J. Ranum wrote:
>In my opinion, a firewall that assumes FTP servers are
>binding the privileged port are mis-implemented. As you've
>noticed, doing so causes them to reject traffic from versions
>of FTP servers and proxies that are actually better than
>the "ordinary" ones!
that's the good "be tolerant in what you receive, strict in what you
do" principle (the word tolerant is to be understood in the networking
sense here, not in the security meaning).
I guess ckp have found it hard to deal with an arbitrary port, which is
understandable. but more understandable is the fact that ftp should
be handled at application level anyway... but that's another story.
>Nope, there isn't; that feature is hard coded into the
>system. There's no code in the proxy to bind the
>privileged port, which would entail making the proxy
>run with privileges, or removing the privilege check
>from the underlying kernel.
I guess you're talking about the original version.
Things changed since release "4.something", when the keyword
"data-port" (or is it dataport?) has been added to allow chosing a
fixed data port instead of gletting the kernel to chose an ephemeral one.
the guys who did the modification also decide to ignore the error if
bind() fails, which may be questionable.
>It's a design that evolved from how the DEC SEAL's FTP
>proxy worked. A while before I coded that, I figured out
>FTP bouncing attacks and hypothesized that some ruserok()
>implementations might not check that the calling port
>was greater than, say, 100, and still in the privileged range.
>Anyhow, I decided that good FTP servers should not bind
>the privileged port, and further that proxies _especially_
>shouldn't.
The privport stuff is an old heritage that is of questionable value in the
today network.
First, it is only meaningful if you trust the source hostto a certain level.
it doesn't help you to know that the attacker used a privport.
Also, the 1024 and the like lost their magic. the ranges are now considered
insufficient, and the values have become configurable on a per host basis.
So what has been a "standard convention" is now a "local convention".
Anyway, proxies, servers, clients and other beasts should no more
give a reserved port any serious value.
note that protocols that require a reserved ports will have problems in the
case
of NAT or proxies. if you have 2000 clients connecting to an external
server thrugh
a NAT box or a proxy, so that the source address is mapped to one IP address,
then if a reserved port is required, there is no way to find 2000 ones
among the 1024
or so.
>In other words, it's not a bug, it's a feature. :)
I guess checkpoint would say the same thing :)
actually, both are valid choices, though I don't like checkpoint breaking
things that used to work...
>FTP is a fundamentally broken protocol. Back in those
>days I was trying to fix it using proxies and whatnot. Now,
>based on some of the stuff Michael is finding, I don't
>even think it's worth fixing. It just needs to have a bullet
>put through it. Someone needs to spearhead an RFC
>deprecating FTP in favor of a suitable replacement like
>SSH/SCP.
let's have faith in the future :)
regards,
mouss
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
