On Wed, 24 Jan 2007 14:20:46 -0800 "Kian Mohageri" <[EMAIL PROTECTED]> wrote:
> On 1/24/07, Travers Buda <[EMAIL PROTECTED]> wrote: > > > Last time I checked though, clients only talk with the web server on > > port 80. So, the only reason you would want to keep state would be if > > you have a ruleset like block out all (which is generally only usefull > > if you don't trust the users of said machine.) So, just unconditionally > > pass port 80 traffic in both directions. > > > > That was really bad advice. Stateful filtering is much more efficient, and > that is very important for a firewall handling thousands of connections. > The default state limit of 10,000 is pretty reasonable and you can change it > easily. I usually have around 100,000 states on my firewall. You can also > put limits on the number of states each client can create to prevent Denial > of Service. In my opinion, it is best to keep state unless you have a > reason NOT to. > > Keeping state will soon be the default behavior in pf...that says something > about it. > > Also see the three articles Daniel Hartmeier wrote: > > http://undeadly.org/cgi?action=article&sid=20060927091645 > > -- > Kian Mohageri > That is a good point that state table lookups are cheaper. You're right, keep state should be faster. On the other hand, if you are in dire need of more ram, one could put pass in quick proto tcp from any to any port 80 at the top of their filtering rules (but below blacklisted IP's =)). Note the "quick," option. This would help mitigate the speed loss. Alec, would you mind doing a brief benchmark of the two techniques? Just for kicks. Travers Buda
