israel.garcia@cimex.com.cu wrote:

Hi again, I was reading from the net http://www.kriptopolis.org/node/4067 about a forkbomb and ran it from a root console in a non-critical machine running CentOS4.4 and the serevr goes down... the command I ran was :(){ :|:& };:

Please, does anyone knows how to aboid this on CentOS?

don't allow malicious users to have root access. in fact, don't allow malicious users to have ANY shell access to your servers.

I quicker way to take down a machine is this:

# dd if=/dev/random of=/dev/port bs=1M count=2

Should take a little less than a second to kernel panic your machine.

As Jim mentioned, have a look at limits.conf to help fix your fork bomb problem...just don't set it too low!!

(if someone has root access, they have *several* ways to take down your machine, including 'reboot', and 'shutdown'...)

Cheers, Mike

-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of israel.garcia@cimex.com.cu Sent: April 24, 2007 3:26 PM To: centos@centos.org Subject: [CentOS] Regarding fork bomb in a CentOS 4.4 Server!

Hi again, I was reading from the net http://www.kriptopolis.org/node/4067 about a forkbomb and ran it from a root console in a non-critical machine running CentOS4.4 and the serevr goes down... the command I ran was :(){ :|:& };:

Please, does anyone knows how to aboid this on CentOS?

regards, Israel

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

On Apr 24, 2007, at 12:25 PM, israel.garcia@cimex.com.cu wrote:

Hi again, I was reading from the net http://www.kriptopolis.org/node/4067 about a forkbomb and ran it from a root console in a non-critical machine running CentOS4.4 and the serevr goes down... the command I ran was :(){ :|:& };:

Please, does anyone knows how to aboid this on CentOS?

Easy: don't forkbomb your own system as root.

First, understand that it didn't "go down". The system was working as designed. There's a limit to the number of processes that can be running, and you exhausted it. No new processes could start, so you couldn't log in again, or even use any functionality not built into the shell (ps, etc). Besides that, the load was quite high from many processes trying to fork as fast as they possibly could (even though all those fork() calls were failing with EAGAIN), so the system was slow.

Since you were sitting at the shell that caused the problem, you could have hit ctrl-Z to suspend the first forkbomb subshell, then "kill -9 0" (a bash builtin) to kill the entire process group, and it would recover. Likewise if you happened to know the pid of the process group leader, "kill -9 -PID" would work. Or if you have a root shell running with a lot of builtin utilities (like BusyBox), you could use those to find the offending process group. Otherwise, you're screwed.

It's possible to prevent unprivileged users from hogging all of the system resources (processes running, RAM, whatever) through the ulimit facility. But Linux (unlike other Unix systems) does not honor root's process limit. [1] Even if it did apply, hitting that artificially lower limit would still mean you couldn't fork() as root, so killing root processes would still be tricky - probably impossible without setup work.

So basically, you can prevent unprivileged users from doing this but not root. That matches the Unix philosophy - root's supposed to know what he's doing:

"UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things." – Doug Gwyn

Cheers, Scott

[1] - <http://groups.google.com/group/mlist.linux.kernel/ browse_thread/thread/f771d3d01478babb>. More precisely, it's controlled by capability bits. In general, root has those bits set and other users don't.