[TriLUG] question about data security with vmdks

[David Both]

To me it is not so much about the gummint trying to recover my hard drive as it is the folks at the (offshore??) recycling center looking to steal my identity.

I like to use the shred command to delete sensitive data. Shredding means overwriting multiple times with differing bit patterns. It works equally well on a file, a partition, or an entire drive. 

	shred -u -n 25 /path/to/file

Shreds the file 25 times and unlinks (deletes) it at the end. Beware of the caveats on various types of file systems. See the man page.

	shred -n 8 /dev/sdb

Shreds the entire contents of the sdb drive starting at the boot record, 8 times.

I just love "everything is a file!"

-- 


*********************************************************
David P. Both, RHCE
Millennium Technology Consulting LLC
919-389-8678

dboth at millennium-technology.com

www.millennium-technology.com 
www.databook.bz - Home of the DataBook for Linux
DataBook is a Registered Trademark of David Both


On Wednesday, April 20, 2011 11:24:38 Alex wrote:
> 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 (
> http://hardware.slashdot.org/story/08/09/06/189248/The-Great-Zero-Challenge-Remains-Unaccepted).
> In
> 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
> environment).
> 
> 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.
> 
> ~Alex Kesling
> 
> 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.
> >
> > Igor
> >
> > On Wed, Apr 20, 2011 at 9:57 AM, William Chandler <wcchandler at gmail.com>
> > wrote:
> > > You need to overwrite the previous data.  Simple re-formatting will not
> > do
> > > this.  Most data will still be accessible by using various tools --
> > PhotoRec
> > > comes to mind.
> > >
> > > As somebody else suggested, DBan will do fairly well.  An alternative is
> > to
> > > 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  :
> > http://www.trilug.org/mailman/options/trilug/igor%40igorpartola.com
> > > TriLUG FAQ          :
> > http://www.trilug.org/wiki/Frequently_Asked_Questions
> > >
> > --
> > 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
> > address.
> > TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug
> > Unsubscribe or edit options on the web  :
> > http://www.trilug.org/mailman/options/trilug/akdom2001%40gmail.com
> > TriLUG FAQ          :
> > http://www.trilug.org/wiki/Frequently_Asked_Questions
> >
>