On Wednesday 25 August 2004 14:02, Ed White wrote:
limiting the # of states a single source node can create is also a good
idea, but less so to protect the firewall, more to protect the internet
from machines gone nuts, that got hit by a worm or whatever.
I've looked though my copy of
JW Summer is over. School is back in session. The 4,500 students behind my
JW OpenBSD 3.5 pf firewall are mostly settled into their dorm rooms. My
JW nightmare begins. A single Blaster infection can spray out thousands of
JW connections in seconds. One sad day, I had to reboot my firewall
Mike Frantzen writes:
With gnutella running, my laptop has 208 PF states and 190 of which are
in fin-wait or closed.
Ok, question here, for my own edification: when a socket is in such a
state (wait, closed) is the socket simply waiting for the parent process
to garbage dispose of the associated
On 08/23, Jeff Wilson wrote:
Summer is over. School is back in session. The 4,500 students behind my
OpenBSD 3.5 pf firewall
...
My first thought is to cron a job, once a minute, to monitor the number of
states in `pfctl -s info` ... if any single minute yields an increase of
more than
That will not help you to solve the problem. It will only cause some
troubles to valid connection states.
Nope. The point of the adaptive limits was to only start penalizing
things when the firewall is overloaded. Read-on
When the firewall is overloaded someone trying to start a valid
* Ed White [EMAIL PROTECTED] [2004-08-24 12:30]:
On Tuesday 24 August 2004 00:10, Csillag Tamas wrote:
AFAIK Openbsd 3.5 only use 64Mb memory for pf ruleset and state table
someone posted here a link to the (unofficial?) patch, that changes that.
Search in the archives for:
OpenBSD 3.6 now comes with shiney red buttons. Buy it starting November
1st.
On Tue, 24 Aug 2004 13:47:15 -0500 (CDT)
Jeff Wilson [EMAIL PROTECTED] wrote:
:Could you post a brief synopsis, marketroid style, of incentives to
:upgrading to 3.6? (BTW, when will it be released?) I know I could
Jeff Wilson wrote:
Wow, you guys didn't pommel me like I thought you would.
I'm sure that if you ask really nicely, someone would be glad to pummel
you. Or you could just ask on misc@ about what hardware makes a good
server on OpenBSD. :)
Jon
Peter Hessler writes:
OpenBSD 3.6 now comes with shiney red buttons. Buy it starting November
1st.
Har!
---
That was Zen, this is Tao.
Speaking of network bugs in kernel memory ... does this look pathological?
Even with adaptive start set pretty agressively, I'm still getting kernel
panics. (using -stable 3.5)
Do this to calculate the max number of PF states you can allocate (on
top of what have already been allocated)
$
My first thought is to cron a job, once a minute, to monitor the number of
states in `pfctl -s info` ... if any single minute yields an increase of
more than 50,000 states, then I flush all states and reload the ruleset.
Is there a better way to contain disaster? With ipfilter, I tweaked
On Monday 23 August 2004 19:04, Jeff Wilson wrote:
Once again I am awed by and indebted to this list. Thanks for the prompt
response!
That will not help you to solve the problem. It will only cause some troubles
to valid connection states.
You should use src-ip-tracking limiting the number
Once again I am awed by and indebted to this list. Thanks for the prompt
response!
That will not help you to solve the problem. It will only cause some troubles
to valid connection states.
Nope. The point of the adaptive limits was to only start penalizing
things when the firewall is
13 matches
Mail list logo
