Home » Uncategorized

Deadly Commands You Should Never Run on Linux

You might have read the story of a man  who accidentally ‘deleted his entire company’ with one line of bad code. If not, you can read it here. By accidentally telling his computer to delete everything in his servers, hosting provider Marco Marsala has seemingly removed all trace of his company and the websites that he looks after for his customers.

2808311749

Here are some of these Linux commands that can create big problems:

  • rm -rf / – Deletes everything!
  • Disguised rm –rf /
  • :(){ :|: & };: – Fork bomb
  • mkfs.ext4 /dev/sda1 – Formats a hard drive
  • command > /dev/sda – Writes directly to a hard drive
  • dd if=/dev/random of=/dev/sda – Writes junk onto a hard drive
  • mv ~ /dev/null – Moves your home directory to a black hole
  • wget http://example.com/something -O – | sh – Downloads and runs a script
  • . > file — Flush the content of file
  • ^foo^bar — Edit the previous run command without the need of retyping the whole command again
  • dd if=/dev/random of=/dev/sda — Wipe out the block sda and write random junk data to the block
  • Hidden the Command
  • !543 — Say you wanted to execute command 573 again from your history, but with a typo it became 543, which erases the file you are working on

For details about these commands, click here and also here. Though not a Linux command, I would add hash tables that have grown out of control (and start doing massive amounts of memory paging), forcing me to shut down the computer and restart in a very messy environment, as a result.

It is always good to keep a copy of all your important files, including email, outside your Internet network, possibly in the cloud, and with a mirror copy in case your cloud provider disappears. And do not accidentally delete or compromise your cloud copy, for instance by overwriting a good version of a file, with one that was recently infected or emptied. It is also good to be able to restore your systems to a previous state, precisely to be able to face this kind of scenario. Also, it is a good idea to add a time stamp to all your files.

Last but not least, have your critical passwords stored in some safe place, even on paper. The last time my computer died, I was not worried, knowing that I would recover everything from the cloud, and knowing that computers – just like people – die (mine was old and I was prepared for that; I was even happy to have survived my laptop, rather than the other way around.) However, the password to access my cloud was stored… on my dead computer! You want to avoid that. In my case, I was able to recover it from another location, on a Yahoo email account, though that account is dead too now, following the big Yahoo hack, meaning that today, it would have required more efforts to retrieve access to my cloud.

Interestingly I brought the dead laptop to a computer repair guy. He eventually resuscitated it, and it is still alive and well two years later (if you see typos in my articles, especially missing letters such as “q”, bear with me, this is because of the very old age of my keyboard; I promise I will soon get a new one.)

Top DSC Resources

Follow us on Twitter: @DataScienceCtrl | @AnalyticBridge