System Wipe

micxz · 07-09-2009, 07:24 PM

Hello all'

I have a server I plan to unplug or restore. But I would like to "wipe" the info on it before I tell the ISP to resell it. Just in case say they stick the hard drive on a shelve somewhere and down the road someone may get some info off of it. Unlikely but....

I was planning on removing the mail folders and possibly the vhosts (apache virtual hosts) folder & removing the users.

But I wanted to ask here if there are any other ideas of what else I should remove just to be on the safe side?
Also is there a better way to remove files on a drive besides rm -rf in this type of case when you really want no trace left?

Thanks for the tips in advance;

John VV · 07-09-2009, 07:47 PM

shred might do it
as root
[code]
cd /to/the/mail/folder
shred -f -n 1 -zu *

there also is " srm " but you will need to install that
srm will remove folders , but has a bug on some files it will just keep writing until the disk is full and not remove the file ( mostly on text files - like README and FOR SURE MS 'thumb.db' files )

dd can fill up unused space ( this might do it ???? not sure - from memory )
' dd if=/dev/rand of=/OneBigFile.bin '

micxz · 07-09-2009, 08:13 PM

Quote:

Originally Posted by John VV

shred might do it
as root
[code]
cd /to/the/mail/folder
shred -f -n 1 -zu *

there also is " srm " but you will need to install that
srm will remove folders , but has a bug on some files it will just keep writing until the disk is full and not remove the file ( mostly on text files - like README and FOR SURE MS 'thumb.db' files )

dd can fill up unused space ( this might do it ???? not sure - from memory )
' dd if=/dev/rand of=/OneBigFile.bin '

Cool I'm going to read up a bit about `shred` this sounds like the way to go.

srm sounds like problems. I'll skip that one.

And your last suggestion why would I want to fill up space with dd?

micxz · 07-09-2009, 09:15 PM

Look like shred does not work recursively. So looks like I will have to write a script to traverse the directory tree and shred everyones mail.

and of course check to make sure I'm on the right server

syg00 · 07-09-2009, 09:36 PM

If I am returning a machine (leased) I scrub the whole disk(s). Their problem to rebuild it in need, not mine.
If I wanted to do something like you, I'd delete all the data I cared about, back it up, scrub the disk(s) and restore everything (remaining) using filesystem level tools (rsync, cp, ...). That way no edit recovery data, no journal data, no nothin gets left behind.
Could be difficult to achieve on a (remote) hosted machine - more so if virtualized.

micxz · 07-09-2009, 09:47 PM

find . -type f -print -size +1c -exec shred -f -n 1 -zu {} ;

Yeah! Hoping this won't take too long as there are 12gigs+ of mail in there'

micxz · 07-09-2009, 09:56 PM

Quote:

Originally Posted by syg00

If I am returning a machine (leased) I scrub the whole disk(s). Their problem to rebuild it in need, not mine.
If I wanted to do something like you, I'd delete all the data I cared about, back it up, scrub the disk(s) and restore everything (remaining) using filesystem level tools (rsync, cp, ...). That way no edit recovery data, no journal data, no nothin gets left behind.
Could be difficult to achieve on a (remote) hosted machine - more so if virtualized.

- How would you "scrub the disk(s)"? simply delete? reformat?
- And this is a remote machine.

I would like to reformat the whole disk but I don't know about doing this remotely.

syg00 · 07-09-2009, 10:07 PM

dban if I have the inclination - else just dd the entire disk, then recreate the partitions/filesystems as needed.

micxz · 07-09-2009, 10:20 PM

Thanks. But since this is a rented server I can't put a dban disk in as I'm in California and the server is in Texas. And if I dd'd the whole disk I obviously would not have a shell to do so on without a live cd or other means.

H_TeXMeX_H · 07-10-2009, 04:45 AM

The easiest way is first use 'rm' to remove all files you don't want, then run this:

Code:

dd if=/dev/zero bs=4m of=file; rm -f file

That will overwrite any deleted files with zeroes.

Also, don't bother using urandom or rand or random, unless you're extremely paranoid and have time to waste. There have been no documented cases of data ever being recovered after a drive is zeroed, and no realistic methods to do so, and no sound theory that is actually possible to do so with any degree of accuracy.

micxz · 07-11-2009, 01:02 AM

Code:

[root@phoebe domain.com]# find /var/www/vhosts/domain.com/ -type f -print | xargs dd if=/dev/zero bs=4 of=- ; rm -f - ;
dd: unrecognized option `/var/www/vhosts/domain.com/error_docs/bad_request.html'
Try `dd --help' for more information.

I tried to use find's -exec but no dice either'

Code:

[root@phoebe domain.com]# find . -type f -print -exec dd if=/dev/zero bs=4m of={} \; rm -f {} \;
find: paths must precede expression
Usage: find [path...] [expression]

find thinks /dev/zero is where I want to look.

I'm able to use find and exec to "shred" but my find command& been slowly shredding emails for over 24 hours.

Any ideas how I can run though every file and dd it? Thanks for all you help so far guys er girls'

jschiwal · 07-11-2009, 01:55 AM

Your last find command will create a new file (with an new inode) instead of zeroing out the old information.

One thing you might consider doing is deleting the files, and then filling the free space with zero's or pseudorandom characters.

Use the df command to determine the free space on the filesystem. Use that amount for the size of the file.

dd if=/dev/urandom bs=1k count=<df results> of=/directory/to/junkfile

If you are really paranoid, you could do this repeatedly, or use the shred program on this new file. However shred may not work if the filesystem uses journaling. A larger block size would be faster. You will need to divide the size of `count' by the same factor you multiply the block size. I simply used the same block size as the df command.

micxz · 07-11-2009, 02:14 AM

Yeah good call. I think will do the trick fastest' Thank You all for the great answers!

I do think as suggested above urandom, random, rand might take a while so I plan to use /dev/zero.

karamarisan · 07-11-2009, 02:31 AM

Before you go - I'd like to append to the dd thing. The most efficient way to clear a disk is to boot a live environment of some kind and `dd if=/dev/zero of=/dev/sda`, replacing sda with the disk (not the partition) you want wiped. This will set absolutely every byte on the drive to zero, and unless you are attempting to sabotage the US government, I don't think there's any reason to believe you'll need more than that.

micxz · 07-11-2009, 02:54 AM

Quote:

Originally Posted by karamarisan

Before you go - I'd like to append to the dd thing. The most efficient way to clear a disk is to boot a live environment of some kind and `dd if=/dev/zero of=/dev/sda`, replacing sda with the disk (not the partition) you want wiped. This will set absolutely every byte on the drive to zero, and unless you are attempting to sabotage the US government, I don't think there's any reason to believe you'll need more than that.

If you read the whole thread you would know this is a leased server. So there is no way I could boot a live cd. And I understand what the commands do thanks for the reiteration. And finally if this where "sabotage" I think I would "need more than that"!