-   Linux - Security (
-   -   Secure erase HDD from within itself (

paddyrooney 12-16-2009 07:47 AM

Secure erase HDD from within itself
Hoping somebody else has come across this type of problem, I have several RH linux blades on a remote site which use SAN drives for all their disc, what I need to do is to secure erase the systems own discs from within itself as I am not able to get a network boot working from the kickstart server (hardware issue), I am decommissioning the servers but need to securely wipe the SAN LUNs before handing them back to be allocated for other systems. I have checked with the SAN team and they cannot preform this task for me as they have no visibility of the LUNs/filesystems only the block devices, any suggestions would be welcome.

sundialsvcs 12-16-2009 08:26 AM

This is a bit "out of my league," but I was under the impression that SAN devices usually possess the ability to "secure-erase themselves." In other words, specifically for this purpose: you've pulled the devices but need to erase them before you can put them back into the stockroom, on eBay, or into the trash. I would be very surprised if such a useful feature were limited to "guv'mint grade" hardware intended only for applications such as ==OMITTED==.

"Secure erase" would, of course, be a "block-level operation," not a filesystem-level operation.

paddyrooney 12-16-2009 08:48 AM

You are correct that the SAN would be able to secure erase themselves but only at a Block device level and not at the LUN/filesystem level that I need to, as there are other LUNs in the same block that are still required, so I need a way to securely wipe the data including the OS from the LUNs before handing them back to the SAN team. Is there a way to store say the commands that I would need in to system memory to preform the task and then shutdown the machine.

beadyallen 12-16-2009 01:43 PM

Interesting problem.
First off, you can do the secure equivalent of 'rm -rf'. That would wipe out the files, but you wouldn't be able to reboot. Dunno if that's absolutely essential to you, but I don't think it's a good solution anyway.
Second trick might be to try chrooting into a ram disk, and remounting the root partitions within that. I'm fairly sure it wouldn't work though. It's still mounted above, and chroot isn't a full blown 'new' boot. In a similar vein, I wonder if you could use 'kexec' to soft reboot the kernel into a ram disk?

Your best shot might be to reboot and use an initramfs to mount and wipe the SAN filesystems. Although initramfs's are usuually used to load modules and such at bootup, there's not reason you can't have them do anything you want (such as wiping the filesystems). Depending on your distro, there's probably a mkinitramfs package available to help you. Check this to get the general idea as to what can be achieved.

Finally, it might be easier to try to figure out how to get network booting working rather than messing around with the above. What's the problem with it?

Hope that gives you some ideas.

syg00 12-16-2009 04:20 PM

Me, I'd just drop down to an "init 1", disable SELinux, unmount what I could and start wiping.
The non-O/S system LUNs shouldn't be a problem; why not just "dd if=/dev/zero ..." over the top of them. Depends on your "securely delete" requirement - but for in-house I'd consider that sufficient.
For the system itself you should be able to do similar - turn off as much logging as possible and zap it. I can't see why you'd need to go out to the disk itself for data whilst doing this.

Untested of course ... ;)

All times are GMT -5. The time now is 01:35 PM.