A protocol which is insecure should either be not implemented or
implemented with "self made" secure add-ons. There is no third alternative.
That RFC in ancient.
DS
> On Sun, 31 Oct 1999, CyberPsychotic wrote:
>
> Hi.
>
> > for me just fine), I just got points that ftp daemon should do
> appropriate
> > things instead. :)) Quite humorous but looks like ftp developers would
> > claim that not their code, but kernel should take care of the
> solution to
> > the problem.. oh well, that is life :)
>
> It may not be as easy as it looks. If you just go for "ftp daemon should
> check source IP address of the data transfer", it would have the following
> consequences:
>
> - effectivly proxy ftp transfers are denied, since the source IP is not
> the one of the client but the one of the remote ftp server
> - you'd get problems when using ftp bouncers or ftp bounce networks
> (such as bnc4all http://bnc4all.ftp4all.de/, redirect4all or the
> rftpd bouncer)
> - it might confuse load balancing application layer gateways
> - RFC 959 doesn't mention source IP checking anywhere, therefore it
> would be a doubtable selfmade addon
>
> On the other hand random ports choosen by the server violate the RFC, too:
> "Every FTP implementation must support the use of the default data ports,
> and only the USER-PI can initiate a change to non-default ports."
>
>
> > -Fyodor
>
> ciao,
> scut / team teso
> [http://teso.scene.at/]
>
> --
> - scut@nb.in-berlin.de - http://nb.in-berlin.de/scut/ -
> > sacbuctd_at_ircnet --
> -- you don't need a lot of people to be great, you need a few
> great to be --
> -- the best
> -----------------------------------------------------------------
> --- nuclear arrival weapon spy agent remain undercover, hi
> echelon ----------
>
Received on Nov 05 1999
Intro
