From owner-freebsd-security Sun Jan 23 11:40:14 2000 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id D1D7214E7D for ; Sun, 23 Jan 2000 11:40:07 -0800 (PST) (envelope-from brett@lariat.org) Received: from workhorse (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id MAA15588; Sun, 23 Jan 2000 12:39:47 -0700 (MST) Message-Id: <4.2.2.20000123122732.01ace310@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sun, 23 Jan 2000 12:39:46 -0700 To: Jason Young , Matthew Dillon , Dag-Erling Smorgrav From: Brett Glass Subject: RE: Some observations on stream.c and streamnt.c Cc: Keith Stevenson , freebsd-security@FreeBSD.ORG In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 11:33 PM 1/22/2000 , Jason Young wrote: > > In fact, > > using ipfw or ipfilter to impose policy (only the latter can be used > > in case of the stream.c exploit) is redundant, since ipfilter must > > retain tables of connections which duplicate information stored by > > the protocol stack already. > >Both ipfilter and the kernel correctly drop the packet. There's a difference, though. ipfilter doesn't send RSTs, which in turn cause congestion and additional system loading due to ICMP messages. The kernel normally does send RSTs. That's what this discussion is about: how to make the kernel enforce the policy rather than ipfilter, which eats memory and CPU because it maintains redundant tables. >The fact that >ipfilter is being successfully used to defend against it simply means that >it's more efficient at dropping these particular rogue packets. IPFilter seems like a nice piece of work, but it's still not efficient to use if if the kernel can do the right thing. >It's my >understanding from the list that the main reason the kernel is bogged down >by this attack is that it is computationally expensive to generate all the >return RSTs required by protocol. Partially, but not entirely true. ICMP imposes an additional burden. >Matt Dillon's rate-limiting patch is a form of hardening the TCP/IP stack >while maintaining all possible protocol compliance. I agree with this. In >the usual case you should stick to protocol, and in a failure or overload or >attack situation you should do your best. Unless you're concerned about scans. Which can be done as a very, very slow attack if you are scanning a wide range of addresses ("slow scanning"). >Personally, I don't understand why people are so antsy about being >portscanned or having their OS identified. Yes, it's more information for an >attacker. But if you have a security hole, you have a security hole. This is >exploitable if the intruder knows you're running XYZ unrelated service or >no. This argument is akin to the one which says, "Why are you concerned about privacy? If you have nothing to hide, you have nothing to worry about." >People seem to be regarding the fact that you can scan a machine for its >open ports to be a fault in its TCP/IP stack. In fact, it is doing what it's >supposed to do. If you don't like what it's doing, then that comes back to >imposing local policy. Exactly. And the kernel has always has options that let the administrator impose local policies, such as quotas, etc. This is another one. Let's give him an efficient choice. >Any client/server interaction that has pending activity after the reboot >will be in some varying stage of exponential backoff or have timed out >depending on when the activity took place and how long the server took to >"come back". 5000 connections will certainly not result in 5000 packets in >one second worth of RST-able client traffic. Many of the clients will not >have pending activity. Actually, I already stand corrected on this. It's not as devastating as I first painted it in the case of an FTP server. But a server that's streaming RealAudio, for example, is likely to take a much bigger hit. I maintain one for a radio station, and a packet monitor shows a whole lot of wild stuff going on. RealAudio and RealVideo even encapsulate themselves in HTTP to get through firewalls! It's ugly. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message