Open Source

Securely delete files with shred

If you want to delete sensitive data and make sure that it can't be recovered, the Linux rm command may not be enough. For deletion and file scrubbing, try the shred command, which overwrites data with gibberish before deleting it.

There are two utilities on a typical Linux box that can be used to delete files. Most users are familiar with the rm command. Most of the time, this command is sufficient for routine deletion, but for files that contain sensitive data, you might need to scrub them so that they cannot be recovered later with other data retrieval tools.

To delete files with sensitive content, rm is not sufficient. Instead, consider using the shred command, which not only deletes a file, but deletes it in such a way that it cannot be recovered. Shred overwrites the file multiple times with garbage prior to deleting it, ensuring that if anything does get retrieved, it isn't your top-secret data.

For instance:

$ echo "this is private data" >private.txt
$ cat private.txt
this is private data
$ ls -l private.txt
-rw-r--r-- 1 vdanen vdanen 21 Mar  4 09:36 private.txt

To illustrate how shred works, call it without any command-line options so that the garbage in the file can be viewed:

$ shred private.txt
$ cat private.txt
?9?-?w?K?=???l;b8SƉ?b???????@,?18!??DM??P?
...
$ ls -l private.txt
-rw-r--r-- 1 vdanen vdanen 4096 Mar  4 09:36 private.txt

The rest of the output is removed as it is binary gibberish. You can also see the file size has changed.

To delete the file after overwriting it with garbage, use the -u option. To see what shred is actually doing, give it the verbose -v option:

$ shred -u -v private.txt
shred: private.txt: pass 1/25 (random)...
shred: private.txt: pass 2/25 (cccccc)...
shred: private.txt: pass 3/25 (111111)...
shred: private.txt: pass 4/25 (000000)...
shred: private.txt: pass 5/25 (999999)...
shred: private.txt: pass 6/25 (aaaaaa)...
shred: private.txt: pass 7/25 (924924)...
shred: private.txt: pass 8/25 (b6db6d)...
shred: private.txt: pass 9/25 (6db6db)...
shred: private.txt: pass 10/25 (888888)...
shred: private.txt: pass 11/25 (492492)...
shred: private.txt: pass 12/25 (db6db6)...
shred: private.txt: pass 13/25 (random)...
shred: private.txt: pass 14/25 (ffffff)...
shred: private.txt: pass 15/25 (bbbbbb)...
shred: private.txt: pass 16/25 (777777)...
shred: private.txt: pass 17/25 (444444)...
shred: private.txt: pass 18/25 (dddddd)...
shred: private.txt: pass 19/25 (333333)...
shred: private.txt: pass 20/25 (555555)...
shred: private.txt: pass 21/25 (222222)...
shred: private.txt: pass 22/25 (eeeeee)...
shred: private.txt: pass 23/25 (666666)...
shred: private.txt: pass 24/25 (249249)...
shred: private.txt: pass 25/25 (random)...
shred: private.txt: removing
shred: private.txt: renamed to 00000000000
shred: 00000000000: renamed to 0000000000
shred: 0000000000: renamed to 000000000
shred: 000000000: renamed to 00000000
shred: 00000000: renamed to 0000000
shred: 0000000: renamed to 000000
shred: 000000: renamed to 00000
shred: 00000: renamed to 0000
shred: 0000: renamed to 000
shred: 000: renamed to 00
shred: 00: renamed to 0
shred: private.txt: removed

As you can see, shred overwrites the file 25 times with garbage. After this, it renames the file 11 times before deleting it.

Shred can also be used to overwrite entire disks instead of just files. If you wished to overwrite the contents of an entire hard drive, a process which would definitely take a fair amount of time, use:

# shred -u -n 30 /dev/hda

This will overwrite the data on the drive with garbage using 30 passes. The drive will need to be re-formatted after this as even the filesystem structure will be destroyed.

About

Vincent Danen works on the Red Hat Security Response Team and lives in Canada. He has been writing about and developing on Linux for over 10 years and is a veteran Mac user.

12 comments
dgs010243
dgs010243

The most indicated procedure is to backup regularly the sensitive files and folders. It is mandatory. The second is to have a supplimentary partition with the Windows XP/NT. Sorry! Please avoid to choose the NTFS organization. as consequence you can save files from Linux to a FAT-32 partition. The third and the most important procedure is to have a wireless closed private network, transporting your strategic files to many nodes. Yours faithfully, Dan Gheorghe http://dan.somnea.free.fr/2C/

DanLM
DanLM

Isn't that a shread? From the man page: [i] -P Overwrite regular files before deleting them. Files are overwritten three times, first with the byte pattern 0xff, then 0x00, and then 0xff again, before they are deleted. Specifying this flag for a read only file will cause rm to generate an error message and exit. The file will not be removed or overwritten. [/i] Or is that just Unix???? Dan

BALTHOR
BALTHOR

Is this what the author of Linux had in mind?A lot of typing?

TripleII-21189418044173169409978279405827
TripleII-21189418044173169409978279405827

Shred, from their own man page, CAUTION: Note that shred relies on a very important assumption: that the file system overwrites data in place. This is the traditional way to do things, but many modern file system designs do not satisfy this assumption. ... * log-structured or journaled file systems, such as those supplied with AIX and Solaris (and JFS, ReiserFS, XFS, Ext3, etc.) ... Since the default for Linux is Ext3, or ReiserFS, shred is not actually overwriting on place. Your tool to shred an entire disk using, shred -u -n 30 /dev/hda is a good one, however, format the disk to be EXT2 (non journalised) before you run the command. TripleII

techrepublic@
techrepublic@

You can use CLI or GUI, it's your choice! p.s. Is this what the author of Windows had in mind? A lot of clicking?!

apotheon
apotheon

Someone inform the developer of the BALTHOR artificial intelligence project that BALTHOR has started repeating itself. This is the second time I've seen this exact formulation of a BALTHOR post on TR.

zefficace
zefficace

Considering that you really need only the following: $ shred -u private.txt And that everything else is for the purpose of illustrating the example. Do you really find that a lot of typing? Oh, and by the way, no matter how many time you click a file under windows, you won't shred it without 3rd party software. So unless you know something I don't, typing is better than nothing. Lastly, before anyone calls me a zealot, I use bot windows and linux, thank you.

maxhetrick
maxhetrick

Actually, I thought ext 3 was by default mounted as: data=ordered Which according to the clause of shred: "In the case of ext3 file systems, the above disclaimer applies (and shred is thus of limited effectiveness) only in data=journal mode, which journals file data in addition to just metadata. In both the data=ordered (default) and data=writeback modes, shred works as usual. Ext3 journaling modes can be changed by adding the data=something option to the mount options for a particular file system in the /etc/fstab file, as documented in the mount man page (man mount)." This means that if the ext3 journaling mode is data=ordered or data=writeback, then shred works just as expected. From my understanding, ext3 is default as data=ordered. If you do a man mount you can see what ordered means. It pushes all data out to the main filesystem prior to the metadata being committed to the journal. So it depends on how you have your ext3 filesystem being mounted.

Jaqui
Jaqui

even journalized file systems in linux will not move a file to a different physical location on disk unless needed to allow for file size increase. and the 4 k shown in Jack's example after shred hit the file is a minimum allocation for a file on any linux filesystem. so, while shred relies on physical location to be effective, the journilized file systems do not move files around at every read / write operation.

techrepublic@
techrepublic@

It is easy to configure a GUI file manager (e.g. Konqueror) to call shred on a set of files. So if point & click shredding is your (the readers) preference, it's easily available.

apotheon
apotheon

Because ext3 is the default filesystem for (most) Linux distributions, and data=ordered is the default journaling mode for ext3, Linux users should be fine. As a FreeBSD user, the fact I'm using UFS instead of one of those wacky journaled filesystems on a Linux-based OS means I'm covered, too.