From owner-freebsd-security Fri Jan 21 17:16: 9 2000 Delivered-To: freebsd-security@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 112C414BCE for ; Fri, 21 Jan 2000 17:16:00 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id RAA65781; Fri, 21 Jan 2000 17:15:57 -0800 (PST) (envelope-from dillon) Date: Fri, 21 Jan 2000 17:15:57 -0800 (PST) From: Matthew Dillon Message-Id: <200001220115.RAA65781@apollo.backplane.com> To: "Bob Madden" Cc: "FreeBSD-Security" Subject: Re: Some observations on stream.c and streamnt.c References: <038801bf645c$ed6d5f00$01000000@madman> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :I believe this to be true. Realize that in a real world attack, the attack :most likely originates from more than one source AND it continues for a good :hour or so or however long it takes to crash the box. But it DOES crash the :box. My experience is with FreeBSD, but as has been suggested/demonstrated it :has similar effects on other platforms. : :Bob Madden If the attack doesn't take down your machine in the first 60 seconds then the failure condition may not be where you are looking for it. The first thing I would check would be to make sure that you are restricting the tcp connection resources. net.inet.tcp.sendspace and net.inet.tcp.recvspace should be left at their default 16384 or perhaps made smaller. See if connections are building up (netstat -tn | wc -l) during the attack. If the build up forever that may be the source of the mbuf exhaustion. Another possibility is that your machine's route table is being blown up by the spoofed packets. Each spoofed packet has a different source address which means that a temporary route table entry is being created for each one. These entries take time to timeout. Use 'vmstat -m' and check the 'routetbl' field while the attack is going on. (Wasn't there a route table leak that we fixed in -current? Was that ever backported to -stable?). Route table entries can be controlled somewhat with: test3:/var/mail# sysctl -a | fgrep .rt net.inet.ip.rtexpire: 3600 net.inet.ip.rtminexpire: 10 net.inet.ip.rtmaxcache: 128 Do the following: sysctl -w net.inet.ip.rtexpire=2 sysctl -w net.inet.ip.rtminexpire=2 In your case it is not the packet attack itself which is causing you to crash - your machine is able to handle that just fine if it stays up for an hour. The problem is probably some side effect of the packet attack. We have to figure out what that side effect is so it can be addressed. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message