No subject

limit and being killed as a result.

> OK, let's bring out the big guns:
>
> $ ulimit -v 64000

I left mine at 524288.

> $ for i in `seq 1 8` ; do tail /dev/zero & done

zen:~$ for i in `seq 1 8` ; do tail /dev/zero & done
[9] 12673
[10] 12674
[11] 12675
[12] 12676
[13] 12677
[14] 12678
[15] 12679
[16] 12680

And later:

[9]   Killed                  tail /dev/zero
[10]   Killed                  tail /dev/zero
[11]   Killed                  tail /dev/zero
[12]   Segmentation fault      tail /dev/zero
[13]   Killed                  tail /dev/zero
[14]   Killed                  tail /dev/zero
[15]-  Killed                  tail /dev/zero
[16]+  Killed                  tail /dev/zero

> Darn... totally unresponsive, disk crunching like mad. :-(
>
> Moral of the story:  Local DoS attacks are childsplay under Linux, and

Not for me.  I can't reproduce the problem.  Box was still humming along
after these tests.

Just for fun I decided to up the ante...

zen:~$ for i in `seq 1 20` ; do tail /dev/zero & done

It eventually killed all of them to.  Oh let's go for broke...

zen:~$ for i in `seq 1 100` ; do tail /dev/zero & done

System is definately slow.  On the basis of this I'd consider lowering the
per user process limit to 64.  A user can actually get a lot done in 64
processes (checkout how many processes you're actually using at any given
time).

No sooner were the processes finished forking than they started getting
killed.  I ran a top while doing all these tests.  At no time did the
number of processes in run state exceed 55.

The tails have all been killed and the system is now fine.

> I would guess under all but the most hardened UNIXes.  Don't give someone
> you don't trust a shell account.

This is still true, in case they know of a local root exploit or DoS you
don't know about :)

> "ulimit" can help, but you'd have to set uselessly-low limits to prevent
> this kind of attack.

Mine are comfortable and seemed to have protected me well.  As a general
rule I limit a user's memory usage on a box to no more than half of the
total ram on the box.  Even though this box as 1 Gb ram I limit each
non-root user to 256Mb of physical memory.  It is surprising how little
ram a user actually needs to own on a system during normal usage.  This
box has 1Gb to get the most from disk caching.

The scheduler in 2.6 is greatly imrpoved over 2.4 (Linux's scheduler up to
2.4 hasn't been the best) so we should see improved performance while
someone is trying to DoS the box like this.

Someone has come out with a scheduler which divides time between users as
well as processes.  So if someone forks a lot of processes only they see
the slow down.  Others don't see it at all.  This is similar to an idea I
had a while back but someone actually coded a scheduler to do it :)  I
don't think this is standard in 2.6 but I'll certainly be trying it out.
This scheduler would prevent anyone else on the box actually noticing the
attempt at a DoS.

Hmm...better reenable swap...

Cheers,
	Rob

-- 
Robert Brockway B.Sc. email: robert at timetraveller.org, zzbrock at uqconnect.net
Linux counter project ID #16440 (http://counter.li.org)
"The earth is but one country and mankind its citizens" -Baha'u'llah