Date: Wed, 16 May 2001 15:23:00 -0700 From: "Brian O'Shea" <boshea@ricochet.net> To: Mike Meyer <mwm@mired.org> 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> In-Reply-To: <15106.63705.646786.525612@guru.mired.org>; from mwm@mired.org on Wed, May 16, 2001 at 05:02:01PM -0500 References: <120199664@toto.iv> <15106.59157.606928.512401@guru.mired.org> <20010516150231.B62767@shaolin.hq.netapp.com> <15106.63705.646786.525612@guru.mired.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, May 16, 2001 at 05:02:01PM -0500, Mike Meyer wrote:
> Brian O'Shea <boshea@ricochet.net> types:
> > On Wed, May 16, 2001 at 03:46:13PM -0500, Mike Meyer wrote:
> > > Brian O'Shea <boshea@ricochet.net> 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
> --
> Mike Meyer <mwm@mired.org> 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
<boshea@ricochet.net>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010516152300.C62767>