WARNING: The “fork bomb” is nothing new but still leads to a denial of service on poorly or unprotected systems. Do not take the risk of testing this kind of “toys” on a server in production.
The principle of a “fork bomb” (or “fork bomb”) is to multiply a process to reach the limits of the system. The multiplication of processes saturates the system and quickly consumes all available resources.
The processes in progress then no longer have sufficient resources to function properly and the new processes must wait for resources to become available to start. The set leads to a system freeze and / or denial of service (DoS).
The most common form of the bash bomb fork is:
: ( ) { : | : & } ;:
This form, cryptic, is more or less intended to hide the effects of this ridiculous recursive function.
In a more explicit form, we could write:
1: ( ) {
2 : | : &
3 } ;
4:
line 1: creation of a function named “:” taking no argument “()”
line 2: body of the function. It is called (first “:”) is its return is sent (the pipe “|”) to another occurrence of itself (second “:”) . “&” Puts the function call in the background so so child cannot die at all and start eating system resources.
line 3: end of the function “}; ;
line 4: Recursively launch of the bomb (call the “:” function).
As you can see, this feature does not actually do much but is amazingly effective.The original function can be found under different aspects such as its octal, hexadecimal, etc.
How to protect your system?
One simple way to protect your system is to set limits on the number of processes that users can instantiate, “max user processes” , via the ” ulimit ” function.The maximum number of processes of a user can be queried directly via the “-u” option of “ulimit”:
[training@beingexplorer ~]$ ulimit -u
1024
Default limit on RHEL 6 is 1024 for root and non-root users.This value can be greatly reduced to protect the system:
[training@beingexplorer ~]$ ulimit -u 100
[training@beingexplorer ~]$ ulimit -u
100
The attack is then quickly blocked (no more than 100 user-instantiated processes) and the system retains enough resources to service the services it hosts.See System Resource Check (ulimit) for more information on the tool.
Apply the limit to all users
The restriction of the maximum number of processes instantiated by the users can be set up, via the file “/etc/security/limits.conf” :
[training@beingexplorer ~]$ cat /etc/security/limits.conf
...
@users soft nproc 100
@users hard nproc 200
training hard nproc 300
See System Resource Control (ulimit) for more information on the “/etc/security/limits.conf” file .Another solution to protect the system is to use cgroups (available on kernels greater than or equal to 2.6.24).