Date: Fri, 21 Jan 2000 17:15:57 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: "Bob Madden" <bobm@atgsystems.com> Cc: "FreeBSD-Security" <freebsd-security@FreeBSD.ORG> Subject: Re: Some observations on stream.c and streamnt.c Message-ID: <200001220115.RAA65781@apollo.backplane.com> References: <038801bf645c$ed6d5f00$01000000@madman>
next in thread | previous in thread | raw e-mail | index | archive | help
: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
<dillon@backplane.com>
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?200001220115.RAA65781>