[TriLUG] question about data security with vmdks

David Both dboth at millennium-technology.com
Wed Apr 20 12:05:20 EDT 2011


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
> >
> 



More information about the TriLUG mailing list