A Better Way to Delete a Server

unSpawn · 11-11-2009, 04:20 PM

Quote:

Originally Posted by catkin

Has this ever been reliably demonstrated to allow recovery of significant data?

I remember I did test different methods of deletion and recovery a year or so ago. I don't have the results at hand right now but I could run tests again and post them (in a way anyone could reproduce them with the right tools). Anyone interested is invited to create a separate thread and we'll take it from there.

kschmitt · 11-12-2009, 11:03 AM

Quote:

Originally Posted by b10m3ch4

All good ideas I am looking forward to trying. Also, I am experimenting with replacing the /var/log with a sym link to a TrueCrypt partition. If this is successful, is there any other place data concerning IP connections could be stored that are not addressed in my scripts above?

Also, what little distro do you recommend, and how do you set the user and IP info of a such a distro?

Back in the day I would have gone with tomsrtbt, but I don't think it supports LVM... So either crux, DSL, or something like that. If your current system is using LVM (and most likely it is) you need something that has LVM support, and many of the classic util distros don't.

Crux is actually a full distro, but it's rather small, you can install it using tar, and configure it using vim. All pluses in this situation.

It's been awhile but I think the network is configured like..
[root@localhost ~]# vi /etc/init.d/network

Good luck, and we all expect to hear the war story about this later.

catkin · 11-12-2009, 02:27 PM

Quote:

Originally Posted by unSpawn

I remember I did test different methods of deletion and recovery a year or so ago. I don't have the results at hand right now but I could run tests again and post them (in a way anyone could reproduce them with the right tools). Anyone interested is invited to create a separate thread and we'll take it from there.

I'm interested so started this thread.

b10m3ch4 · 11-12-2009, 03:30 PM

I'm setting up a lab to test the installation of a second distro, followed by booting into that distroy, and dbanning the main drive. I am however concerned about, how to remove the logs from the new distro, to remove the IP used to login and wipe the primary drive...a bit of a catch 22.

meanwhile, if anyone is interested, here is my script I am running in cron leading up to the final conclusion of the project, which by time I hope to have mastered the remote dban procedures.

As an added security step, we are now using SS5 Proxy for all interconnections, so we only have one IP to track and shred, and of course that should only appear in the SS5 logs.

I am following the new thread as well

Code:

#!/bin/sh
shred -vzfu 8 /var/logs/ssl_request_log
shred -vzfu 8 /var/log/httpd/domains/domain.net.error.log
shred -vzfu 8 /var/log/httpd/access_log
shred -vzfu 8 /var/log/httpd/error_log
shred -vzfu 8 /var/log/httpd/homedir.log
shred -vzfu 9 /var/log/directadmin/da-popb4smtp.log
shred -vzfu 8 /var/log/messages
shred -vzfu 8 /var/log/maillog
shred -vzfu 8 /var/log/secure
shred -vzfu 8 /var/log/btmp
shred -vzfu 8 /var/log/wtmp
shred -vzfu 8 /var/log/xferlog
shred -vzfu 8 /var/log/lastlog
shred -vzfu 8 /var/log/ss5/ss5.log
shred -vzfu 8 /var/log/audit/audit.log
#
touch /var/logs/ssl_request_log
touch /var/log/httpd/domains/domain.net.error.log
touch /var/log/httpd/access_log
touch /var/log/httpd/error_log
touch /var/log/httpd/homedir.log
touch /var/log/directadmin/da-popb4smtp.log
touch /var/log/messages
touch /var/log/maillog
touch /var/log/secure
touch /var/log/btmp
touch /var/log/wtmp
touch /var/log/xferlog
touch /var/log/lastlog
touch /var/log/ss5/ss5.log
touch /var/log/audit/audit.log
#

ramram29 · 11-12-2009, 04:21 PM

`dd if=/dev/zero of=/dev/hda` will fill your disk with zeros from start to finish. However, this may take a very long time, especially if the disk is very big.

b10m3ch4 · 11-12-2009, 05:21 PM

Well, I found a way to totally kill all the logs in one swoop, and I can store client files in the TrueCrypt virtual drive, so I may not need to do anything else...unless Linux some how logs SSH/FTP/WWW access somewhere other than in /var/log...does it?

Anyway, here's my final script, short, and sweet.

Code:

#!/bin/sh

for i in `find /var/log -type f`; do
shred -fxz -n 8 $i;
rm -f $i;
touch $i;
done

Question, does anyone know if I run this as a cron job, will writing log files to zero bytes cause problems for any standard processes?

chrism01 · 11-12-2009, 07:14 PM

Well, on a running system, /var/log is a busy area, there's nearly always something writing there. I'd mount it 'cold' from another 'system/rescue disk' to do that.
You may already be doing that.

b10m3ch4 · 11-12-2009, 09:06 PM

I'm using the -f for shred, seems to work. It does hang up on single files from time to time, but the next pass gets it, and the hanging up doesn't keep it from wiping the other files. So far so good...but is this everywhere IPs would be logged?

chrism01 · 11-12-2009, 10:00 PM

Depends on the apps you are using. Most apps that come with Linux / from a repo log in there (I think?), but in this particular case I'd check each one.
Of course if you used a VM, you could blow away the entire env each time. Just have a created-but-not-used VM ready, so you can clone it quickly into a working VM.

OlRoy · 11-17-2009, 12:42 PM

Recovering useful data after an overwrite is a myth. This SANS blog post shows why.

http://blogs.sans.org/computer-foren...verwrite-data/

salasi · 11-18-2009, 07:52 AM

Quote:

Originally Posted by OlRoy

Recovering useful data after an overwrite is a myth. This SANS blog post shows why.

http://blogs.sans.org/computer-foren...verwrite-data/

Interesting; for those who haven't read the post, it describes (described when it was written, in Feb-09), a future way of recording more data on a disk than the currently used methods, describes what happens when you point an electron microscope at data on a disk (and there are several different electron microscope technologies that could be used and at no point does it say which one, so you can't comment on whether another one would be better...although the picture is quite pretty). They then mis-describe the technological approach which is putated to allow over-written data recovery, and show that this version of the technology would be not be feasible.

They then shoot off to describe a statistical approach to the recorded bits on disk and show that recovery of data from this statistical data would be very unreliable as the data from a pristine drive would be very similar to the data from that from a drive on which the data was previously a one and overwritten with a one.

There is then another mangled description of reading overwritten data.

There is then a section on RLL drives; it is said that these are easier to analyse than current drives. This is probably true, but nothing is done to quantify this.

Here is a critical quote:

Quote:

The values do not tell you what existed on the drive prior to the wipe; they just allow you to make a guess, bit by bit

In comparison:

Quote:

PRML (and ePRML)1 drives work by taking the most likely value of the data from an analogue value. If more regions of high flux density exist, the drive reads the bit cell as a “1”. In the event that the bit cell is composed of grains that mostly have a low flux value, the value is read as a “0”.

I could also describe this as 'taking a guess'; In the latter case, I know that the guess has a very high probability of being correct, in the former case, there is insufficient information to know, but the implication is that the probability is low.

Quote:

Each time you guess, you compound the error. As recovering a single bit value has little if any forensic value, you soon find that the cumulative errors render any recovered data worthless.

Here is one key to the disagreement; even if you randomly guessed the data, you'd get some of it right.

If you are a three letter agency, you will want no significant snippet of data to be recovered, other people may feel that if there is a high probability of one or more errors in a chunk of data, the data is worthless (if you were going to go to a court of law and you said 'well, I've guessed the data, but this genuinely is my best guess' and couldn't quote an impressive-sounding error rate, you probably wouldn't get very far). Those are very different standards.

For the OP, if you have an ISO9000/QS9000 procedure and are doing any less than is specified in your procedure, you are taking a silly risk. (And, if this is a normal part of you role and you don't have a procedure, there is something badly wrong with that, too.)

For anyone with non-critical data, there is clearly a chance that a single pass of overwrite will do all that you need, particularly if you have one of those disks that you can't buy yet and there is also a strong chance that no one will have the motivation to spend money on recovery services. And someone with your disk is only likely to be able to recover a series of disconnected fragments of data, which they won't be able to do anything useful with. But is that good enough to give you peace of mind?