|
|
|
|
|
|
| Author |
Message |
Ertugrul Soeylemez
*nix forums Guru Wannabe
Joined: 28 Oct 2005
Posts: 126
|
 Posted: Tue Jun 20, 2006 10:18 pm Post subject:
Re: Disk over writing software
|
|
|
Loki Harfagr <loki@DarkDesign.free.fr> (06-06-20 01:10:23):
| Quote: | Encrypting the whole hard-disk is going to be overkill for most
configurations.
Right, but wasn't it reasonably on topic for this group to think that
this was not the question 
Besides, you were the one to say :
"That's why I prefer encrypting my hard-disk instead of being
concerned about proper disposition."
|
I didn't talk about the _whole_ hard-disk. Some parts of /etc, my swap,
my /tmp and my /home are encrypted. I use Blowfish for swap (because
it's faster), and AES for the rest.
| Quote: | and modern distributions should provide an easy way to do all this
automatically on installation, if desired (using PAM for home
directory encryption or similar). Unfortunately I don't know of any
distribution, which does that.
Er ... You seem concerned with securing a system and then you
install PAM on it !? That'd be quite as good by only rot13'ing the
filenames
|
Sure. PAM provides the necessary modules to do things on login (like
mounting an encrypted partition). Combined with LUKS you could provide
the same partition to all users, without disclosing its key, and still
mounting it only on demand. However, I don't like LUKS, hence I don't
use it. I mount my partitions after boot. =)
| Quote: | I don't know exactly, what you mean by "overall encrypt in RAM", but
if you mean encrypting all RAM contents,
Right, I wasn't very clear! I just meant about using encrypted data
for data, the main hole in a system isn't the RAM (or if it'd be
that'd just mean you're already assaulted beyond help) but in the
possibility of some data written clear on some disk, use a RAM /tmp
and encrypting pipes then you may have proper data encryption for the
parts that counts.
|
Okay, that makes things clear. But then it's not a RAM issue.
| Quote: | this is either useless or technically difficult. Remember that you
have to save the key somewhere, and you will save it in RAM.
Not only, but I'll agree on that point too, at least there'll be a
moment when the keys would be in the RAM.
|
They need to be somewhere, otherwise you would be typing passphrases
every minute. A bit over-secured. =)
| Quote: | By the way, for current RAM chips, it is hard to read the RAM
contents, without having access to the operating system running,
and/or without disturbing its operation.
And on this you have my total reddition, sorry if my poor english
writing could make you feel I was criticizing your sayings.
|
Well, I guess you got me wrong. I didn't criticize either, I just added
that as a side-note. =)
Regards,
E.S. |
|
| Back to top |
|
 |
Loki Harfagr
*nix forums Guru
Joined: 25 Feb 2005
Posts: 782
|
| Posted: Mon Jun 19, 2006 11:10 pm Post subject:
Re: Disk over writing software
|
|
|
Le Mon, 19 Jun 2006 05:27:39 +0200, Ertugrul Soeylemez a écrit :
| Quote: | Loki Harfagr <loki@DarkDesign.free.fr> (06-06-18 18:50:40):
As for the the encrypting of HDs, do not omit your to encrypt your
swap partition (or use an overall encrypt in RAM too).
Encrypting the whole hard-disk is going to be overkill for most
configurations.
|
Right, but wasn't it reasonably on topic for this group to think
that this was not the question
Besides, you were the one to say :
"That's why I prefer encrypting my hard-disk instead of being concerned
about proper disposition."
to which I absolutely agree 
I was just reminding the occasional reader (obviously not you) a
small point about swap that would defeat all previous efforts if not controlled.
| Quote: | It's useless to encrypt */bin directories, but they
will cause a noticable speed impact when encrypted -- at least, if you
don't have much RAM or a slow CPU.
|
Agreed too.
| Quote: |
However, one should encrypt his home directory, or better yet, the
entire /home tree. Encrypted swap is an obligation in my opinion,
|
If swap is *supposed* to be used then *YES* do encrypt it.
Or don't use swap, *or* use an "overall encrypt in RAM" for data,
so even if some gets in the swap reposit at some time it'll just be
a part of the noise.
| Quote: | and
modern distributions should provide an easy way to do all this
automatically on installation, if desired (using PAM for home directory
encryption or similar). Unfortunately I don't know of any distribution,
which does that.
|
Er ... You seem concerned with securing a system and then
you install PAM on it !? That'd be quite as good by only rot13'ing
the filenames ;-)
| Quote: | I don't know exactly, what you mean by "overall encrypt in RAM", but if
you mean encrypting all RAM contents,
|
Right, I wasn't very clear! I just meant about using encrypted data
for data, the main hole in a system isn't the RAM (or if it'd be that'd
just mean you're already assaulted beyond help) but in the possibility of
some data written clear on some disk, use a RAM /tmp and encrypting pipes
then you may have proper data encryption for the parts that counts.
| Quote: | this is either useless or
technically difficult. Remember that you have to save the key
somewhere, and you will save it in RAM.
|
Not only, but I'll agree on that point too, at least there'll be
a moment when the keys would be in the RAM.
| Quote: | To keep this short: Using RAM
encryption is going to be more difficult than breaking it,
|
That's a part of the game ;-)
| Quote: | thus it's
useless.
|
Well, difficult or painful aren't necessarily synonyms of useless, but
I'll agree on that point too if you meant something like "users that use
heavy passwords" will end up to print them or forget them" ;D)
| Quote: | By the way, for current RAM chips, it is hard to read the RAM contents,
without having access to the operating system running, and/or without
disturbing its operation.
|
And on this you have my total reddition, sorry if my poor english
writing could make you feel I was criticizing your sayings.
Cheers. |
|
| Back to top |
|
|
Ertugrul Soeylemez
*nix forums Guru Wannabe
Joined: 28 Oct 2005
Posts: 126
|
| Posted: Mon Jun 19, 2006 3:27 am Post subject:
Re: Disk over writing software
|
|
|
Loki Harfagr <loki@DarkDesign.free.fr> (06-06-18 18:50:40):
| Quote: | As for the the encrypting of HDs, do not omit your to encrypt your
swap partition (or use an overall encrypt in RAM too).
|
Encrypting the whole hard-disk is going to be overkill for most
configurations. It's useless to encrypt */bin directories, but they
will cause a noticable speed impact when encrypted -- at least, if you
don't have much RAM or a slow CPU.
However, one should encrypt his home directory, or better yet, the
entire /home tree. Encrypted swap is an obligation in my opinion, and
modern distributions should provide an easy way to do all this
automatically on installation, if desired (using PAM for home directory
encryption or similar). Unfortunately I don't know of any distribution,
which does that.
I don't know exactly, what you mean by "overall encrypt in RAM", but if
you mean encrypting all RAM contents, this is either useless or
technically difficult. Remember that you have to save the key
somewhere, and you will save it in RAM. To keep this short: Using RAM
encryption is going to be more difficult than breaking it, thus it's
useless.
By the way, for current RAM chips, it is hard to read the RAM contents,
without having access to the operating system running, and/or without
disturbing its operation.
Regards,
E.S. |
|
| Back to top |
|
|
Loki Harfagr
*nix forums Guru
Joined: 25 Feb 2005
Posts: 782
|
| Posted: Sun Jun 18, 2006 4:50 pm Post subject:
Re: Disk over writing software
|
|
|
Le Tue, 25 Apr 2006 06:36:50 +0200, Ertugrul Soeylemez a écrit :
| Quote: | ibuprofin@painkiller.example.tld (Moe Trin) (06-04-22 17:26:37):
One thing people often forget is defective blocks on the media that
modern drives "auto-fix". What they do is copy the data that had been
on the block (if at all possible) to a "spare" block reserved for this
purpose. The substitution is transparent - done by the drive firmware,
and not under O/S control. This means that some blocks may still exist
with old data even after a thousand writes with random data. For
common users, the data is inaccessible, as you need the manufacturers
software to reset the bad and spare block table to access those blocks
(which may or may not still be usable). This may or may not be an
acceptable level of risk. This is the reason that NISPOM requires
physical destruction of media that contained "Top Secret" data.
That's why I prefer encrypting my hard-disk instead of being concerned
about proper disposition. Using a secure key, I could lose it or throw
it away without having concerns.
Luckily proper encryption cannot be distinguished from random noise. So
an attacker might even think that I've overwritten it that way, trying
to hide data stored on the disk previously. My current hard-disk has
never received a single bit of clear-text.
By the way, is there any way to query the number of such defective
blocks for IDE drives? I don't seem to find a suitable hdparm-option.
|
Just for the dubious case in 45 days you're still searching
here's an addup to your last question.
For SMART drives you've got smart tools, as posted elsewhere.
For e2fs and family you'll find 'badblocks' tool in e2fsprogs.
PS:
As for the the encrypting of HDs, do not omit your to encrypt
your swap partition (or use an overall encrypt in RAM too). |
|
| Back to top |
|
|
Moe Trin
*nix forums Guru
Joined: 20 Feb 2005
Posts: 972
|
| Posted: Tue Apr 25, 2006 7:53 pm Post subject:
Re: Disk over writing software
|
|
|
On Tue, 25 Apr 2006, in the Usenet newsgroup comp.os.linux.security, in article
<e2k912$4d9$02$3@news.t-online.com>, Ertugrul Soeylemez wrote:
| Quote: | That's why I prefer encrypting my hard-disk instead of being concerned
about proper disposition. Using a secure key, I could lose it or throw
it away without having concerns.
Luckily proper encryption cannot be distinguished from random noise. So
an attacker might even think that I've overwritten it that way, trying
to hide data stored on the disk previously. My current hard-disk has
never received a single bit of clear-text.
|
Not using a swap partition?
Old guy |
|
| Back to top |
|
|
Grant
*nix forums Guru
Joined: 07 Mar 2005
Posts: 739
|
| Posted: Tue Apr 25, 2006 4:46 am Post subject:
Re: Disk over writing software
|
|
|
On Tue, 25 Apr 2006 06:36:50 +0200, Ertugrul Soeylemez <never@drwxr-xr-x.org> wrote:
| Quote: | By the way, is there any way to query the number of such defective
blocks for IDE drives? I don't seem to find a suitable hdparm-option.
|
smartctl ( - Control and Monitor Utility for SMART Disks
Grant.
--
Memory fault -- brain fried |
|
| Back to top |
|
|
Ertugrul Soeylemez
*nix forums Guru Wannabe
Joined: 28 Oct 2005
Posts: 126
|
| Posted: Tue Apr 25, 2006 4:36 am Post subject:
Re: Disk over writing software
|
|
|
ibuprofin@painkiller.example.tld (Moe Trin) (06-04-22 17:26:37):
| Quote: | One thing people often forget is defective blocks on the media that
modern drives "auto-fix". What they do is copy the data that had been
on the block (if at all possible) to a "spare" block reserved for this
purpose. The substitution is transparent - done by the drive firmware,
and not under O/S control. This means that some blocks may still exist
with old data even after a thousand writes with random data. For
common users, the data is inaccessible, as you need the manufacturers
software to reset the bad and spare block table to access those blocks
(which may or may not still be usable). This may or may not be an
acceptable level of risk. This is the reason that NISPOM requires
physical destruction of media that contained "Top Secret" data.
|
That's why I prefer encrypting my hard-disk instead of being concerned
about proper disposition. Using a secure key, I could lose it or throw
it away without having concerns.
Luckily proper encryption cannot be distinguished from random noise. So
an attacker might even think that I've overwritten it that way, trying
to hide data stored on the disk previously. My current hard-disk has
never received a single bit of clear-text.
By the way, is there any way to query the number of such defective
blocks for IDE drives? I don't seem to find a suitable hdparm-option.
Regards. |
|
| Back to top |
|
|
Moe Trin
*nix forums Guru
Joined: 20 Feb 2005
Posts: 972
|
| Posted: Sat Apr 22, 2006 10:26 pm Post subject:
Re: Disk over writing software
|
|
|
On Fri, 21 Apr 2006, in the Usenet newsgroup comp.os.linux.security, in article
<aJ92g.4241$mu2.1841@newssvr24.news.prodigy.net>, Bill Davidsen wrote:
| Quote: | Moe Trin wrote:
The Gutmann paper is nearly ten years old - think there might have been
some changes in technology in that time? See 'Putting the "NSA Data
Overwrite Standard" Legend to Death...' a thread on Bugtraq on 4/5 Feb 2003.
A lot depends on who you need to exclude. It takes a lot to stop a TLA
(three letter agency) but a few passes will prevent the local salvage
guy from getting at the data.
|
One thing people often forget is defective blocks on the media that modern
drives "auto-fix". What they do is copy the data that had been on the block
(if at all possible) to a "spare" block reserved for this purpose. The
substitution is transparent - done by the drive firmware, and not under
O/S control. This means that some blocks may still exist with old data
even after a thousand writes with random data. For common users, the data
is inaccessible, as you need the manufacturers software to reset the bad
and spare block table to access those blocks (which may or may not still
be usable). This may or may not be an acceptable level of risk. This is
the reason that NISPOM requires physical destruction of media that contained
"Top Secret" data.
None the less, do a search on the Bugtraq archive for a thread titled
"Peter Gutmann data deletion theaory?" (typo is in original) from July 2005.
"Simple Nomad" (a name that may ring bells if you are in security) wrote
"The quote is from 1996. I spoke with Guttman about this at AusCERT a
few years ago and even *he* doesn't believe it anymore. Drive technology
has changed substantially since then."
| Quote: | I use DBAN (ask Google) in one of the medium security modes, that pretty
much blocks anyone who doesn't have high tech.
|
The program has been mentioned several times. Multiple pass overwrites with
semi-random data are usually adequate - people forget that the ones and
zeros are not written directly to disk, but a density improvement and data
management scheme called Run Length Limited writes a different pattern to
allow packing those bits in tightly.
Old guy |
|
| Back to top |
|
|
Bill Davidsen
*nix forums Guru Wannabe
Joined: 22 Mar 2005
Posts: 217
|
| Posted: Fri Apr 21, 2006 6:43 pm Post subject:
Re: Disk over writing software
|
|
|
Moe Trin wrote:
| Quote: | Followup-To: set to comp.os.linux.security.
On Mon, 17 Apr 2006, in the Usenet newsgroup comp.os.linux.security, in article
ldo-FDCD1E.23405117042006@lust.ihug.co.nz>, Lawrence D'Oliveiro wrote:
To make data unrecoverable on magnetic storage, it's not enough to
overwrite it with purely random data (e.g. /dev/urandom output). This
does not only take forever, it's not even secure. Shred uses special
patterns to overwrite the storage.
This doesn't agree with the Peter Gutmann paper, if I recall rightly.
The Gutmann paper is nearly ten years old - think there might have been
some changes in technology in that time? See 'Putting the "NSA Data
Overwrite Standard" Legend to Death...' a thread on Bugtraq on 4/5 Feb 2003.
Old guy
|
A lot depends on who you need to exclude. It takes a lot to stop a TLA
(three letter agency) but a few passes will prevent the local salvage
guy from getting at the data. I use DBAN (ask Google) in one of the
medium security modes, that pretty much blocks anyone who doesn't have
high tech.
--
-bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me |
|
| Back to top |
|
|
Moe Trin
*nix forums Guru
Joined: 20 Feb 2005
Posts: 972
|
| Posted: Mon Apr 17, 2006 8:01 pm Post subject:
Re: Disk over writing software
|
|
|
Followup-To: set to comp.os.linux.security.
On Mon, 17 Apr 2006, in the Usenet newsgroup comp.os.linux.security, in article
<ldo-FDCD1E.23405117042006@lust.ihug.co.nz>, Lawrence D'Oliveiro wrote:
| Quote: | To make data unrecoverable on magnetic storage, it's not enough to
overwrite it with purely random data (e.g. /dev/urandom output). This
does not only take forever, it's not even secure. Shred uses special
patterns to overwrite the storage.
This doesn't agree with the Peter Gutmann paper, if I recall rightly.
|
The Gutmann paper is nearly ten years old - think there might have been
some changes in technology in that time? See 'Putting the "NSA Data
Overwrite Standard" Legend to Death...' a thread on Bugtraq on 4/5 Feb 2003.
Old guy |
|
| Back to top |
|
|
Unruh
*nix forums Guru
Joined: 22 Mar 2005
Posts: 1166
|
| Posted: Mon Apr 17, 2006 7:20 pm Post subject:
Re: Disk over writing software
|
|
|
Matthias Kirchhart <matthias.kirchhart@freenet.de> writes:
| Quote: | -----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
Lawrence D'Oliveiro wrote:
In article <20060306053730.2844ea53@kill.mine.nu>,
Ertugrul Soeylemez <never@drwxr-xr-x.org> wrote:
To make data unrecoverable on magnetic storage, it's not enough to
overwrite it with purely random data (e.g. /dev/urandom output). This
does not only take forever, it's not even secure. Shred uses special
patterns to overwrite the storage.
This doesn't agree with the Peter Gutmann paper, if I recall rightly.
If you *really* need to destroy the data on a tape, wouldn't it be easier
just to throw it into a fire until it is just a small pile of fluid
|
Agreed. Or hard disks. |
|
| Back to top |
|
|
Lawrence D'Oliveiro
*nix forums Guru
Joined: 25 Mar 2005
Posts: 723
|
| Posted: Mon Apr 17, 2006 11:40 am Post subject:
Re: Disk over writing software
|
|
|
In article <20060306053730.2844ea53@kill.mine.nu>,
Ertugrul Soeylemez <never@drwxr-xr-x.org> wrote:
| Quote: | To make data unrecoverable on magnetic storage, it's not enough to
overwrite it with purely random data (e.g. /dev/urandom output). This
does not only take forever, it's not even secure. Shred uses special
patterns to overwrite the storage.
|
This doesn't agree with the Peter Gutmann paper, if I recall rightly. |
|
| Back to top |
|
|
Michael Paoli
*nix forums Guru Wannabe
Joined: 10 Oct 2005
Posts: 107
|
| Posted: Fri Mar 17, 2006 8:38 am Post subject:
Re: Disk over writing software
|
|
|
Subba Rao wrote:
| Quote: | I am looking for some software that will over write the files on the HD
several times over. This software should meet the DOD security
requirement of cleaning up the data on the hard disk.
|
(groups trimmed)
How feasible this may or may not be, and by software means alone, may
depend on various factors, such as the nature of the hardware, the
relative degree of difficulty to be created regarding any data
recovery from the media, and the filesystem type and method(s) used.
First of all, overwriting an entire filesystem, or larger area of the
disk, will generally be more secure than attempting to overwrite less
than an entire filesystem. Secure overwrite of file(s) may be
particularly problematic with filesystems which use journaling,
where, at least typically, overwriting the same byte offset ranges to
the same file multiple times, does not result in the data being
repeatedly rewritten to the same areas on the disk. For more
specialized operations, this limitation may be at least partially
overcome, by working with more specialized tools/software, and on
filesystem which is unmounted. Note also, to generally be secure in
overwriting less than all data on a filesystem, it will generally be
necessary to overwrite all free (unallocated) blocks and slack space
(space within allocated blocks that doesn't contain data which is to
be left as it exists - e.g. if a 512 byte sector has been allocated
as the single data block for a file of logical length 100 bytes,
there are 412 bytes of slack space in that sector; similar also
typically applies to meta-data areas of the disk (directory
structure, etc.)). These issues can also be further complicated if
other technologies are used (e.g. RAID, Logical Volume Management
(LVM), etc.) - e.g. the file's data may not only exist as part of the
file's data proper, but may also exist elsewhere on disk, in areas
that are no longer part of the file's data. More modern (e.g.
non-ancient) drives also do remapping of sectors, so that an area
that may be problematic or unreliable, may still contain data, but
may not be accessed through the customary means, or via ordinary
hardware and software (e.g., in use, drive finds a sector which is
becoming difficult to read - it copies that data (upon read, or next
overwrite) somewhere else, remapping the sector, and never uses the
old sector again - that could happen at essentially any time -
including the instant one decides one needs to overwrite and securely
wipe that data).
If one is actually dealing with government classified data, there
likely are applicable standards to be used for the storage, handling,
and destruction of the data - and there may be severe civil and/or
criminal penalties for failing to follow the required procedures.
If one is dealing with data which isn't governmentally classified,
it's usually a matter of risk assessment. E.g. how valuable/critical
is the data vs. what are appropriate estimates of the resources
(available/obtainable and time) a potential adversary may likely have
and be willing to expend to attempt to recover the data - also taking
into account estimates into the future of those factors, for as long
as the data may potentially be of value.
references/excerpts:
http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html
http://en.wikipedia.org/wiki/Data_remanence
http://en.wikipedia.org/wiki/Data_remanence#Software_for_purging
shred(1)
CAUTION: Note that shred relies on a very important
assumption: that
the filesystem overwrites data in place.
Google Is Your Friend / Search The Fine Web (GIYF/STFW) |
|
| Back to top |
|
|
Shmuel (Seymour J.) Metz
*nix forums Guru Wannabe
Joined: 16 Mar 2005
Posts: 162
|
| Posted: Tue Mar 07, 2006 1:53 am Post subject:
Re: Disk over writing software
|
|
|
In <slrne0p5ep.4ej.ibuprofin@compton.phx.az.us>, on 03/06/2006
at 02:04 PM, ibuprofin@painkiller.example.tld (Moe Trin) said:
| Quote: | If this is an official requirement, talk to the Contracting Officer's
Representative
|
COTR is probably a better choice, since that is a technical issue.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org |
|
| Back to top |
|
|
Moe Trin
*nix forums Guru
Joined: 20 Feb 2005
Posts: 972
|
| Posted: Mon Mar 06, 2006 8:04 pm Post subject:
Re: Disk over writing software
|
|
|
On Sun, 05 Mar 2006, in the Usenet newsgroup comp.os.linux.security, in article
<30LOf.56418$Ug4.7105@dukeread12>, Subba Rao wrote:
[Followup set - if it belongs on comp.os.linux.security, it does NOT belong
in comp.os.linux.misc]
| Quote: | I am looking for some software that will over write the files on the HD
several times over. This software should meet the DOD security
requirement of cleaning up the data on the hard disk.
|
If this is an official requirement, talk to the Contracting Officer's
Representative and find out EXACTLY what the requirements are and what
approved software may be available. Don't do ANYTHING without getting
that approval.
If you merely wish to get something that sounds great, google for '5220.22-M'
which is the (US) DoD number for the "National Industrial Security Program
Operating Manual" (NISPOM) ISBN 0-16-045560-X. Briefly, to sanitize a
non-removable rigid drive, that the choices of degaussing, destruction of the
drive, or a 3 pass wipe are acceptable methods for disk sanitation. Note that
the 3 pass wipe method is NOT acceptable for drives that contained Top Secret
information.
It should be noted that this issue has been done to death on bugtraq several
times.
As for actual software needed to overwrite the disk (overwriting files
ALONE does not satisfy the DoD requirement), you likely have all that is
needed in '/bin/dd', '/dev/zero' and '/dev/urandom'.
Old guy |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Sat Nov 22, 2008 1:04 pm | All times are GMT
|
|
Credit Cards | MPAA | Books | Inkjet Printer | Mortgages
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
*nix
»
Linux
»
security
