Date: Wed, 16 May 2001 17:02:01 -0500 From: Mike Meyer <mwm@mired.org> To: boshea@ricochet.net Cc: Mike Meyer <mwm@mired.org>, john@office.naver.co.id, questions@freebsd.org Subject: Re: My network is dead because of this program :( Message-ID: <15106.63705.646786.525612@guru.mired.org> In-Reply-To: <20010516150231.B62767@shaolin.hq.netapp.com> References: <120199664@toto.iv> <15106.59157.606928.512401@guru.mired.org> <20010516150231.B62767@shaolin.hq.netapp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15106.63705.646786.525612>