Date: Fri, 21 Jan 2000 20:58:43 -0700 From: Brett Glass <brett@lariat.org> To: keramida@ceid.upatras.gr Cc: Matthew Dillon <dillon@apollo.backplane.com>, Warner Losh <imp@village.org>, Darren Reed <avalon@coombs.anu.edu.au>, security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths Message-ID: <4.2.2.20000121204210.019817b0@localhost> In-Reply-To: <20000122044638.B27337@hades.hell.gr> References: <4.2.2.20000121163937.01a51dc0@localhost> <200001210417.PAA24853@cairo.anu.edu.au> <200001210642.XAA09108@harmony.village.org> <200001212321.PAA64674@apollo.backplane.com> <4.2.2.20000121163937.01a51dc0@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
At 07:46 PM 1/21/2000 , Giorgos Keramidas wrote: >So what needs to be done is: > >(a) drop all multicast packets that reach the tcp stack. >(b) extend ICMP_BANDLIM to RST packets, and >(c) avoid sending anything tcp to a multicast address > >Do I forget something here? (d) Don't *accept* TCP from a multicast address. And a few other possible refinements: 1. Don't look for a listening socket when we receive a packet that's not a SYN. Trivial and fast, and it eliminates some awkward code that catches this situation after the fact. 2. Consider starting the rate limit on RSTs off high at boot time (when cleanup might be needed) and ramping it down to a lower user-configurable level after that. Let the final level be settable to zero if the user doesn't want to be probed easily but does want to kill old connections. If the user is really paranoid, he can set the starting level at zero as well, thus killing all RSTs and committing heresy against the IETF. ;-) 3. Consider not sending RSTs in response to certain attacks, such as FIN probes. 4. Consider lazy checksumming of the TCP payload. Though, frankly, since one checksum covers the TCP header and the data, and you need to test the checksum to get at the port numbers, control bits, etc., it really can't be deferred very much. --Brett 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?4.2.2.20000121204210.019817b0>