Re: [fw-wiz] CERT vulnerability note VU# 539363

From: Mikael Olsson (mikael.olsson@clavister.com)
Date: 10/16/02 

From: Mikael Olsson <mikael.olsson@clavister.com>
To: Stephen Gill <gillsr@yahoo.com>
Date: Wed Oct 16 17:00:13 2002

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 ***-
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