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
This archive was generated by hypermail 2b30 : Wed Oct 16 2002 - 09:30:38 PDT