Date: Fri, 21 Jan 2000 21:26:39 -0700 From: Brett Glass <brett@lariat.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Dag-Erling Smorgrav <des@flood.ping.uio.no>, 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.20000121210443.01981600@localhost> In-Reply-To: <200001220353.TAA66856@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> <4.2.2.20000121195112.0196a220@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
At 08:53 PM 1/21/2000 , Matthew Dillon wrote: > Brett, it's an interesting rationalization, but it's completely wrong. > If you think a moment you will find that there are plenty of RST situations > long after boot. Think of all those dialup connections where people > turn off their modems before disconnecting, for example. At BEST our > servers always had a large number of hanging connections from that > sort of situation. This is really a different situation. In this case, the system is acting like a router. The packet never gets to the TCP level on the host, or shouldn't, during the call. When the user hangs up, your PPP software might want to send a bunch of RSTs to shut down the caller's sessions (if it's been tracking them). Or just do what a router does, and flag the machine as down. > Now what happens when someone new gets that dynamic > dialup IP and connects back to the same server using the same port pair? > There are ftp port-pairs, there is the tendancy for machines to reuse > port numbers, there are all sorts of problems that RST helps with. This is the equivalent of a new host coming up at that IP. Again, RSTs are useful at the outset but not necessarily later. > Believe me, RST's are useful. Rationalizing them away just isn't > going to work. You will wind up with some convoluted set of rules and > conditions when all you had to do in the first place was turn on > ICMP_BANDLIM. ICMP_BANDLIM isn't a very good fix for this exploit -- it merely limits some of the secondary effects. Limiting or killing RSTs is much more effective. I think we've reached a general consensus that bandwidth limiting of RSTs is a good idea; after that, it's just a matter of degree (with zero being just one of those degrees). And whether we want that limit to change over time. (As I mentioned, my personal strategy would be to crank it down.) > As far as port probing goes: So what? Do you think preventing people > from identifying your machine will make it more secure? No, but it'll make it harder to figure out which 'sploits to try. It's the difference between leaving the door visibly wide open and forcing the cracker to TRY the door. If I can waste a cracker's time, I want to. It seems to me that a rate-limiting feature that had an an initial and final limit, with a ramp starting when the host or interface was brought up, would let you have your way and other people have theirs. They could set either or both to be zero if they wanted, but you would set neither to zero. Voila! Everyone's happy. --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.20000121210443.01981600>