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!)
  • If your cloud partition is static then Delete your files and fill it up with large junk files, movies or pictures will do. The once is completely filled the delete everything. That will will fill up your space and wipe out all your original files. If they have Backups or mirror Partitions then i don't know what the policy is for archived Data, usually between 6 months to 6 years, but then that goes against the Data Protection Act which i will assume includes Cloud data as that is your property and you a just renting data space. – Tasos Jun 10 '14 at 17:54
  • 1
    It doesn't much change the intent of the question, but I just want to point out that the term "scrub" has an additional, very different, meaning: to read all blocks in some sort of storage and confirm that they are accurate, for example by comparing against redundant data, checksums, or by some other means. Make sure you do what you think you do. – a CVn Jun 10 '14 at 20:09
  • "The data on the drive will be wiped before giving the disk to the next person" Unless your VPN provider is an idiot, they would most likely use dynamically allocated virtual disks. This is much cheaper for them since the virtual disk would not be mapped to an actual space on the physical storage device until you write something to it, and also makes it much more difficult for other clients on the same physical machine to read your disk content as the VM would just return blanks if the virtualized OS tries to read unallocated space. – Lie Ryan Jun 10 '14 at 20:58
  • The answer given by @WarrenYoung below could help you if you want to prevent, say, an employee of the VPS host from getting to your data or from law enforcements giving subpoena to the host (or from spy agencies discretely working on things they would publicly deny). But if your VPS provider is so seedy that you are genuinely concerned with that, you should also be wary about any guarantees they claim about wiping data (which makes no sense with virtualized disks in the first place). – Lie Ryan Jun 10 '14 at 21:05
  • @LieRyan that's re-assuring. All the same, data leaking to other users is not unheard of. – Michael Kropat Jun 10 '14 at 21:19

Use the scrub command1 on the user data portions2 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:

    ~/.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 filesystem2 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 list2 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.)

  • 1
    That's an incredibly thorough guide. You took best effort to heart. – Michael Kropat Jun 10 '14 at 19:34
  • If I'm worried about sensitive data being in deleted files, would it make more sense to run scrub -X at the start, instead of waiting till I might not be able to run it any more? – Michael Kropat Jun 10 '14 at 19:35
  • 2
    @MichaelKropat: Thanks. Re: scrubbing free space, no you don't want to do that too early. Keep in mind, you are doing this as root which bypasses the system's normal protections against a single user filling the entire filesystem. When a filesystem fills up, processes start crashing as they fail to do even simple things like create temporary files. If you crash sshd, for instance, you've just locked yourself out of the VPS, with no way to get back in and finish the job. – Warren Young Jun 10 '14 at 19:39
  • /etc/ssh should definitely be included, but also in the "wait until last" category. – a CVn Jun 10 '14 at 20:04
  • @MichaelKjörling: Thanks, I've added /etc/ssh/*key* to the list above. Everything else in /etc/ssh should fall under the "boring configuration data" rule. – Warren Young Jun 10 '14 at 20:16

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.

  • +1 good point about multiple random passes being overkill. Personally, I'll probably be wiping with zeroes or a single pass of /dev/urandom. – Michael Kropat Jun 11 '14 at 16:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.