Deleting Data Remotely

June 21, 2006 9:48 AM

What's the best way of securely deleting data remotely?

A friend of mine rented a dedicated server, and his host was sold to an unreliable and untrustworthy company. He has a new server and has moved all of his data to it, and would now like to decommission the old one.

However, he doesn't trust the hosting company, and would like to wipe the server as thoroughly as possible remotely. It's a RedHat OS, with a single drive, and he does have the root password.

The obvious answer is rm -rf [directories] but as we all know, rm doesn't overwrite data so that it can't be recovered.

posted by dweingart to computers & internet (12 comments total)

The "shred" command is available on most Linux systems, and will overwrite a file or device repeatedly to attempt a secure deletion. See the man page for details.

If possible, he should unmount the filesystem and run shred on the raw device (e.g. "/dev/hda"). For the root filesystem on a remote server this probably won't be possible, so hopefully his important data is not on the root filesystem.
posted by mbrubeck at 9:52 AM on June 21, 2006

It's unlikely that the hosting company would go to much trouble to recover your friend's data, but better safe than sorry.

Is there a possiblity that the hosting company is backing up the data? If so, there's no way to remove their backups. One possible option would be to overwrite all files but not delete them-- depending on their backup system, this would eventually overwrite their archives. Shred does this if the remove switch isn't set.
posted by justkevin at 10:06 AM on June 21, 2006

from `man shred`:

CAUTION: Note that shred relies on a very important assumption: that the filesystem overwrites data in place. This is the traditional way to do things, but many modern filesystem designs do not satisfy this assumption. The following are examples of filesystems on which shred is not effective:

* log-structured or journaled filesystems, such as those supplied with

AIX and Solaris (and JFS, ReiserFS, XFS, Ext3, etc.)

--

so unless you're using ext2 or some other non-journalled filesystem, the best way is probably to unmount the partition that sensitive data was on and do

dd if=/dev/zero of=(device name of partition)
posted by (lambda (x) x) at 10:45 AM on June 21, 2006

If you're using a journaled filesystem, shred will still do its job fine if you unmount the partition and shred the entire raw device, as mbrubeck suggested. Also, if you're using ext3, you can remount it as ext2, and then shred the contents effectively.
posted by brett at 10:59 AM on June 21, 2006

Is there a possiblity that the hosting company is backing up the data? If so, there's no way to remove their backups.

Take off and nuke the site from orbit. It's the only way to be sure.

Seriously though, lambda, there's no way to do what you suggest if the data and root reside on the same partition, is there?
posted by The Bellman at 11:26 AM on June 21, 2006

Delete all the sensitive data. Upload files to the hard drive until it is full. Voila.
posted by Jairus at 11:37 AM on June 21, 2006

I say we take off and nuke the entire site from orbit. It's the only way to be sure.
posted by roue at 11:58 AM on June 21, 2006

First, remove all the data you care about with the good old rm command. Then, in each partition with sensitive data:

dd if=/dev/urandom of=bigrandomfile bs=512

That will create a gigantic file that will fill up the whole partition, and overwrite the old data. (this can take an hour or two to run, if it's a big drive.) Verify that it there are 0 bytes free on the partition after finishing... some filesystems can't make files bigger than 2g, so you may need to make several files to fill up every byte on the partition. And make sure you do this on all your partitions... if you fill up /usr, it won't affect /tmp at all, if they're on separate mountpoints.

Once should be more than enough, but if you're paranoid, you can remove the file(s) and rerun the process two or three times.

As a last step, and understand that this will destroy the entire software installation, equivalent to nuking it from orbit... determine the name of the hard drive in the system. This is usually /dev/hda, but can be /dev/sda as well. Do:

dd if=/dev/urandom of=/dev/hda bs=512

That will totally overwrite the drive in question and destroy all data. There will be nothing left at all.

The reason you do it with the file first is because it doesn't kill the system. You can do it several times, and if it's interrrupted, no big deal.

The second method is the slash and burn approach... salting the earth, so to speak. Once that's done, you can't go back, and if it fails to completely finish, you could leave sensitive data behind. So you do the file version first, and then the drive.
posted by Malor at 12:21 PM on June 21, 2006

justkevin - thanks for pointing out the issue of backups. I don't think the server is being backed-up at this point, but it does suggest that being super-paranoid is probably pointless.

After all, the hosting company has physical access to the machine, and if they were properly motivated they'd have all data they wanted already.

My friend isn't really worried about the hosting company stealing the data. He's more concerned that they won't wipe the machine properly before giving it to another customer.

I should note that I'm pretty sure that everything important is on the root filesystem, so I don't think I'd be able to unmount it. I like Malor's approach the best - delete (or shred) all the sensitive files first, and then slash and burn by using dd to overwrite the device.

Thanks all!
posted by dweingart at 1:08 PM on June 21, 2006

If shred is available, use it instead of "dd" for the final step. Shred does essentially the same thing, but it does it 25 times with different, specially-designed sequences. A file that has only been overwritten once or twice might still be recoverable.
posted by mbrubeck at 1:49 PM on June 21, 2006

If shred will run completely from memory, and you have it available, I don't see any reason NOT to use it... but I'd try it on a local installation, where I could watch the entire process, before trying it remotely. Many programs get Most Upset if you wipe out the drive from which they loaded.

I *know* dd will work this way, because I've used it numerous times to do exactly what he's asking for. Shred may also work, but I have never run it remotely, so I can't be certain.
posted by Malor at 3:37 PM on June 21, 2006

The only way to recover data from a drive that's had everything overwritten by dd from /dev/urandom is to physically take it out of the computer and analyze it with The Most Expensive Machine In The Hospital. Shred attempts to make even that impossible, by writing so many layers of crap over the original that even clever forensic electronics can't recover it.

If all you're trying to prevent is casual access to your old data, dd is more than adequate (and faster than shred, because it writes less stuff).

Also, if you use bs=1048576 rather than bs=512, dd will run a fair bit faster (because it's doing its writes in megabyte-sized chunks instead of 512-byte chunks). Yes, it will still overwrite the smaller-than-one-megabyte leftover part at the very end of the drive.
posted by flabdablet at 8:29 PM on June 21, 2006