From owner-freebsd-questions Wed May 16 15:15:35 2001 Delivered-To: freebsd-questions@freebsd.org Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53]) by hub.freebsd.org (Postfix) with ESMTP id E1FAC37B422 for ; Wed, 16 May 2001 15:15:31 -0700 (PDT) (envelope-from boshea@netapp.com) Received: from frejya.corp.netapp.com (frejya.corp.netapp.com [10.10.20.91]) by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f4GMEiK22883; Wed, 16 May 2001 15:14:44 -0700 (PDT) Received: from shaolin.hq.netapp.com (localhost [127.0.0.1]) by frejya.corp.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f4GMEfK02805; Wed, 16 May 2001 15:14:43 -0700 (PDT) Received: (from boshea@localhost) by shaolin.hq.netapp.com (8.9.3/8.9.3) id PAA08764; Wed, 16 May 2001 15:23:00 -0700 (PDT) (envelope-from boshea) Date: Wed, 16 May 2001 15:23:00 -0700 From: "Brian O'Shea" To: Mike Meyer Cc: boshea@ricochet.net, john@office.naver.co.id, questions@FreeBSD.ORG Subject: Re: My network is dead because of this program :( Message-ID: <20010516152300.C62767@shaolin.hq.netapp.com> Reply-To: boshea@ricochet.net Mail-Followup-To: Brian O'Shea , Mike Meyer , john@office.naver.co.id, questions@FreeBSD.ORG References: <120199664@toto.iv> <15106.59157.606928.512401@guru.mired.org> <20010516150231.B62767@shaolin.hq.netapp.com> <15106.63705.646786.525612@guru.mired.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <15106.63705.646786.525612@guru.mired.org>; from mwm@mired.org on Wed, May 16, 2001 at 05:02:01PM -0500 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, May 16, 2001 at 05:02:01PM -0500, Mike Meyer wrote: > Brian O'Shea types: > > On Wed, May 16, 2001 at 03:46:13PM -0500, Mike Meyer wrote: > > > Brian O'Shea types: > > > > --3uo+9/B/ebqu+fSQ > > > > Content-Type: text/plain; charset=us-ascii > > > > Content-Disposition: inline > > > > > > > > On Tue, May 15, 2001 at 10:44:32PM -0400, Matthew Emmerton wrote: > > > > [...] > > > > > > After going to single user mode, cause I can't kill the offending > > > > > > program once it is running in multiuser mode (even kill -9 won't > > > > > > work ... > > > > > > > > Probably because the program is forking and you can't kill it's children > > > > fast enough. > > > > > > In which case, setting maxproc for that user in login.conf would cut > > > the thing off at the kneeds. 0 seems like a good number for this user > > > :-). > > > > Not necessarily. A program that does the following is very hard to > > kill: > > > > while (1) { > > fork(); > > } > > > > Set maxusers to 10 in login.conf and try this on a test system, if you > > have one lying around. > > I didn't suggest setting maxUSERs, I suggested setting maxPROC. Your > example program will get 9 processes, then the forks will start > failing. Doh! I meant maxproc (I made that mistake when I was testing this too; there is no maxusers field in login.conf). Sorry about the confusion. I tested this and while it did significantly reduce the impact, kill -9 -1 didn't stop them. The point I was making is that even if you have just 9 processes, they are still all consuming a lot of CPU and making system calls. -brian > > > Every child is also a parent. If fork() fails in one iteration of the > > loop, as soon as there is a free process table entry (or as soon as the > > number of processes drops below the user's limit), the next fork() might > > succeed, creating yet another potential parent process. You can cap the > > number of processes that the user can create, but then you're in a race > > to kill all of them fast enough to prevent just one from forking. You > > only need to lose that race once for it to start all over again. Even > > if you limit the user to 10 processes so the fork() calls fail, you > > still have 10 processes calling fork() in a loop. This is expensive > > even if all the fork() calls fail. > > Yup. Then again, you can't stop a user from creating a CPU loop if > they can log in. They can even do it with only one process. You can > alleviate the damage somewhat by setting priority in /etc/login.conf > to 10 or so. > > The only way to stop a malicious user from executing a DoS attack is > to deny them access to the services in the first place. Once you allow > them access to any services, they can start consuming them to the > limit allowed by the OS. All you can do is lower the limit so that > they can't get enough resources to do any damage. This may mean > preventing them from doing useful work, as illustrated by the extreme > case of denying them access to the machine at all. > > > Also note that login.conf settings only take effect at the time the user > > logs in. If you change the setting for a user's login class, all > > processes owned by that user will have the limits that existed at the > > time the user logged in. > > True. You can forcibly log them out, though. > > -- > Mike Meyer http://www.mired.org/home/mwm/ > Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message -- Brian O'Shea To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message