DEV Community

Cover image for Let's Destroy a Linux System
Ethan Rodrigo
Ethan Rodrigo

Posted on • Originally published at ethanrodrigo.hashnode.dev

Let's Destroy a Linux System

Linux is a powerful and flexible operating system, but with great power comes great responsibility. As a Linux user, it's important to understand the potential dangers of certain commands and how to use them safely. In this blog post, we'll take a closer look at some of the most destructive commands in Linux and how to use them safely.

So let's dive in and learn how to protect yourself and your system from the destructive power of Linux commands.

1. rm

The rm command is used to delete files and directories(to find out other ways of deleting files in Linux, see this article), but it can be harmful if not used properly. By default, it does not prompt for confirmation before deleting, which means it's possible to accidentally delete important files or entire directories without realizing it.

rm can be even more hazardous when used with the -r and -f flags, which stand for recursive deletion and forceful deletion. These flags are mostly used for the deletion of a directory.

The most dangerous variation of the rm is sudo rm -rf / --no-preserve-root. This command says "Delete everything in the / directory and do not treat it as a special directory."

image.png

Preventing accidental file deletion

  1. Use of the -i and -I flags: You can use -i to prompt before every removal and -I for prompt whether to proceed with the entire operation, before removing more than three files or when removing recursively.

  2. Use a Trash: Try out trash-cli and prevent accidental file deletions.

  3. Use a recovery tool: This article talks more about how to recover deleted files in Linux.

2. :(){:|:&};:

Looks like some emoticons, right? But these are dangerous. These symbols are called a fork bomb in Linux.

According to the Wikipedia;

In computing, a fork bomb (also called rabbit virus or wabbit) is a denial-of-service attack wherein a process continually replicates itself to deplete available system resources, slowing down or crashing the system due to resource starvation

In a nutshell, the above command creates a chain of processes.

If you're a programmer or student who is learning to program you may be familiar with recursion. This command utilizes the destructive power of recursive functions.

As the above command is a function, here is the breakdown version of it.

bomb(){ # creates a function
    bomb | bomb & # calling recursively and pipe its result to the background job of itself
}; 
bomb # calling of the function
Enter fullscreen mode Exit fullscreen mode

As you can see. this is a function that calls itself (a recursive function). In the function, the function calls itself and the pipe its result to a background job of itself.

How to prevent a fork bomb?

Well, don't run that command. That's it.

And do the following also,

  1. Limit the maximum number of processes per user: The ulimit command can be used to limit the number of processes that can be created by a user and prevent a fork bomb. Give a number to the -u flag and that will be the new limit.

  2. Limit the maximum number of open file descriptors per process: The ulimit command can also be used here. ulimit -n [number], sets a hard limit of [number] file descriptors per process. For example, consider the following. It will restrict a process from opening more than 100 file descriptors at a time. Once a process reaches the limit of 100 file descriptors, the system will not allow it to open any new file descriptors.

  3. Monitor system resources usage: This can be done by using a tool top, ps, htop or bpytop. These tools let you introspect the processes running on a Linux system and the resources they're consuming.

3. dd

The dd command in Linux is used to copy and convert files. Yet, it can also be deadly if not used correctly. The command is a very low-level command that operates on a device level, meaning that it doesn't care about file systems, partitions or any other abstraction layer, it will just write to the device whatever is given to it as input.

For instance, if you use /dev/random,/dev/urandom or /dev/zero as a value for if parameter and provide a hard drive as the value for of, the command will wipe all the data on that hard drive. (It's best to try this out in a virtual machine as a safe experiment.)

This makes it particularly dangerous because if the wrong device is specified, it can cause irreparable damage to the system, including the loss of important data.

Another reason why dd is dangerous is, if you specify only the input and output stream, the command will use up the available space on the system, eventually making the system out of storage.

Safe usage of dd command

  1. Always double-check what you're writing: Make sure that the input and output files are correct.

  2. Use of bs and count options: The bs and count options allow you to specify the block size and the number of blocks to be copied. By using smaller block sizes and fewer blocks, you can reduce the risk of overwriting important data. For example, here dd creates a file of 100MB with some random data.

  3. Use status option: By using the status=progress option, you can see what's going on when you run a certain dd command.

4. /dev/null

/dev/null is a special file that discards any data written to it. It's often referred to as the null device or the bit bucket. This is not a physical device, but a virtual file located in the /dev directory. It acts as a placeholder for unwanted input or output.

In this example, I'm finding a file named 2022-12-03. However, as the command looks into the root(/) directory, there are several Permission denied errors.

And sometimes, it's not going to fix even if we use sudo .

To eliminate these errors, we can redirect them to the /dev/null device.

But, What makes /dev/null potentially so harmful? Well, it's the redirection. If you redirect the output of an important command, such as getting an API key, to /dev/null, it would be lost forever.

5. chmod

The chmod command in Linux is used to change the permissions on files and directories.

One way chmod can be destructive is by inadvertently removing the execute permission from a file that is required to run the system can cause issues. A shell script needs permission to be executed, and if that permission is removed from a script used during booting, the system can be halted. Similarly, adding executable permissions to an unknown file can also be malicious.

In the following example, we have a bash script named, hello.sh. It shows how to add and remove the executable permissions of a file.

Another way chmod can be destructive is, by granting too much access to a file or directory. This could allow malicious users or programs to access sensitive information or perform harmful actions.

For example, consider the following screenshot that shows the permissions of a file. It has granted read permission to everyone, and write permission only to the user.

But if we give read, write, and execute permissions to everyone, that would be a major security vulnerability.

Therefore chmod 777 can be considered one of the most destructive commands in Linux.

Preventing data loss with chmod

  1. _Be careful with wildcard characters (\_, ?, etc.):* You can use wildcards with chmod command, as it can match multiple files and unintentionally change their permissions. However, let's say you run this command for changing the files in a dir called Dir0.

     chmod 755 Dir0/*
    

    This looks fine until you realize you have given the same permission for the files and subdirectories as well.

  2. Check the permission before changing: Check the current permissions of the file or directory using the "ls -l" command to avoid changing them in a way that can cause problems.

  3. Be careful with -R flag: This allows you to change the permissions of a file or directory recursively, which means all the files and directories inside it will also have their permissions changed.

A bonus tip for preventing data loss

Well, this is an advice for the system admins, HAVE REGULAR BACKUPS. And also make sure to verify the backups.

🔰RB ASHISH (rbashish) ☁️ on Twitter: "Where is your backup? #Cloud #Linux  #webdeveloper https://t.co/xUStqx2gLq" / Twitter

Conclusion

Thank you for reading! If you haven't subscribed to the newsletter, DO IT IMMEDIATELY! Then you would find my latest article in your inbox. If you find this interesting, let's connect on LinkedIn, Twitter, Instagram, dev.to and Hashnode.

Now go and execute sudo rm -rf / --no-preserve-root and make tux happy. Until next time...

Top comments (0)