I find that the best tool for the job is secure remove. The command srm will allow you to do a 38-pass deletion wipe that's good enough for most purposes. Note that it's not impossible to recover the data deleted in this method, just beyond the reach of any small to medium sized organization.
Install secure remove:
$ sudo apt-get install secure-delete
Now, you could use this command to bash script a quick exit, but without forking off your processes, a quicker way would be to run each part of your secure removal separately. This works very well if you've got multiple cores or processors. You can use process management tools such as screen or background processes to run multiple srm commands at one time.
The three basic parts of your server you should consider deleting would be the MySQL databases, Apache www folder, and your logs. If you've installed any other software, be sure to check those out as well.
MySQL
sudo srm -rv /var/lib/mysql/
Web root
sudo srm -rv /var/www/
Logs
sudo srm -rv /var/log/*
You'll have to use your judgment on the rest of the system on an individual basis. Don't forget to delete any backups you've made. The last thing you can do is clear out your private files before you exit.
sudo srm -r ~/.*
That's all. SRM uses a lot of processor and takes some time on larger directories and files, so be sure to start your deletes in a relatively parallel fashion if you've got to high-tail it out.
Expect to see the series on "The Tracker Demystified" next week. Hopefully, if I write loud enough, that might happen. ;)
CurlyFries adds: Only stuff that you delete with srm will be securely removed. For this reason, do not drop your MySQL databases prior to hitting /var/lib/mysql with your srm stick. If you do so, MySQL will (insecurely) delete your database files, and running srm afterwards will do you no good.
Oh yeah, and hush up. I'm getting to it.
7 comments:
A 38 pass delete is unneeded and will just take more time, meaning you can delete less in your limited window. Please see:
http://16systems.com/zero/
I've always had great faith in dd, but I'm not a professional data recovery firm and only go by the fact that the government claims that even 38 passes doesn't do a great job. What I've heard is that the only way to stop data recovery is to abrade the disk surface or melt it down. Your source is less than optimal. What reputation do they hold? That site is barren of anything that would lead me to believe anything they write, so I'd have to look into it further.
a quicker way would be to run each part of your secure removal separately. This works very well if you've got multiple cores or processors.
I disagree and I ran some tests to back it up.
test system: four dual-core 2.2ghz Opteron 875 processors (8 cores total), 4x146GB 10krpm RAID5, 32GiB ram, RHEL AS4 2.6.9-34.ELsmp
test content: eight 20MiB files of /dev/urandom data.
test results: eight srm processes deleting the 8 files concurrently took 675 seconds.
2 concurrent srm processes deleting the 8 files took 366 seconds.
one srm process at a time, deleting the 8 files took 353 seconds.
If the files are on different disks, then you can and should run concurrent deletes, but don't delete more than one file at a time on the same disk. I believe the primary reason is seek latency. If you had a SSD, multithreading like you suggested could be a good idea. But for the most part, SRM is not processor bound.
for clarity;
you can run concurrent deletes if the files are on different disk or arrays. you shouldn't do concurrent deletes on the same array, unless it's a JBOD and you know where the files are physically located, which isn't common.
great blog btw, thanks a lot.
Crash,
First of all, you should know that SRM is not ideal in RAID arrays with stripped disks.
In my experience, and a recent test, deleting a 250 MiB archive maxed out 1 processor, using none of the second processor. Deleting two of such archives used 100% of both processors. I didn't time the operation, so I could be incorrect about the time it takes, but I know that processor affinity is to one at a time on my Ubuntu box.
@checkers,
That site you linked not does not back up what they're saying with any reputation. The challenge they present asks specifically to recover only the names of a file or folder. You can't win the challenge by recovering the data. Doesn't that sound fishy to you?
Also, a quote from Peter Guttman, a developer of data overwrite algorithms: "...it is effectively impossible to sanitize storage locations by simply overwriting
them, no matter how many overwrite passes are made or what data patterns are written."
I'd just like to step in and say Thank you for a great writeup on this! There's very few good examples out there and I've recently needed to move out of a dedi I've had for a few years, and unfortunatly can no longer afford. So in my case there's no hard feelings, or dire need to ditch out quickly, but I rest easy knowing that there will be no leftovers for anyone else to pry upon. Just good security practice for anytime this type of situation arises.
I've been keeping up on all of your post's guys, great stuff, and thanks for dedicating the time to do this on the side of running another site. Busy guys.
Post a Comment