From owner-freebsd-security Fri Jan 21 7:11:13 2000 Delivered-To: freebsd-security@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id 2F7BA1544D for ; Fri, 21 Jan 2000 07:11:04 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from imap.gv.tsc.tdk.com (imap.gv.tsc.tdk.com [192.168.241.198]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id HAA05873; Fri, 21 Jan 2000 07:10:58 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by imap.gv.tsc.tdk.com (8.9.3/8.9.3) with ESMTP id HAA47735; Fri, 21 Jan 2000 07:10:57 -0800 (PST) (envelope-from Don.Lewis@tsc.tdk.com) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id HAA13068; Fri, 21 Jan 2000 07:10:57 -0800 (PST) Message-Id: <200001211510.HAA13068@salsa.gv.tsc.tdk.com> From: gdonl@tsc.tdk.com (Don Lewis) Date: Fri, 21 Jan 2000 07:10:57 -0800 In-Reply-To: Matthew Dillon "Re: stream.c worst-case kernel paths" (Jan 20, 9:21pm) X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Matthew Dillon , Brett Glass Subject: Re: stream.c worst-case kernel paths Cc: Alfred Perlstein , security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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