Secure wipe (scrub) filesystem of VPS from VPS itself

Question

I have a VPS I'm planning to delete. This particular cloud provider makes no guarantee that the data on the drive will be wiped before giving the disk to the next person. What's a best effort attempt I can make to secure-wipe sensitive data (whether existing as files or as deleted data) on the drive?

• Assume the provider does not offer a separate, bootable OS to perform maintenance from
• If not every last bit of sensitive data can be guaranteed to be wiped, that's ok
  • (I would have encrypted the data, if it were that critically sensitive!)

Answer 1

Use the scrub command¹ on the user data portions² of the VPS filesystem.

BEWARE: The following commands purposely destroy data.

Here is a list of ideas for scrubbing targets, in a sensible order, but you may need to vary it for your particular VPS configuration:

• Databases, typically stored under /var. For instance, if you're using MySQL, you'd want to say something like this:

  # service stop mysql       # command varies by OS, substitute as necessary
  # find /var/lib/mysql -type f -exec scrub {} \;
  

• /usr/local should only contain software you added to the system outside the normal OS package system. Nuke it all:

  # find /usr/local -type f -exec scrub {} \;
  

• The web root. For most Linux web servers on bare VPSes running Apache, this is a pretty good guess:

  # service stop apache      # ditto caveat above
  # find /var/www -type f -exec scrub {} \;
  

  If you're on a managed VPS with a nice control panel front end which lets you set up virtual hosting, or you're on shared hosting, chances are that your web root lives somewhere else. You'll need to find it and use that instead of /var/www.

• Email. Be sure to catch both the MTA's spooling directories as well as the individual users' mailbox files and directories.

• Any configuration files with potentially sensitive data in them. I can't rightly think of anything in this category, since configuration data is generally fairly boring. One way to attack it would be to say

  # ls -ltr /etc | tail -30
  

  That will give you the 30 files you most recently touched in /etc, which will give you a list of files most likely touched by you, rather than containing stock configuration information.

  Be careful! There are files you can scrub in /etc that will prevent you from being able to log back in. You might want to put off scrubbing those until later in the process.

• Password files, keys, etc. This list varies considerably between systems, but here are some places to start looking:

  /etc/shadow
  /etc/pki/*
  /etc/ssh/*key*
  /etc/ssl/{certs,private}/*
  ~/.ssh                        # for each user
  

  At this point, you probably cannot log back in again, so be sure not to drop your SSH connection to the VPS.

• Erase the free space on every mounted filesystem that may contain user data:

  For each user data filesystem² mount point MOUNTPT:

  # mkdir MOUNTPT/scrub
  # scrub -X MOUNTPT/scrub
  

  For instance, if /home is on its own filesystem, you'd create a /home/scrub directory and scrub -X that. You have to do this for each filesystem separately. This fills that filesystem with pseudorandom noise.

  If there is user data on the root filesystem, don't do that one yet, since filling the root filesystem may crash the system.

• Burn the world. If the OS hasn't crashed by this point, your shell hasn't dropped your session, etc., you can do a best-effort attempt to burn the world:

  # find /var /home /etc -type f -exec scrub {} \;
  

  Unix being the way it is about file locking, you still might not lose your connection to the VPS while this command executes, even though it is overwriting files you need to log in. You may nevertheless be unable to execute any more commands once it does finish. This is definitely a "saw off the tree limb you are sitting on" kind of command.

  If by some thin chance you are still logged in after this completes, you can now erase the free space on the root filesystem:

  # mkdir /scrub
  # scrub -X /scrub
  

• Nuke the VPS. Finally, log into your VPS control panel and tell it to reinstall your VPS with a different OS. Pick the biggest and most featureful one your VPS provider offers. This will overwrite part of your VPS's disk with fresh, uninteresting data. There's a chance it will overwrite something sensitive that your prior steps missed.

In all the scrub(1) commands above, I haven't given any special options, since the defaults are reasonable. If you are feeling especially paranoid, there are methods in scrub to use more passes, different data overwriting patterns, etc.

Scrub uses data overwriting techniques that require truly heroic measures to overcome. It's a question of incentives: how much work is someone willing to put in to recover your data? That tells you how paranoid you should be about following the steps above, and adding additional steps.

Due to the nature of virtual machines, there may be "echoes" of your user data in the host system due to VPS migrations and such, but those echoes are inaccessible to outsiders. If you cared about such things, you shouldn't have chosen to use a VPS provider in the first place.

If you added other directories to the standard list² of user data trees, you should probably scrub those early on, since the order of scrubbing is from most-user-centric to least.

You do the least user centric parts last, since they tend to be parts of the filesystem that affect the system's own functioning. You don't want to lock yourself out of the VPS before you're done scrubbing.

---

1. Scrub is highly portable, and is probably in your OS's package repo already, but if you have to build it from source it's not hard.

2. Typically, the trees containing user data are /home, /usr/local, /var, and /etc, in decreasing "density" of user data vs system default data. You may need to add other directories to this list due to your system administration style or VPS management software preferences.

   We aren't going to bother scrubbing places like /usr/bin and /lib, as these should only contain copies of files that are widely available, and thus boring. (The OS, software you've installed from public sources, etc.)

Answer 2

First, remove any file that contains private data. That means files in /home, in /srv, anything in /etc that you've customized, logs in /var/log, mail in /var/mail, typically many other things under /var, etc. Only keep some minimum network configuration, in particular SSH keys if needed (you may want to create throwaway SSH keys for the duration of the wipe, and remove the others).

Overwrite and unmount all partitions other than the root, e.g.

# you shouldn't have any open file on non-root partitions at this point
umount /srv
</dev/zero cat >/dev/sda2

Now fill in the empty space:

</dev/zero cat >/zero
rm /zero

At that point, most of your data is gone. With some filesystems, there may be some data left over in the last block of each file (e.g. on a filesystem with 1kB blocks, if a file is 2000 bytes long, then there are 48 unused bytes at the end); on ext4, I think this unused space is always zeroed.

For a final this-is-goodbye pass, terminate as many services as you can, then overwrite the root partition, e.g.

</dev/zero cat >/dev/sda1

Your system won't boot back.

Don't bother with overwriting with multiple random passes instead of zeroes: this advice is based on 1990s disk technologies and no longer relevant; today, zeroing is just as effective, and even then, recovering zeroed data required expensive equipment and quite a bit of luck. See Overwriting a Disk and follow the links for more details.