Securely erasing files, by filling your disk
Posted by Steve on Sat 2 Jan 2010 at 14:34
With modern filesystems securely deleting files isn't always easy, but one approach which stands a good chance of working is to write random patterns over all unused areas of a disk - thus erasing the contents of files you've previously deleted.
The Debian secure-delete package contains a number of tools, but the one that I get the most use out of and the one which I'm most confident of is sfill.
The sfill command allows you to write data to all unused areas of a mounted partition. This should ensure that the contents of any deleted files have been overwritten, thereby giving you confidence that their contents are well and truely gone.
To get started install the package:
gold:~# aptitude update gold:~# aptitude install secure-delete
Once installed you can overwrite the unused content of any mounted partition like so:
gold:~# sfill /home
Note: This assumed /home is mounted as a partition. In my case it is, as we can see from this output:
gold:~# mount | grep /dev /dev/mapper/gold--vol-root on / type ext3 (rw,noatime,nodiratime,errors=remount-ro) udev on /dev type tmpfs (rw,mode=0755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620) /dev/md1 on /boot type ext3 (rw) /dev/mapper/gold--vol-home on /home type ext3 (rw) /dev/mapper/gold--vol-music on /home/music type ext3 (ro) /dev/mapper/gold--vol-kvm on /kvm type ext3 (rw)
When you run sfill the program eats up all free space by creating a huge file. Then the contents of this file are written in a number of steps - ensuring that all areas of the disk which were previously free have had their contents erased. Once completed the huge file is removed, meaning you have free disk space again.
For more details please consult the files installed beneath /usr/share/doc/secure-delete, or read the manpage via "man sfill".
But I would assume this tool would not go well on a multi-user system.
Creating a file to fill all of home's partition would annoy the other users.
If the partition is large (several GB or more), this could take a long time.
I guess the best rule here is don't store sensitive information on a multi-user partition; unless you are root and know when the least people are using the machine.
For a single-user personal machine I think this would help, but it still would take a lot of time, if the empty space is large; sort of like wiping a whole disk drive.
Thanks for the article, I have not noticed the secure-delete package before.
Seems like every time I look at the listings in Aptitude I find something new.
That is surely a sign of a large repository!
Happy New Year!
[ Parent | Reply to this comment ]
[ Send Message | View Steve's Scratchpad | View Weblogs ]
Yes it can take a long time - and agreed that if you're on a multi-user system that others will be inconvienced when the drive is full.
Still I'd hope that if you're the admin of a multi-user system you'd choose a time when others aren't using the system, and that you'd take care to disable email deliveries, etc. (So that delivering to ~/Maildir doesn't fail).
Debian is huge with new packages being added all the time!
[ Parent | Reply to this comment ]
For instance, you should know that EXT3 reserves a certain percentage of blocks (5% by default) to prevent non-root users from filling up the disk. So you might need to run this as root to work properly.
Also, if you use anything quota-related, you're in bad luck as well.
And this method is not really practical if you have large amounts of unfilled storage. The process might take too long because, and services/jobs will start to crash and complain since they're out of disk space.
My advice, if you're going to do this, is to switch to single-user mode and have the system do it's things while the rest is completely inactive.
[ Parent | Reply to this comment ]
[ Send Message | View Steve's Scratchpad | View Weblogs ]
Good points about the use of quota-related tools, but you run the sfill tool as root anyway so the 5% reservation doesn't apply.
However you're right to say that it can take a long time to run, in practise I found the time wasn't too horrific, and that starting with a small partition such as /boot would give you a good idea of how long it would take to cleanup the rest.
[ Parent | Reply to this comment ]
yes, there's overhead with encrypting everything, but that's what multicore processors are for. ;-) i really only notice it during high i/o scenarios, like synchronizing two systems (ie unison) or moving large files between systems (eg copying iso from my bittorrent server to my desktop for burning). i don't notice it (ie see kcryptd at the top of top) when web browsing, emailing, or even compiling largish packages.
for a multiuser system, maybe it's more reasonable to encrypt /home and insure no user data gets written elsewhere (eg /tmp; also useful for quota reasons).
[ Parent | Reply to this comment ]
[ Send Message | View Steve's Scratchpad | View Weblogs ]
I have a mixture of both on my systems - but definitely love using LUKS to encrypt partitions.
But either way if I ever gave a disk drive away I'd run it through dban first, its just the sanest thing to do.
[ Parent | Reply to this comment ]
smartctl -a -d ata /dev/sda >smart.0baseline.log
smartctl -t offline -d ata /dev/sda
<wait length of offline test>
smartctl -a -d ata /dev/sda >smart.1offline.log
diff -u smart.[01]*.log
badblocks -v -s -p 1 -w /dev/sda
smartctl -a -d ata /dev/sda >smart.2badblocks.log
diff -u smart.[12]*.log
and it's interesting that i read dban.org trying to figure out what exactly dban did (besides the nebulous "securely wipes the hard disks"), but couldn't find anything, except the assumption that it writes "random" data based on the Gutmann FAQ entry. for badblocks, in write-mode (-w) without manually specifying a test pattern (-t), it writes 0xAA, 0x55, 0xFF, and 0x00, which effectively deletes all data, but also verifies the disk by following each write cycle with a read cycle to insure what's written is also read and can trigger SMART errors by touching a previously unused bad sector.
[ Parent | Reply to this comment ]
i translate your article to Chinese in my blog
you can see it
http://kadok0520.pixnet.net/blog/post/25604532
thank you!
[ Parent | Reply to this comment ]
[ Send Message | View Steve's Scratchpad | View Weblogs ]
Thanks!
[ Parent | Reply to this comment ]
I bought many second hand servers which were used by companies and they didn't even bother deleting any files from them or zer0ing the boot records at least...
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
1. Filesystems allocate storage in multiples of some minimum amount, and if you store a file containing one byte of data there will be a possibly substantial quantity of storage allocated for the file but unused. It is not likely that simple tools will have any effect on this unused space, but it _is_ likely (a) that the space will have been used previously to store data, possibly sensitive data, and (b) that the data will still be there unless for example the filesystem honours some attribute such as 'chattr +s' on the file (or you've been filling the disc using this technique on a fairly regular basis for quite some time... :)
2. File metadata such as name and timestamps can be an issue.
3. It is probably not necessary to fill a partition to ensure that all erased data has been overwritten, because most sane filesystems will use a least recently used algorithm when writing data. So at worst you can just write two files which are slightly bigger than half the available free space.
[ Parent | Reply to this comment ]