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

[mag () bunuel tii matav hu (Magosányi Árpád)]

A levelezőm azt hiszi, hogy Mikael Olsson a következőeket írta:
> > 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.

Those SPFs just _try_ to do exactly that. As I have mentioned it is not
just extremely complicated to do with a packet filter, but also impossible.
(Because recognition of a known pattern in a tcp traffic with packet filters is
theoretically impossible. See http://www.insecure.org/stf/secnet_ids/ for more details.)

> > 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

I was imlpying those attacks where you should do some communication
back and forth until you reach the state where the vulnerability lies.
(Yes, you can predict the answers, but with what probability?)

> > 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.

This is why I used the word "may".

> > BTW, is there any app
> > level firewall besides Zorp which can do active-passive conversion?
>
>
> > 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.

Recognition of a known pattern in a tcp traffic with packet filters is 
theoretically impossible.

Well, to "inspect any protocol to such great extent that all attacks are 
thwarted" is of course impossible. But when I start to build a real firewall,
I want to run off information on the defended system and used protocols and
implementations _before_ I run off the possibilities of defence.

> > 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.

Agreed:) My main point was whether and how should we generalize this question
to the question of when and how should we break standards.

>  
> > traffic filtering routers are not firewalls.
>
> Excuse me?

I think that the main point of the firewall is being a security device, enforcing
a policy. I expect a security device to defend against attacks it is supposed to
withstand. A firewall is in an ideal case is supposed to defend against all attacks.
In the real word it should defend against all handleable (think of DoS) classes
of attacks I can think of. Packet filtering routers are not in this
category. Most of the firewall are also not in this category, but firewalls
in theory could be, while packet filters couldn't.

[The last part is the old proxy/packet filter flamewar. Sorry about that.]

-- 
GNU GPL: csak tiszta forrásból
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards