Summer is over. School is back in session. The 4,500 students behind my
OpenBSD 3.5 pf firewall are mostly settled into their dorm rooms. My
nightmare begins. A single Blaster infection can spray out thousands of
connections in seconds. One sad day, I had to reboot my firewall three or
fou
> 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
How did I miss that? Probably panic mode.
Once again I am awed by and indebted to this list. Thanks for the prompt
response!
jw
On Mon, 23 Aug 2004, Mike Frantzen wrote:
My first thought is to cron a job, once a minute, to monitor the number of
states in `pfctl -s info` ... if any single m
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 i
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 st
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
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:
> http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf_table.c.diff
On Monday 23 August 2004 23:49, Mike Frantzen wrote:
> > 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 t
> > > 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 sta
On Tuesday 24 August 2004 15:27, Mike Frantzen wrote:
> There we'll agree to disagree. I prefer Amdahl's law which tells me to
> optimize for the common case instead of degrading everything to the
> pathological case.
I prefer to have a fixed limit for every IP instead of a firewall that changes
* 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:
> > http
* Ed White <[EMAIL PROTECTED]> [2004-08-24 17:48]:
> On Tuesday 24 August 2004 15:27, Mike Frantzen wrote:
> > There we'll agree to disagree. I prefer Amdahl's law which tells me to
> > optimize for the common case instead of degrading everything to the
> > pathological case.
> I prefer to have a
how about using 3.6 instead? snapshots are out there. it has shitloads
of improvememts in that area.
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 RTF
change log ... but what can you tell me in the brief m
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 <[EMAIL PROTECTED]> [2004-08-24 20:52]:
> >how about using 3.6 instead? snapshots are out there. it has shitloads
> >of improvememts in that area.
> Could you post a brief synopsis, marketroid style, of incentives to
> upgrading to 3.6?
want me to babble on some mailing list or work
I know I could RTF change log ... but what can you tell me in the brief
moments I have between firefights?
plus.html
basically all network related problems wrt kernel memory have been
solved. at least all that I am aware of.
Wow, you guys didn't pommel me like I thought you would. This is exactly
On Tuesday 24 August 2004 21:18, Henning Brauer wrote:
> basically all network related problems wrt kernel memory have been
> solved. at least all that I am aware of.
I like the work made by Cedric that permits return-icmp/rst on IPless bridge.
Also return-icmp-as-dest should be included, right ?
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.
On Wed, 2004-08-25 at 05:46, Henning Brauer 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 Jac
> 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)
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 thoug
On Wednesday 25 August 2004 00:53, Russell Fulton 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
* Russell Fulton <[EMAIL PROTECTED]> [2004-08-25 11:41]:
> On Wed, 2004-08-25 at 05:46, Henning Brauer 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, tha
26 matches
Mail list logo
