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.olssonat_private> Organization: Clavister AB To: danielat_private Cc: firewall-wizardsat_private, "Paul D. Robertson" <probertsat_private> 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-wizardsat_private http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
This archive was generated by hypermail 2b30 : Wed Oct 16 2002 - 11:50:16 PDT