On 30 jun 2011, at 12:19, Fernando Gont wrote: >>> I thought server-to-server transfer had been banned for many years >>> now (it was exploited for address scan purposes). Am I missing >>> something?
>> Do you have a reference? > * http://nmap.org/hobbit.ftpbounce.txt > * http://www.cert.org/advisories/CA-1997-27.html > * http://cr.yp.to/ftp/security.html I don't think these three are useful as they fall outside the scope of the IETF. > * IETF RFC 2577 I think this is the relevant part: Disabling the PORT command is also an option for protecting against the bounce attack. Most file transfers can be made using only the PASV command [Bel94]. The disadvantage of disabling the PORT command is that one loses the ability to use proxy FTP, but proxy FTP may not be necessary in a particular environment. This doesn't forbid or deprecate server-to-server transfers. >> As it's only listed here as an example of something that isn't >> addressed, I don't think it's an issue to include this here. > The point is that proxy FTP is not supporting in the FTP software I checked. FTP predates TCP/IP but I doubt many implementations can still run over NCP... Unfortunately there is no single FTP spec that lists only those things still in active use. In fact, earlier this week I found out that wu-ftpd still supports RFC 1639 long addresses, which is an experimental spec to support non-32-bit addresses before IPv6 was standardized. And being good students of Jon Postel, we are conservative in what we send and liberal in what we accept. [urgent data] > Well, *TCP* does not state what should be done with the urgent data, > since it doesn't know what's the application on top. But if you ignore > urgent indications, you won't be able to interrupt ongoing commands > (e.g. RETR). -- so my take is that this is important for FTP. > Unfortunately, as noted in RFC6093, some middleboxes already play with > urgent indications. BUt if you deliberatly ignore it, this would > exacerbate the problem. I tried interrupting a transfer, and my client (the MacOS commandline one) did indeed send a packet with urgent data to ftp.nluug.nl but the transfer didn't get aborted so apparently it may be unreliable either way. So I want to add this text: Some FTP clients use the TCP urgent data feature when interrupting transfers. An ALG MUST either maintain the semantics of the urgent pointer when translating control channel interactions, even when crossing packet boundaries, or clear the URG bit in the TCP header. >> I think it's not worth the trouble and unlikely to be tested well, so >> I would be in favor of clearing the URG flag. Any objections? > My understanding is that the implications of this is that you no longer > will be able to abort commands (head of line blocking). Hm, doesn't this only apply to the situation where command 1 is being executed, command 2 has been given but is waiting to be executed and command 3 is ABOR? The urgent pointer allows the server to look at the ABOR even though command 2 is earlier in the pipeline. But if there is no command 2 it shouldn't matter.
