Hello guys! In this video, I'll show you a very interesting attack of type Denial-of-service called 1
Fork Bomb or Rabbit Virus. Pay special attention to it because it can be executed by a non-privileged 2
user and can bring down and make unusable the entire Linux system. 3
I can honestly say that it was a very unpleasant surprise for me to test it on the many Linux distributions 4
and see that it works on all of them. 5
In a matter of seconds and with only one line of code, a normal user will hack the system. 6
Let's get started and see the attack live, but please don't test it on a production system because 7
it will make it unusable. Run it in a VM or on a test system 8
to which you have physical access. 9
Be prepared for a crash and a force reboot of your system. On the latest version of Ubuntu as a non-privileged 10
user, 11
and this is the key here, 12
I'm creating a new Bash script. 13
And inside the script, I'm adding a single line of code: $0 && $0 & 14
And that's all. 15
Don't worry, I'll explain it to you in detail later. 16
Now I'm saving the file, setting the execution permission and running the script as usual. 17
In a few seconds, the system will become unusable, I cannot even move the mouse anymore, and there 18
is no chance to stop it. 19
I try to run the ls command, but it doesn't work. 20
The system has crashed; the script has caused resource starvation, crashing the system. The only 21
way to get out of this is force reboot the system using the power of or reboot button. 22
I'm stopping the VM and then starting it again so I can regain access. 23
I'm pausing the recording until it starts so I can log in. 24
The system has restarted. 25
Let's take a deeper look at the script and what has happened. 26
This is the script. 27
It performs a denial of service attack that makes use of the fork system call to create an infinite 28
number of processes. 29
So $0 is a special variable that represents the script itself, so the script is running itself recursively 30
two times and the is going in the background for another recursive call. 31
It does this indefinitely. 32
& (Ampersand) at the end puts the process in the background so new child processes cannot die at all and 33
start eating the system resources. 34
Let's see how to prevent such a fork bump! 35
If you run ulimit -u, you will see the number of available processes for the current user. 36
This value is very large. 37
You can also run ulimit -a to see a lot of limits available to the shell and the processes it creates. 38
To prevent the fork 39
bomb we'll lower the number of processes the user can start. 40
The processes cannot continuously replicate themselves: as root I'm opening the following file: 41
/etc/security/limits.conf 42
And at the end, I'm adding the following line, the name of the user, student, hard nproc and 43
the value, for example, 2000; this will limit the user processes to 2000. 44
Please, don't set too low the ulimit numbers! 45
By doing so, you will prevent the user from working on the system. 46
And you can also add such a limit for a group as follows: @ the name of the group, for example, admins 47
hard nproc and the value, for example, 4000. I'm saving the file; the new limits will 48
be available for new sessions, so I'm logging out and then logging in again. 49
I'm opening a shell and running the script again. 50
We see that the system is not becoming unavailable and we can work on it. See this message, which 51
practically means that the shell is not allowed to create the new processes. 52
But the system is not unusable. 53
I can work on it. 54
Congratulations, you've just mitigated the fork bomb attack on Linux and made your system more secure!