[TriLUG] question about data security with vmdks
akdom2001 at gmail.com
Wed Apr 20 11:24:38 EDT 2011
My two cents.
It's a long running debate as to whether or not zeroing a drive is
sufficient to thwart all but theoretical government organizations from
recovering information. The "Great Zero Challenge" comes to mind (
my opinion, you'd need a scanning electron microscope (or some similar scale
probing device) to recover a drive that has been zeroed, and do you have
data worth that cost? If you're absolutely worried about it, then dd it
with /dev/urandom a couple times... theres no coming back from that.
It should be noted that VMDKs are not encrypted, they're well documented,
and they aren't particularly different from just a plain-Jane disk (beyond a
bit of muxing to make a VM happy when running from one) so if you have a
half intelligent recovering scheme you'll pick up data that hasn't been
overwritten with no particular problem. A potential solution is to have
your VMs run encrypted FSs inside their VMDK file, and you could even
encrypt the disk they're sitting on, but that's still theoretically
recoverable with a smidgen of computation (read: the future will render
all "present" cryptography moot). Not to mention that you'll have a
performance hit (though I don't know if this is acceptable in your
As has been mentioned, formatting doesn't particularly erase data... all it
does is remove references that the filesystem uses to point to things. If
you use an arbitrarily random hashing algorithm which is built on a per disk
basis to distribute data around the disk (as one filesystem or two may have
done...) this would theoretically be a valid solution... but most any modern
filesystem will still be recoverable provided you have the proper heuristic
approach to data recovery.
To paraphrase Bill Farrow's elegant response: You'll sleep better at night
if you make some effort to shred your data.
On Wed, Apr 20, 2011 at 10:22 AM, Igor Partola <igor at igorpartola.com> wrote:
> You could also use badblocks in write mode, where it will by default
> use patterns like 0x00, 0x55, 0xaa, and 0xff. This always made me feel
> better about recycling drives. Then again, I am no data recovery
> expert. Maybe some random noise would be better than uniform patterns.
> On Wed, Apr 20, 2011 at 9:57 AM, William Chandler <wcchandler at gmail.com>
> > You need to overwrite the previous data. Simple re-formatting will not
> > this. Most data will still be accessible by using various tools --
> > comes to mind.
> > As somebody else suggested, DBan will do fairly well. An alternative is
> > dd if=/dev/zero of=/dev/whatever. It should take a long time.
> > --
> > This message was sent to: Igor Partola <igor at igorpartola.com>
> > To unsubscribe, send a blank message to trilug-leave at trilug.org from
> that address.
> > TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug
> > Unsubscribe or edit options on the web :
> > TriLUG FAQ :
> This message was sent to: Alex Kesling <akdom2001 at gmail.com>
> To unsubscribe, send a blank message to trilug-leave at trilug.org from that
> TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug
> Unsubscribe or edit options on the web :
> TriLUG FAQ :
More information about the TriLUG