Stephen Gill wrote: > > 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. Well, I've been considering the pros and cons of using SYN cookies in our firewall. Generally speaking, I don't think it's worth it in a firewall. A state table replacement function that prefers replacing connections in SYN state seems much more worth while to me. It eliminates the SYN cookie problem of keeping track of MSS, TSOPTs, SACK, etc. Sure, there are clever ways of encoding approximations of these things in the cookie, but that also destroys the strength of the cookie hash. Now, add TCP ECN plus its upcoming extensions to this mess, and I see us going down a slipperly slope that lands us at a hash strength that is easily brute forced -- we'd be back at "predictable ISNs" again. > ] 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. I assume you're NOT talking abuot SYN cookies here; I see no way of doing those without keeping state for established sessions. Maybe you're talking about rate limiting SYNs? Yes, that works. I think it's butt- ugly and flakey at best, but, yes, it's doable. > > ] - 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. Yes, I made an assumption that I didn't spell out: In a high bandwidth / connection establishment scenario where you go for stateless forwarding rather than stateful tracking, you're likely not really interested in logging every single packet. That would be really painful, and probably better left to "Network VCRs" and other dedicated sniffer gizmos. However, I also missed the obvious: one _might_ be interested in logging SYN/FIN/RST packets, which, of course, is doable without keeping state. (Yes, this could be abused, but logging state creation/destruction is no better in this respect.) -- 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 _______________________________________________ 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 - 14:36:38 PDT