Firewall Wizards mailing list archives
Re: CERT vulnerability note VU# 539363
From: Daniel Hartmeier <daniel () benzedrine cx>
Date: Wed, 16 Oct 2002 16:05:44 +0200
On Wed, Oct 16, 2002 at 09:36:06AM -0400, 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. If you're trying to rewrite sequence numbers because of a host that talks to the public with high predeictability, again you're probably made a questionable architectural decision.
Keeping state can have performance benefits. Depending on your rule set, associating a packet with a state entry is cheaper than evaluating the rules. Keeping state does not 'just' increase the quality of filter decisions.
Public-talking hosts should be protectable with simple non-stateful packet filtering rules- *especially* those which allow the untrusted side to initiate connections.
In my experience, allowing to specify a maximum for the number of states created by a filter rule is very useful in this case (if you want to keep state on all connections, and everything passes through the same firewall). While an attacker can exhaust the individual maxima for incoming connections to different services, other kinds of connections (like outgoing connections, or connections the attacker can't establish) are not affected. Daniel _______________________________________________ firewall-wizards mailing list firewall-wizards () honor icsalabs com http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
Current thread:
- Re: CERT vulnerability note VU# 539363, (continued)
- Re: CERT vulnerability note VU# 539363 Daniel Hartmeier (Oct 16)
- RE: CERT vulnerability note VU# 539363 Stephen Gill (Oct 16)
- RE: CERT vulnerability note VU# 539363 R. DuFresne (Oct 16)
- RE: CERT vulnerability note VU# 539363 Stephen Gill (Oct 16)
- RE: CERT vulnerability note VU# 539363 R. DuFresne (Oct 16)
- RE: CERT vulnerability note VU# 539363 Stephen Gill (Oct 16)
- RE: CERT vulnerability note VU# 539363 Ofir Arkin (Oct 16)
- RE: CERT vulnerability note VU# 539363 Stephen Gill (Oct 16)
- Re: CERT vulnerability note VU# 539363 R. DuFresne (Oct 16)
- Re: CERT vulnerability note VU# 539363 Daniel Hartmeier (Oct 16)
- Re: CERT vulnerability note VU# 539363 Paul D. Robertson (Oct 16)
- Re: CERT vulnerability note VU# 539363 Mikael Olsson (Oct 16)