In message <3EB995FB.2010401@berklee.edu>, "Louis Guillaume" writes:
>
>Steven M. Bellovin wrote:
>
>> In message <3EB984D9.8090403@berklee.edu>, "Louis Guillaume" writes:
>> 
>>>Hello,
>>>
>>>I've been having a great big fight with my network admin over access to 
>>>ftp.netbsd.org (or anoncvs) through our Checkpoint Firewall. It's 
>>>version "NG - patch level 4".
>>>
>>>The session looks like this...
>>>
>>># ftp -a ftp.netbsd.org
>>>Trying 2001:4f8:4:b:2e0:81ff:fe21:6563...
>>>ftp: connect to address 2001:4f8:4:b:2e0:81ff:fe21:6563: No route to host
>>>Trying 204.152.184.75...
>>>Connected to ftp.netbsd.org.
>>>220 ftp.netbsd.org FTP server (NetBSD-ftpd 20020615) ready.
>>>331 Guest login ok, type your name as password.
>>>230-
>>>421 Service not available, remote server has closed connection.
>>>ftp: Login failed.
>>>ftp>
>>>
>> 
>
>Thanks very much for this fix. The problem I forsee, is that my Network 
>admin will look at this doc from Checkpoint...
>
>http://www.checkpoint.com/techsupport/alerts/pasvftp.html
>
>... and say that it's a security issue, and that we would be de-grading 
>the firewall.
>
>Does the ftp server actually need to be patched?
>

I love that Web page -- what it doesn't say is "Checkpoint FW-1 does a 
half-hearted job of parsing FTP control connections, so it's 
vulnerable."  Also, if I interpret it correctly, the risk is if the FTP 
*server* is behind a Checkpoint firewall -- at least, I don't see how 
that could be a risk otherwise.  (Explanation:  in FTP, data is 
transferred over a separate TCP connection.  In default FTP mode, the 
PORT command is used, which means that the FTP server will do an active 
open to a socket on which the client is listening.  This means that the 
client's firewall has to parse the FTP connection, and temporarily open 
up a port for incoming traffic.  This has its own security issues -- 
see, for example,

@inproceedings{Martinetal,
        author = {David M. Martin and Sivaramarkrishnan Rajagopalan and Aviel D. Rubin},
        title = {Blocking {Java} Applets at the Firewall},
        year = 1997,
        month = {February},
        booktitle = {Proceedings of the Symposium on Network and Distributed System Security},
        address = {San Diego},
        pages = {16--26}
}

Also google for "ftp bounce attack".

The alternative is PASV mode.  In PASV mode, the client asks the server 
for an address and port number; the server creates a socket and tells 
the client.  This means that the client is only making outgoing calls, 
which is generally permitted without restriction by most firewalls.  
See RFC 1579, by your truly.  If the client's firewall has that 
permissive policy, there's no need for the client firewall to even look 
at the FTP control connection in that case, though of course it will 
because it probably doesn't know in advance that PASV will be used.
(Well, in my opinion good firewalls don't permit PORT-mode ftp clients, 
but my opinion doesn't rule -- and since you have to configure IE 
explicitly to use PASV, firewall vendors are not going to adopt my idea 
of a sane policy.  Mumble -- Microsoft does it again.)

However, if the FTP *server* is behind a firewall -- a very dubious 
setup in any event -- *its* firewall has the converse problem; PORT is 
easy, but PASV is hard.  Worse yet, Checkpoint was lazy -- rather than 
actually parsing a full TCP stream, they're looking at one packet at a 
time.  If a response from the server -- say, a PASV message, which 
specifies a port number to open up -- spans a packet, it would have 
trouble, and could be deceived about which port to open.  Their "fix" 
is to look for a NL at the end of a packet, i.e., so they know where 
the response line ends.  

The fix doesn't work that well, btw.  See, for example,
http://www.securityfocus.com/archive/82/50226 for details.

Anyway -- feel free to show this to your network administrator.  Beyond 
that, you might want to see if Checkpoint has a better fix -- that note 
is 3 years old.  And there's a work-around that should work -- the 
problem here is being triggered by the very long motd that 
ftp.netbsd.org is emitting.  You can shut it up by sending a password 
starting with a '-' -- that should avoid the problem.

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)