RE: CERT vulnerability note VU# 539363

["Stephen Gill" <gillsr () yahoo com>]

Hi Mike,

] Of course, there's also the issue of establishing new sessions. If
you're ] opening and tearing down sessions at a fearful ratio (tens of
thousands of 

Yeah, this is pretty much worst case since it involves the most amount
of resources for establishment.  

] states per second), you might be better off 
] (if security allows it) to have maybe a dozen or so stateless packet 
] packet forwarding rules at the top of the ruleset.

Interesting.  Tradeoffs are performance of state for established
sessions, or performance of no state for new connections.

I've not seen much discussion on TCP SYN Cookies for SYN Flood
protection on server side.  NS, CP, Cisco, and some others showed some
interest in it but I haven't seen it deployed aside from Linux and some
other Unix variants.  This would in theory eliminate the state problem
for TCP at the cost of a couple of minor annoyances.  This could be
dynamically enabled when a certain threshold is reached (under DoS) so
that you don't always have it in service.

http://www.qorbit.net/documents/maximizing-firewall-availability.pdf
http://cr.yp.to/syncookies.html

] Of course, with stateless filtering rules, you'll lose things like:
] - SYN flood protection

Not necessarily.  Depends on what your methods of SYN protection are.

] - TCP ISN randomization
] - LOGGING!

I would think you can still log here when you match a rule.  Perhaps I'm
missing something.  Of course, you'd probably only have logging for
things such as TCP control connections or limit matches for active in
some way.

Cheers,
-- steve


----------------


Date: Wed, 16 Oct 2002 17:55:20 +0200
From: Mikael Olsson <mikael.olsson () clavister com>
Organization: Clavister AB
To: daniel () benzedrine cx
Cc: firewall-wizards () honor icsalabs com,
        "Paul D. Robertson" <proberts () patriot net>
Subject: Re: [fw-wiz] CERT vulnerability note VU# 539363 (fwd)


"Daniel Hartmeier" wrote:
> I think most people (falsely) assume that filtering statelessly is 
> faster with their rule sets. Even simple real-life filter policies put

> create less load on the firewall when state is being kept.

Just to corroborate: I agree 100% with this.

In my experience (our stuff), ruleset lookup hits on stateless packet 
forwarding rules at the _very top_ of the ruleset is comparable to 
keeping state.

Anything below the very top will start showing differences, and for
someone that needs "maximum throughput", hits on rules 100+ can be
"painful".

We should have PDFs that show the exact ratios for our gear lying around

here somewhere, but people have left for the day and I can't seem to
find them. :/


Of course, there's also the issue of establishing new sessions. If
you're opening and tearing down sessions at a fearful ratio (tens of
thousands of states per second), you might be better off 
(if security allows it) to have maybe a dozen or so stateless packet
packet forwarding rules at the top of the ruleset.

Of course, with stateless filtering rules, you'll lose things like:
- SYN flood protection
- TCP ISN randomization
- LOGGING!

-- 
Mikael Olsson, Clavister AB
Storgatan 12, Box 393, SE-891 28 ÖRNSKÖLDSVIK, Sweden
Phone: +46 (0)660 29 92 00   Mobile: +46 (0)70 26 222 05
Fax: +46 (0)660 122 50       WWW: http://www.clavister.com

"Senex semper diu dormit"

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards