Re: Phrack #60: "Java tears down the Firewall"

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

Árpád, Magosányi wrote:
> [regarding java applets playing evil active mode FTP clients]
>
> The first one is whether a good app level firewall can defend again this 
> kind of attack? Not exactly. But can do more defense than a stateful packet 
> filtering router. Tracking whether the data should go in or out is more 
> complicated with a packet filter (and theoretically impossible also). 

Bull. I know for a fact that several SPFs do exactly this. But even with 
such a protection in place, _many_ services are vulnerable. See below.


> Stopping one direction can
> make the attack unfeasibly complicated and more easily observable with
> whole classes of attacks. 

Any service that has a vulnerability 
(buffer overrun or otherwise) that can be triggered with a single
TCP exchange is indeed vulnerable. This definately includes HTTP
servers (like systems management agents installed by default by
many OEMs, commonly running on high ports), but with stacked commands, 
one can attack many other types of services.


> Converting active connections to passive may also
> make the logic on the server side (if any) confused. 

If you mean: client speaks active, server speaks passive: yes, the 
server would be confused if it did not understand it. It is however
only security through obscurity; it is equally exploitable.

If you mean: client speaks passive, server speaks active: well, then
there's not a problem. But the problem here was firewalls that 
"protect" clients allowed to speak active mode FTP.


> BTW, is there any app
> level firewall besides Zorp which can do active-passive conversion?

Client active -> server passive?  I don't really know. It's not a 
useful conversion to do, neither from a security nor functionality
standpoint.

Client passive -> server active? I know of at least two more.
There might be more.


> Defense against known attack signatures is also more easy with a good app
> level firewall, as it can match against signatures in the data channel.

Ah, is this the same "can" that dictates that proxy firewalls "can inspect
any protocol to such great extent that all attacks are thwarted?".
Practice has thus far fallen woefully short of theory.


> The second question is whether a data channel should go to the same machine
> where the control channel is. 

I'd expect all firewalls worth being called firewalls to enforce this 
by default.  Some people want to allow server-to-server transfers ("FXP"), 
but support for that should, IMHO, be optional in a firewall, and in either
case off by default.

 
> traffic filtering routers are not firewalls.

Excuse me?


-- 
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
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards