Re: CERT vulnerability note VU# 539363

[Frank Knobbe <fknobbe () knobbeits com>]

On Wed, 2002-10-16 at 08:36, Paul D. Robertson wrote:
> [...] 
> If you're hosting public resources behind the same firewall that's 
> protecting everything else in your enterprise, you've probably made a 
> questionable architectural decision.  If you're keeping state on say 
> inbound SMTP traffic, the question is "Why?"  If the 'Net as a whole can 
> connect to something, the state itself isn't going to do much good.  

Not for inbound connections, but doesn't a stateful firewall prevent
non-legit outbound connections? If the firewall protecting a web server
were stateless (read packet filter), the web server could establish
connections to the outside with a source port of 80, and a backdoor
would be able to connect to its master. However, if state is kept, and
only inbound connections to port 80 are allowed, then the backdoor can
not establish a connection to the outside using source port 80.

To me it seems that stateless access control only protects my side from
incoming traffic, but I also want to enforce access control on outbound
traffic. In order to distinquish between a valid response, and a new
connection, isn't state helpful?

I understand that I could filter any packets from the web server (in
above example) by denying packets with SYN flag set, so maybe above rant
is only valid for UDP. But in general I believe state is useful in
access control. Or am I way off? 


Regards,
Frank

Attachment: signature.asc
Description: This is a digitally signed message part