Re: Microsoft FTP Server problem on W2K?
From: Alun Jones [MS MVP] (alun_at_texis.com)
Date: 12/12/03
- Next message: swbell.net: "sign in"
- Previous message: Jeff Cochran: "Re: "we have been hacked""
- In reply to: DavidM: "Microsoft FTP Server problem on W2K?"
- Next in thread: DavidM: "Re: Microsoft FTP Server problem on W2K?"
- Reply: DavidM: "Re: Microsoft FTP Server problem on W2K?"
- Reply: Pete Hornby: "Re: Microsoft FTP Server problem on W2K?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Fri, 12 Dec 2003 20:43:04 GMT
In article <O2PGLCNwDHA.2000@TK2MSFTNGP11.phx.gbl>, "DavidM"
<scandal_123@cox.net> wrote:
>The below excerpts are what the mainframe vendor is telling us:
>
>Email #1 from us to vendor:
>The windows FTP server does not like the mainframe sending packets from
>multiple IP addresses. When we restricted the packets to come from only one
>IP address, passive mode worked.
>
>So the question is, should packets be allowed to come from multiple IP
>addresses when using Passive Mode. Bug or feature. A good question for
>engineering. Can you follow up on this??
Bug. Definitely. In the case that a PASV mode transfer is coming from a
client (rather than another server, as in proxy transfer), the IP address
(and technically, the port) the client binds to must match that address (and
port) currently in use on the control connection. The port binding is
parenthesised, because a) nobody does it and b) it would lead to problems
with TIME_WAIT state when transferring large numbers of files in short time
(four minutes or less) through a restrictive port range (such as a firewall
might provide).
>Email #2 from vendor to us:
>
>The following is from engineering:
>1. Any given FTP connection - in fact, any TCP/IP connection - will involve
>packets being sent from a single IP address and to a single IP address. The
>TCP/IP connection is identified by source and destination port numbers and
>source and destination IP addresses.
Yes - statement of fact.
>2. The FTP standard (RFC 1123 section 4.1.2.12) states that, on a
>multi-homed server, the data connection MUST use the same IP address as the
>control connection. It is not, however, required that the client-side data
>connection use the same IP address as the client-side control connection. In
>fact, it's not even necessary, according to RFC 959, that the client ends of
>the two connections be in the same machine. See RFC 959 section 2.3.
Ah, but section 3.3 of RFC 959 says that there is a default port,
client-side, that must be used unless the PORT command is used to negotiate
a different one. Since PASV voids PORT, the client side must use the
default port (and hence, the IP address that it used to connect to the
server from). As it turns out, few clients do this, but all clients should
use the same IP address.
Also, check out section 4 of RFC 2577, "FTP Security Considerations" -
essentially, your vendor is saying that there is a random chance that their
client won't work when connecting to a server that chooses to check for the
same IP address in control and data connections.
Note that the random chance of _failure_ is 1/2 for a two-homed client, 2/3
for a three-homed client, 3/4 for a four-homed client, etc. In other words,
the chances of failure go up the more network cards you have in the machine,
and your chance of success is never better than fifty-fifty. What poor
odds. Such an unreliable client. Care to name it, so we can all avoid it?
>3. The mainframe FTP behaves in this way:
>
>In PORT mode, where the data connection establishment is FROM server TO
>client, our client establishes the data connection from the same IP address
>as the data connection.
Yes, this makes sense, for security's sake as much as for consistency.
>In PASV mode, where the data connection establishment is FROM client TO
>server, our client allows TCP/IP to assign the IP address of the data
>connection. It is possible that this could be different from the IP address
>of the control connection.
This is bogus. It takes what, two, three lines of code to call getsockname
and bind? The IP address used to connect to the PASV socket should be the
same as used to connect to the control connection, if it comes from the same
machine. Otherwise, the server is free to decide that "this is not the same
client", and reject the attempt to hijack the port.
>The following is the result of the analysis of the information you provided:
>We analyzed the trace that was provided and it shows, we initiated the
>control connection from 10.246.1.12, and the data connection from
>10.246.1.11. The data connection opened successfully, which suggests that
>the remote FTP server was, at least at a TCP level, prepared to accept the
>connection initiation from the second IP address. The server returned a 426
>error response when we sent the STOR command over the control connection,
>and immediately closed the data connection.
>
>As I said previously, I believe that the behavior of our client is in
>accordance with the FTP protocol standard.
So is a client that refuses to allow the user to transfer any files at all.
At some stage, you have to say "okay, we want to make sure that our software
not only obeys the standard, but also has some useful functionality".
>We still believe the problem is on the remote FTP server side.
Bull-pucky. The FTP server is behaving slightly more securely than RFC 959
/ 1123 dictates, in a manner compliant with RFC 2577. The FTP client is
behaving like its programmers have got their heads up their collective arses
and haven't been aware of the last decade's developments in FTP.
>Can someone please tell me what the correct answer is. I would imagine that
>the FTP server cannot accept passive connections from two different IP
>addresses. Otherwise, FTP transmissions would be failing for no apparent
>reasons due to port scans, hackers, etc.
The FTP server _could_, if it wanted to, accept connections to PASV
listeners from any old IP address. But, this would open your server up to
port hijacking attacks. See RFC 2577. This FTP server is configured or
programmed to prevent such attacks by requiring that both control and data
connections must come from the same port. This is how our own FTP servers,
WFTPD and WFTPD Pro, are configured by default, and it's a recommendation of
RFC 2577, which only covers the most basic and vital of security
considerations. [Its only concession to encryption, for instance, is to
state "To guarantee the privacy of the information FTP transmits, a strong
encryption scheme should be used whenever possible."]
The client, and its vendor, are being stubborn-headed in insisting that
they're RFC compliant. For that matter, so's a brick - it refuses all
access. That doesn't make it useful. Your vendor doesn't want to add the
few lines that it takes to make their client more useful in the days of an
unsecured Internet. Dump your client vendor and go with one that gives even
the slightest damn about security.
>Any comments, feedback, etc. appreciated.
I like RFC 2577. It has my name in it.
>Perhaps THIS IS A Microsoft bug???
No, it's a rare occasion of Microsoft being more secure than is desired by
your vendor.
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.
- Next message: swbell.net: "sign in"
- Previous message: Jeff Cochran: "Re: "we have been hacked""
- In reply to: DavidM: "Microsoft FTP Server problem on W2K?"
- Next in thread: DavidM: "Re: Microsoft FTP Server problem on W2K?"
- Reply: DavidM: "Re: Microsoft FTP Server problem on W2K?"
- Reply: Pete Hornby: "Re: Microsoft FTP Server problem on W2K?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
