Date: Fri, 21 Jan 2000 20:40:37 -0700 From: Brett Glass <brett@lariat.org> To: Matthew Dillon <dillon@apollo.backplane.com>, Dag-Erling Smorgrav <des@flood.ping.uio.no> Cc: Keith Stevenson <k.stevenson@louisville.edu>, freebsd-security@FreeBSD.ORG Subject: Re: Some observations on stream.c and streamnt.c Message-ID: <4.2.2.20000121195112.0196a220@localhost> In-Reply-To: <200001220245.SAA66403@apollo.backplane.com> References: <4.2.2.20000120194543.019a8d50@localhost> <Pine.BSF.4.10.10001211419010.3943-100000@tetron02.tetronsoftware.com> <20000121162757.A7080@osaka.louisville.edu> <xzpk8l2lul4.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
At 07:45 PM 1/21/2000 , Matthew Dillon wrote: > Second, you purport that TCP_RESTRICT_RST is a better solution. > I'll tell you something about TCP_RESTRICT_RST: It's garbage. It should > never have been committed into the tree. It takes out *EVERY* single > goddamn RST response in the entire TCP input chain, even the ones that > couldn't possibly be related to an attack. You propose rate-limiting RSTs, and I agree that this could help against an attack. But there are two problems. First, it allows port probing; and second, it might actually be a problem if a system crashes while a large number of connections are active and then immediately reboots. The flurry of necessary RSTs sent at the outset might exceed the limit and fail to clean up the mess. So, you'd probably want to allow a fairly high rate of RSTs at boot time (not enough to crash the machine) and then fewer later on. Things WILL get back to normal quicker if you can RST all of the sessions that were active before the reboot. In this situation you are absolutely right: RSTs can do something useful. It is also true that a RST can defeat spoofed sessions, but the benefit is small. In attacks involving spoofing the person sending the spoofed packet generally doesn't intend to establish a session and won't get the RST anyway. Rather, he or she is wasting the machine's time and/or resources (e.g. by SYN flooding). And as we've seen, the RST can amplify the attack by triggering ICMP traffic. So, one might argue that RSTs could (and should!) be turned off a certain amount of time after a machine boots. After all, once it's past the time when they can reasonably used to kill old sessions, they're pretty much only going to be responses to attacks (see RFC 793). And they'll allow port probing. My preference as a sysadmin would therefore be to rate-limit during the "cleanup" period but ramp the limit down to zero thereafter. This might be the best of all worlds for those of us who don't want to be probed but want to be able to reboot gracefully -- which is what the protocol designers had in mind. --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.20000121195112.0196a220>