The yearly FTP rant (Was: Re: Passive FTP and NAT/PAT with PIX and Serv-U)

[Mikael Olsson <mikael.olsson () clavister com>]

It would appear that it is again time for my FTP rant, so I'm 
redirecting my response back to the list.

someone wrote, off list:
> [on passive/active mode, and which connection goes where]
> Oh agreed. It depends on whether you are the client or
> the server. But what was that about layer 7 magic? I
> didnt understand that part.

In active mode, the client's firewall needs to open holes for the 
dynamic server->client data connection back to the client. 

In passive mode, the server's firewall needs to open holes for the 
dynamic client->server data connection back to the server.

Especially in the active mode to client case, but also often in the 
passive mode to server case, this is done through "layer 7 magic", 
where the firewall parses the application layer data to learn which 
dynamic holes to open back to the client / server.


HOWEVER, as I said previously in this thread, the server side MAY be 
solved without "L7 magic", since it is generally possible to allocate 
a public IP for the FTP server and allow port 21 and a range of high 
ports inbound. With some FTP servers, it is even possible to hard-code 
the range of high ports the server will listen on in passive mode.  
This is usually more secure, since it has been proven over and over 
again that most stateful inspection firewalls are apparently incapable 
of parsing the command channel properly. (I'm not surpised; bypassing
the layering model and grepping for strings in raw, unreassembled L7 
data just because it "usually" produces the right results is about as 
good an idea as strapping a pound of C4 to your gonads and painting a 
bulls-eye on your shorts.) (And yes, I believe this goes for IDSes too.)


Having said that, I also need to say that even full proxy firewalls 
have security problems with FTP and other dynamic channel protocols.
In the FTP case, and probably the other ones too, this problem is more 
pronounced on the client side. (Although I make no promises for
glitzy "server" apps that support the latest in multimedia magic.)

In summary: someone needs to put a bullet through the FTP spec
and force-feed the idea that implementing something new and better
is a Good Thing(tm) down our collective throat.

Heck, simply moving the data channel to an in-line channel in
the port 21 connection would be by far more preferable, and easier
to implement to boot. I can't believe they botched the perfectly 
good chance of clearing up this old mess when they adapted FTP to 
IPv6, rather than just extending the "PORT" and "227" messages to 
handle IPv6 addresses in ASCII format. (But then again, I'm a 
grumpy security guy whose pet peeve is protocols with dynamic 
channels, not a stressed-out engineer who needs to get things 
working yesterday.)


I dread the day when the manglements of companies worldwide start
declaring SIP based applications Mission Critical. It seems to be
worse by an order of magnitude. (But I need to do some reading up
before I can really say that authoratively.)


... okay, I'm done now ;)

/Mike

-- 
Mikael Olsson, Clavister AB
Storgatan 12, Box 393, SE-891 28 ÖRNSKÖLDSVIK, Sweden
Phone: +46 (0)660 29 92 00   Mobile: +46 (0)70 26 222 05
Fax: +46 (0)660 122 50       WWW: http://www.clavister.com

For bored sysadmins: http://lart.badf00d.org
_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://list.nfr.com/mailman/listinfo/firewall-wizards