On 5/4/05, Jon Hart <[EMAIL PROTECTED]> wrote:
> On Wed, May 04, 2005 at 04:00:20PM +0200, Henning Brauer wrote:
> > * Jon Hart <[EMAIL PROTECTED]> [2005-05-04 14:35]:
> > > but you should definitely
> > > be specifying which combination of TCP flags can create the initial
> > > state here.  Try "flags S/SA" as a start.
> >
> > no, this is bad advice and certainly not related to the problem. this
> > whole flags filtering is mostly masturbation.
> 
> Thats why I stated "This probably is not the cause of the problem".  It
> was mere advice.
> 
> If this "masturbation" is just that, then why is it used fairly
> consistently in pf.conf(5)?  Sure, I'm not a huge fan of the rulesets
> that have been posted in the past that do crazy flag filtering to do
> things like filter out all the possible TCP flags combinations that nmap
> sends, being explicitly RFC compliant, etc.  On the other hand, without
> any flag specifications, would that allow any TCP packet to create
> state and subsequently get passed?
> 
> -jon
> 

Interesting...Could Henning explain why it's "bad advice"? A little
paranoid maybe, but what does it hurt?

I guess the one downside I can think of is that if the state table
gets flushed for some reason, established connections will be lost.
And I don't know enough about cracking to know what harm non-syn
packets could do if they get through to my network. So I'm pretty
interested in what you guys think.

Jonathan

Reply via email to