I belong on the 'UNIX for Dummies Questions' forum but I need to delete information on a sensitive SUN box. The company is going to use the box for a web server and I need to have the hard drives Completely clean!!!
One of the bosses 'friends' through out the term 13th level. And now it's the coin phrase of the day!!
Any clue what it means but more important, how do I clean the disks?
You could try just using "rm", then fdisk'ing the drive and creating a new partition. That will keep all but the most determined (and well-funded) hackers out.
Something my instructor had us do in HPUX class a few years ago works too.
Create a tar file and write the output to a disk device. This should destroy any data that was there. Also, if you system has a /dev/zero file. You can write zeroes to the disk as well.
Like PxT said, as long as the disk is in a "secure" site you shouldn't have to worry too much.
BTW, that reference to 13th level is referring to the 13th level of hell, reserved for the most deserving of all evil creatures and persons!
I am not sure of what urandom is, so I must pass on that. Using dd to copy /dev/zero to a disk special file will work in all cases if you use the default block sizes as you are doing.
You don't specify whether you are using a block special file or a character special file to access the disk. That cat would be expensive but would work if you use a block special file.
It is not guaranteed to work if you use a character special file, but it might depending on the disk driver, the disk hardware, and block size used for physical writes by the cat command. A raw disk device requires i/o to be aligned on a DEV_BSIZE boundary. But it's not guaranteed to fail if you don't do that.
The second smartest way to do this would be to use dd to copy /dev/zero to the raw device but using a very large block size that is a multiple of DEV_BSIZE.
But HP-UX has mediainit and SunOS has format. Instead of zeros on every pass, they use various patterns chosen by hardware experts to really test the disk. If you need more security than that, you need to use sledge hammers and blow torches.
Ahh...
/dev/urandom is kind of an "enhanced" random... faster and more "random" than /dev/random is...
It very well may be a Linux specific device then (maybe BSD too...).
Also, as a sidenote, the OP could look for a utility like wipe, which will run against a raw device (and is free too).
And now that I think about it, if you're going to use it as a web server and don't want any sensitive recoverable data on it, just zero'ing out the disk should be fine. Any more sophisticated recovery than that would require physical access to the platter, right?
Hmmm...well I had not heard of /dev/random either... I see that SunOS has a /dev/random and a /dev/urandom symlink to it. I didn't find anything with man -k. I'll look around for some docs on this thing.
As for just writing zeroes once, yeah it's probably good enough if you don't have physical access to the disk. But to take a disk with sensitive data, write zeroes to it and then make it available to the web would give a security guy a heart attack.
Suppose a write operation failed because the disk is flakey? A good driver will detect that and arrange for the write to return -1. But bad drivers exist. And few programmers do a good job of checking return codes anyway. Later on, someone might get the data with a lucky read. And this line of "reasoning" applies equally to a disk that has been wiped a thousand times. Security guys think this way...
HP-UX famously lacks a /dev/random capability which every other major vendor implemented long ago. That is one of the reasons that extablishing an ssh connection from a HP-UX box is relatively slow -- entropy (used for generating keys) has to be gathered from the system which is much slower than pulling it from /dev
While I know that this is an old posting, I wanted to put my 2 cents in. If you really want to protect the sensative data, replace the drive. It's cheap, the hardware would be faster, and the disk would last longer. Take the old drive and put it on the shelf so that you could get the sensative data back (if you ever needed to).