Vladimir Dubrovin wrote:
>
> According to RFC 959 (FILE TRANSFER PROTOCOL - STATUS:STANDARD) IP
> address shouldn't be checked:
>
> -=-=-=-=-=-=-=-
> In another situation a user might wish to transfer files between
> two Hosts, neither of which is his local Host. He sets up TELNET
> connections to the two servers and then arranges for a data
> connection between them. In this manner control information is
> passed to the user-PI but data is transferred between the server
> data transfer processes.
> -=-=-=-=-=-=-=-
>
> So, if your server does check the IP and doesn't allow connection from
> another IP your server doesn't complies with RFC 959.
>
> RFC 2228 which specifies security mechanism in FTP doesn't obsoletes
> this.
You probably didn't mean to imply this, but let me address it as if you
did. First, thanks for pointing this out, it's very relevant. Second, as
most folks here probably know, standards don't necessarily apply in
security situations.
On various firewall lists, etc.. I occasionally see a post where someone
makes a statement like "you can't do that, it violates standard x, and
breaks behavior y." In my mind, security is all about breaking any
behavior you don't want to happen, per some policy, either written, or one
you make up on the spot. This is irrespective of what the standards say.
This can be unfortunate, as most coders will tend to favor features over
security, and therefore tend to follow standards. So, if the standard
includes risky features, so will the product.
Ideally, the standard would be "fixed" and the products would have to
follow. That's not going to happen with FTP. (FTP should just be declared
obsolete, and blocked at the NAPs and MAEs, but that's a different rant.)
So, you probably pointed this out to explain where the behavior came from
(because it said so.) I appreciate the info. Silly me, I assumed like the
original poster that that sort of behavior is broken, a result of not
coding in a check.
The point here is that this creates a security problem that attackers can
take advantage of, and I assume we'd like a switch to turn it off with.
BB
Received on Nov 05 1999
Intro
