Date: Fri, 21 Jan 2000 14:23:47 -0700 From: Brett Glass <brett@lariat.org> To: Gene Harris <zeus@tetronsoftware.com> Cc: freebsd-security@freebsd.org Subject: Re: Some observations on stream.c and streamnt.c Message-ID: <4.2.2.20000121141918.01a54ef0@localhost> In-Reply-To: <Pine.BSF.4.10.10001211419010.3943-100000@tetron02.tetronso ftware.com> References: <4.2.2.20000120194543.019a8d50@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
At 02:18 PM 1/21/2000 , Gene Harris wrote: >After eight hours of testing, in which I have been >bombarding the NT 4.0 SP6a Server, the CPU usage on an >unloaded machine jumped to 27%. However, when I started up >Oracle 8.05 and ran a rather lengthy query against a 400MB >database, no distinguishable differences exist in the query >time between a machine under attack and one not under >attack. A poor test, IMHO. It's disk-intensive and CPU-intensive, but not network-intensive. Also, other conditions can affect the results. Were the machines on a network with a live gateway router? Remember, traffic to, from, and through the router is significant, since one of the effects of the exploit is to cause a storm of packets on the local LAN. I've made an NT/IIS server virtually inaccessible using the same exploit. >In the case of Windows 95/98, several more complex >interactions occured, and my FreeBSD machine began to post >jess: No more buffer errors. I tested the Win98/95 machines >against read/writes against the IDE and reads against the >DVD subsystems and no apparent performance loss was noticed >when the machines were under attack. (I used the movie "Gone >With the Wind" as a test on the DVD drive.) Again, a bad test -- I/O and CPU intensive, but not network- intensive. The same seems to be true of the Linux and BSD tests you describe. --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.20000121141918.01a54ef0>