3

I manage a pool of systems that are loaded with software and sent to potential customers for evaluations which often land sensitive information on the drives. Before shipping them back, they typically like a standard wipe to be run to clean out the drives. Most are familiar with DBAN so I try to make sure it can work on my systems. Unfortunately, this means I'm usually in RAID driver hell trying to make sure that the versions out there support the ones my systems are shipping with. These are various kinds of 3ware and LSI ones.

Consequently, I have DBAN 1.0.7 working on some, a beta version of 2.0 on the others and 2.2.6 on some of the latest SSD based ones. Now with the LSI controllers on my IBM x3550 M3s (1064/1068) I'm getting no love at all.

Is there a way out? Do you buildroot with DBAN and try to piece the drivers together? Any other tools, free or commerical, that stay updated. I'm trying to walk people of varying technical proficiencies through this, so a boot disk with simple choices is preferable.

hmvm123
  • 31
  • 2
  • We've somewhat standardized on DBAN, and the only version I've been able to consistently make work is 1.07. I have similar IBM machines with LSI controllers and I usually end up breaking the RAID to let DBAN see the drives natively. The bonus is that it can wipe them simultaneously. – Keith Stokes Dec 22 '10 at 23:08
  • If/when you do get DBAN working, make sure to have them take the drives out of a RAID group before running DBAN (makeing them a JBOD). Otherwise, DBAN doesn't erase the parity drives. This is per DBAN's instructions. – jftuga Dec 23 '10 at 00:07
  • I did JBOD each of the disks, even removed some of the disks to leave just one in and none of DBAN 1.0.7, dban-beta.2006042900 and 2.2.6 work. IOLO DriveScrubber also dies quick early and with no error messsages, so I'm still guessing it's this system type. I'm going to pull a different 3550 M3 to see if it's just this system or the model. – hmvm123 Dec 23 '10 at 21:12

3 Answers3

1

We now use mechanical destruction to wipe drives, but we don't have a need to reuse them.

If you don't have a specific security/audit standard to target, you might have more success using a Linux boot CD and simply writing /dev/random to the drives.

Another option might be (depending on the application) encrypting the drive on the filesystem level, and having the customer change the volume key when they turn it over to you.

duffbeer703
  • 20,077
  • 4
  • 30
  • 39
  • As a customer, I'd be concerned that even if I changed my key, there may be alternate keys. I like this idea, but it needs to be developed further to have some way of assuring the customer that their key is the only key. For instance, if the server was shipped with the application configured to store data in a specific place, with instructions to obtain truecrypt and create an encrypted volume in that specific place myself. Might even make the application fail to start if that location isn't there. – DerfK Dec 22 '10 at 23:24
1

We also use DBAN. Forget about the raid drivers. For our Dell servers we broke the RAID and assigned each physical disk to it's own RAID 0 (1 disk per RAID 0). DBAN found each disk and wiped them all. The other (maybe best) option is to have the devices sent back to you without the disks and let the customer dispose of them according to thier own standards. This saves you from any liability.

Edit: I read the question again and noticed these are for eval. As long as the customer unstands it's for demo only you may be able to get away with using cheaper near-line SAS or even SATA drives to keep costs down.

murisonc
  • 2,968
  • 2
  • 20
  • 30
  • Thanks. Even JBOD isn't getting me out of this mess. My inclination would be to go down the path of leaving the drives behind, but even some of our customers are IA types in their orgs and find themselves with information they're not authorized to view. In these cases, they come to us (the vendor) to help them sort through this. Destruction of the drives, while most convenient to us, isn't what they're looking for. – hmvm123 Dec 23 '10 at 21:16
  • Some more options then. Put the drives into a system without a raid controller; then use DBAN. Maybe an external connector to a laptop? Take a look at Active Kill Disk (www.killdisk.com). Use a degausser. Here is one example http://www.datalinksales.com/degaussers/hd-2.html The degausser will ruin the disk though. – murisonc Dec 27 '10 at 21:02
  • Great inputs and thanks again. I really needed to find a way to wipe these disk in system (no degauss, no removal). Active Killdisk (freeware) worked but it looked like it was going to take 30+ hours to wipe each disk and there wasn't a way to select multiple disks on a single pass. Doesn't look like they've done an update since 2008, so I'm not certain the product is alive anymore. Acronis Drive Cleanser, Iolo Drive Scrubber and Knoppix couldn't see the disks. I've finally found something that works with Parted Magic 5.7, where I'm using nwipe, which is the primary engine from DBAN. – hmvm123 Dec 28 '10 at 19:51
1

I had similar problems with DBAN 1.07/2.2.6. I had some spare time so I rolled my own i686 and x86_64-generic versions of buildroot 2012.05 + disknukem (further development of dwipe by Paolo Iannelli at github). I also put in sg3_utils, sdparm and found the lsiutil 1.63 source code so that's included too (if you want to enable write cache on RAID volume, for example). The 64-bit version is available at http://www.cs.helsinki.fi/u/mcrantan/dban/dwipe-bzImage-x86_64 and works with at least Cisco B-series blades and under qemu.

Sorry for answering old topic (I hear it is sometimes frowned upon).

Mikko Rantanen
  • 11
  • 1