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>