Date: Fri, 21 Jan 2000 07:10:57 -0800 From: gdonl@tsc.tdk.com (Don Lewis) To: Matthew Dillon <dillon@apollo.backplane.com>, Brett Glass <brett@lariat.org> Cc: Alfred Perlstein <bright@wintelcom.net>, security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths Message-ID: <200001211510.HAA13068@salsa.gv.tsc.tdk.com> In-Reply-To: Matthew Dillon <dillon@apollo.backplane.com> "Re: stream.c worst-case kernel paths" (Jan 20, 9:21pm)
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 20, 9:21pm, Matthew Dillon wrote: } Subject: Re: stream.c worst-case kernel paths } } :How about one of the "golden" releases along 3.X-STABLE? After all, those } :of us who are conservative will not be deploying 4.X in mission-critical } :applications until the 4.1 or 4.2 point release (depending on how well } :things go). } : } :I'd certainly like to see TCP_RESTRICT_RST on by default. Blocking RSTs } :is getting to be a standard feature. Our lab's Windows boxes run BlackIce } :Defender, which does this, and it makes them pretty resilient. } : } :And is there any reason NOT to turn on TCP_DROP_SYNFIN? } : } :--Brett } } I think it's a bad idea to make anything that breaks the protocol } standard the default. I don't like the idea of always dropping (instead } of sending an RST) - it's much better to band-limit the rate to deal } with D.O.S. attacks and follow the protocol spec at all other times. I agree. Failing to set RST makes SYN floods worse. The victim machine will have more sockets hanging around in a SYN-SENT state that keep sending SYN+ACK packets until the sockets times out. If the spoofed clients send RST packets in response, then the server will immediately nuke these sockets and won't have their incoming bandwidth consumed by the packets they are ignoring (they'll receive one packet and send one packet for each spoofed SYN instead of receiving N packets and sending none if they don't send RST packets). It's also a lot easier to spoof a TCP connection from a host that doesn't send RST packets. } For the same reason I don't particularly like the idea of killing } SYN+FIN gratuitously. I couldn't care less whether nmap is able } to identify my machine or not, but I care greatly about protocol } breakage. You can't drop SYN+FIN packets if your want to do T/TCP. The only thing dropping them buys you is that you can hide some information from nmap. They don't have any more DoS potential then plain old SYN packets. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001211510.HAA13068>