Delete files on Linux securely

I want to make one thing clear. You need to use multiple overwrites strategy ONLY when you’re dealing with a file, or a bunch of  files, size of which doesn’t equal capacity of the storage device. Multiple overwrites strategy is a legacy approach that made much sense back in the day, and to some extent today too, but largely it took on a size of an urban legend.

It’s true, though, that  if you want to completely destroy a single file you should rather use this multiple overwrites strategy to stay on the safe side. There are a couple of reasons for this is, one would be that, theoretically, underlying storage device logical addressing system (LBA) could remap sectors with data (think bad blocks recovered by hard drive semi-intelligent firmware known as error correction mechanism) to some other place and thus remains of the files, or sometimes even copies could be found on the drive despite the fact that the file(s) was deleted.

Keep in mind that in most cases recovering these remnants is not a trivial task, so if your adversary is your girlfriend or geek friend with mild degree in Geekinness, you may consider yourself reasonably safe when deleting files with rm. If you’re up against cyber police or underground hackers perhaps it won’t hurt to use the method described in this post down below.

Also, please note, that on SSD drives multiple overwrites strategy should really be embraced due to the technical design of this type of storage device (read more about it in stackoverflow thread).

Bottom line is, if you need to destroy all data on a drive you don’t have to overwrite it multiple times, just once will be enough but ONLY IF you’re sure you’re overwriting every single sector on the drive (think dd if=/dev/random of=/dev/sda). It won’t hurt but you really shouldn’t.

Here’s a nice starting point if you’re interested in deeper details of the discussion:

Here’s the deal, in most cases, on most popular distributions, on most standard Linux setups removing a file via GUI file manager or in your terminal window, including by rm command, isn’t secure at all. A file removed in such a fashion can be relatively easily recovered.

If you’re donating your old computer to a younger sister and don’t want to blush when she recovers your Inkscape drawings of  Pokemon characters and posts them up on Facebook, you need to know how to delete those files for good. Securely, so that not even Interpol can recover them with expensive hardware.

If you doubt how much this is serious, google “securely delete file linux” up and look at the numerous warnings written by many people all across the web — rm is not enough!

Even more, the filesystem type and its options may prevent you from successfully deleting a file for good even with shred. So, how do we do it?

shred is the command line utility that does the job. There are a few interesting command line options that are often omitted elsewhere on the various pages on the Internet.

Continue reading

How to clone a VMWare virtual machine

This is a brief example that shows how to clone a virtual machine on a running VMWare Server 2.x using UNIX box shell and  VMWare’s web-based Virtual Infrastructure Web Access GUI.

  • Login to the UNIX box that runs an instance of VMWare Server and has virtual machine data files.
  • Find the suitable virtual machine and copy it. Give the new virtual machine a distinct name.
  • Rename *.vmx and *.vmxf to reflect the name of a new virtual machine.
  • Edit *.vmx so that it points to new, renamed files.

% cd /vmachines
% sudo cp -r imap-replication.master/ imap-replication.replica3/
% cd imap-replication.replica3/
% sudo mv imap-replication.master.vmx imap-replication.replica3.vmx
% sudo mv imap-replication.master.vmxf imap-replication.replica3.vmxf
% sudo vim imap-replication.replica3.vmx

You’d have to edit only the following two lines:

displayName = "imap-replication.replica3"
extendedConfigFile = "imap-replication.replica3.vmxf"

displayName can be anything you like, but it makes sense to give it a meaningful value (one that reflects the actual virtual machine title is a good choice). extendedConfigFile should simply point to *.vmxf you’ve renamed before editing this *.vmx file.

If you’ve copied data files of a running virtual machine you might have a lock directory that you’d need to delete. You could do it like this:

% sudo rm -rf imap-replication.master.vmdk.lck/

Now go to the Web Access, the web-based Virtual Infrastructure management GUI. By default it’s available on port 8333 of your HTTP server, e.g. Login and add a new virtual machine to the repository. You’ll get to browse the folder that holds all your virtual machines, find the one you’ve prepared as suggested above, select the *.vmx file and click OK button to add the new virtual machine.

Once added it should appear in your Inventory list of virtual machines, like this:

Well, now you could go on to actually Power On this new virtual machine but let’s first check if the edits you’ve made to the configuration files on console have been recognized:

Note, that you don’t have to rename the virtual machine’s disk file(s). If there’s a need for a consistent naming of the files go ahead and rename those as you see fit, but remember that you’ll have to reflect those changes in *.vmx and possibly *.vmxf too.

Finally, you can Power On the new virtual machine. VMWare Server should detect that you’re attempting to clone this virtual machine, answer “I copied it” when asked the question pictured in the following screenshot:

In conclusion, a couple of ideas to ponder.

This technique came in really handy when I started out with setting up an IMAP site with replication capabilities. I had access to CentOS 5.5 default install virtual machine, used as a template of sorts, that I cloned like described in this post and created a new virtual machine called imapsite-replication.master as can be seen throughout the screenshots.

After I’ve installed and configured Cyrus-IMAP software on that newly cloned virtual machine I cloned it too in order to create other new imapsite-replication.replicaX virtual machines. This obviously saves a lot of time and is very easy to do. To be honest, it took me a little guess work and help from IRC folks on to get this cloning business right. I couldn’t find a detailed how-to on the Internet so I thought someone like me would like to have one. Well, there you go.