Re: Microsoft FTP Server problem on W2K?

From: Alun Jones [MS MVP] (alun_at_texis.com)
Date: 12/13/03 

Date: Sat, 13 Dec 2003 13:30:53 GMT

In article <brdnda$168r$1@si05.rsvl.unisys.com>, "Pete Hornby"
<peter.hornby@unisys.com> wrote:
>I have technical responsibility for this FTP implementation, and I need
>to make some comments on what you said here. Neither here, nor in
>the responses quoted by David, am I trying to say that "we're right,
>and they're wrong". I would make the point that it's not a cut-and-dried
>decision, and there are arguments on both sides.

Sure it's not - but when I saw the original responses attempting to weasel
out of doing the simple thing to make life better, more compatible and more
secure, and citing "well, it's RFC compliant" as if it was the reason (when
making the fix doesn't break RFC compliance), I got really annoyed.

>RFC 2577 says that the server may find it "desirable to restrict access
>based on network address", citing an example of a server which might
>want to "restrict access to certain files from certain places". Maybe
>I'm wrong, but it doesn't seem to me that that's what's going on here.

Of course, the other thing to remember is that even in the absence of RFC
2577, allowing any old IP address to connect to a PASV listening socket will
allow for port hijacking. A moment's thought indicates that this is so -
it's useful for proxy transfer, but that's not so safe in today's unsecure
world. The reason I made my argument with reference to RFCs more than just
appealing to common sense was simply that it seemed like the OP was dealing
with a vendor that was unresponsive and could only appeal to "RFC
compliance" as if this somehow bound their hands from doing something
useful.

>Or it can unconditionally make the decision made by the server in use at
>David's site. In the case he's discussing, the two IP addresses were not
>only in the same network, they were in the same system. I might argue,
>but probably won't, that this is throwing the baby out with the bathwater.

How would the server know that the two IP addresses were in the same system?

For that matter, it's also important to note that you can't tell whether or
not two uses of the same IP address come from the same user context. This
is one of the insecurities of FTP - port hijacking is not common, but it's
certainly possible, and it's why a server may need to make its port
assignments unguessably random, and why it should reject connections to PASV
ports that don't come from the client's IP address..

[Then you go all evil, and quote something I previously said]:
>The best that a server can do against PASV hijacking is to improve the
>randomness of its choice of ports, and to close all connections other than
>the first received on the incoming port. It might also care to verify that
>the source address matches that of the client, but that, too, is somewhat a
>matter of taste.

It's a matter of taste in that some people choose to allow proxy transfers.
In that case, you clearly _must_ allow any IP address to connect to the PASV
port. You secure it by choosing the PASV port randomly. It's somewhat
hit-and-miss, because it's broken as soon as someone can predict your random
choice (because "random" is never truly random).

If your taste is to disallow proxy transfers, you can make a slightly better
protection by randomising the port offered, _and_ restricting the connecting
IP address to match the client's address. Since you have no reliably secure
way of telling what other IP addresses the client has, you have to restrict
it to the one IP address that you already know about.

>These weren't "any old IP addresses". These were two IP addresses on the
>same machine.

And you could tell this ... how?

If the server couldn't tell, then the other IP address is, indeed, "any old
IP address".

>Look, I don't mind changing this. It's a single line of code.Truth be told,
>I'm
>not entirely sure why we did it the way we did in the first place. I'm
>sympathetic to the issue faced by David, and those you talk about in your
>response. I just wanted to point out that there are things to be said on
>both
>sides. And I'm persuaded.

Glad to hear it. Other than that it's a little less code, there's really no
reason to go binding to a different address. It's not mandated by an RFC,
and it hides information that can be used to associate your data connection
to the control connection. It's not exactly perfect. And as for arguing
that my parenthetical comment about it being obvious that you bind to the
same IP address, when you're told to bind to the same port as the control
connection came from, were you really convinced that the RFC would want you
to bind to the same port, but a _different_ IP address? In what way would
that make any kind of sense?

>One more thing. David didn't point out that our client does allow you to
>force the two client-side IP addresses to be the same. He has verified that
>this works.
>
>Enough. I'll cut a fix.

Glad to hear it. This is not my father's Unisys :-)

Alun.
~~~~

[Please don't email posters, if a Usenet response is appropriate.] 

-- 
Texas Imperial Software   | Find us at http://www.wftpd.com or email
1602 Harvest Moon Place   | alun@texis.com.
Cedar Park TX 78613-1419  | WFTPD, WFTPD Pro are Windows FTP servers.
Fax/Voice +1(512)258-9858 | Try our NEW client software, WFTPD Explorer.

Relevant Pages

  • Re: Microsoft FTP Server problem on W2K?
    ... so I can filter out SQL Server frames from other chatter. ... the other thing to remember is that even in the absence of RFC ... > allow for port hijacking. ... > to the control connection. ...
    (microsoft.public.inetserver.iis.security)
  • Re: Socket Programming
    ... the server accepts the connection. ... It needs a new socket (and consequently a different port ... Now the word "socket" is used in slightly different ways in RFC 793, ...
    (comp.lang.lisp)
  • Re: Correction
    ... Normally to physically disconnect is just a matter of reaching for the ... >> I have an ADSL connection which polls my computer from time to time, ... > disallow each and every port with Windows Firewall? ...
    (microsoft.public.windowsxp.messenger)
  • Re: Using Remote Desktop From an SBS Domain
    ... when you tried to RDP while attached directly to a port on your router? ... Internet to initiate an IP conversation with your computer. ... This situation is different than if you ran your own NAT connection sharing ...
    (microsoft.public.windows.server.sbs)
  • Re: Still cant connect to RWW or OWA remotely
    ... it certainly appears to be something about the SBS configuration. ... Meridian.local Ethernet adapter Local Area Connection: ... Windows SMALL BUSINESS SERVER 2003 Windows IP Configuration ... 192.168.254.254) directly to a port on the router and then ...
    (microsoft.public.windows.server.sbs)