Date: Tue, 25 Jan 2000 14:50:40 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Tim Yardley <yardley@uiuc.edu> Cc: freebsd-security@FreeBSD.ORG Subject: Re: Fwd: multicasts from hell Message-ID: <20000125145040.Z26520@fw.wintelcom.net> In-Reply-To: <4.2.0.58.20000125151430.01234f10@students.uiuc.edu>; from yardley@uiuc.edu on Tue, Jan 25, 2000 at 03:15:16PM -0600 References: <4.2.0.58.20000125151430.01234f10@students.uiuc.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
* Tim Yardley <yardley@uiuc.edu> [000125 14:04] wrote: > Thought this might interest some of you... since all the multicast talk is > going on. > > /tmy > > >Approved-By: aleph1@SECURITYFOCUS.COM > >Delivered-To: bugtraq@lists.securityfocus.com > >Delivered-To: bugtraq@securityfocus.com [message about sending tcp multicast packets snipped] The patches that Warner is about to apply ought to address this issue. About it killing routers and how we deal with forwarding such packets through our routing code probably deserves some investigation. -Alfred > >Another possibility that has been suggested as to why some machines die is > >that the 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. > > > >Route table entries can be controlled somewhat under freebsd with: > > > >[root@solid]::[~] sysctl -a | fgrep .rt > >net.inet.ip.rtexpire: 3600 > >net.inet.ip.rtminexpire: 10 > >net.inet.ip.rtmaxcache: 128 > > > >You can do the following, to help if the route table is at least part of > >the problem: > > > >sysctl -w net.inet.ip.rtexpire=2 > >sysctl -w net.inet.ip.rtminexpire=2 > > > >Things that will help: > > > >1 -- drop all multicast packets (ingress and egress) that are addressed to > >the tcp stack because multicasts are not valid for tcp > >2 -- extend bandwidth limiting to include RST's, ACK's and anything else > >that you feel could affect the stability of the machine. > >3 -- dont look for listening sockets if the packet is not a syn > > > >I hope that this helps, or explains a little more at least. 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?20000125145040.Z26520>