Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I'm about to terminate my relationship with my hosting provider of many years, but I'd like to securely wipe the box before I do. This is a dedicated server running Debian on a single EXT3 drive and although I have root access, I can't boot alternate media since it's headless in a rack somewhere.

I don't need multiple passes, but I would like to wipe free space if possible. Basically I'd like to walk away and make sure I don't leave any of my personal data behind. I'm worried that the box might crash before it finishes wiping/syncing the filesystem if I just run srm -R -s /

share|improve this question

5 Answers 5

up vote 3 down vote accepted

I have successfully gotten all the way through rm -rf --no-preserve-root / without the system crashing first, and without anything being left on the drive.

share|improve this answer
    
I ran srm on my data directories, then rm -rf --no-preserve-root / via SSH to cleanup the rest. It threw a couple errors in /dev ands then completed; I didn't quite know what to do at the bash prompt. Without a /bin/ls or /sbin/shutdown, I couldn't confirm success. Twas anticlimactic; I was mentally prepared for it to crash, not a zombie kernel and sshd session. –  notpeter Jul 23 '10 at 7:07

My solution involves a multi step approach doing some of the above, but also involving a chroot in ram that should allow dd to finish completely clearing the disk.

First delete all of your sensitive data, leaving necessary files for running the operating system. Then do this (not in a script, do it one command at a time):

mkdir /root/tmpfs/
mount -t tmpfs tmpfs /root/tmpfs/
debootstrap --variant=buildd --arch amd64 precise /root/tmpfs/
mkdir /root/tmpfs/mainroot
mount --bind / /root/tmpfs/mainroot
mount --bind /dev /root/tmpfs/dev
chroot /root/tmpfs/

# fill mainroot partition to wipe previously deleted data files
dd if=/dev/zero of=/mainroot/root/bigfile; rm /mainroot/root/bigfile
# now clobber the entire partition, probably won't be able to stay connected to ssh after starting this
# obviously change '/dev/md1' to the device that needs cleared
nohup dd if=/dev/zero of=/dev/md1 >/dev/null 2>&1

That should take care of it!

share|improve this answer

You could try to write random data on your disk like this :

dd if=/dev/urandom of=/dev/sda

Is safer than using /dev/zero because it write random data, but it's also A LOT slower..

share|improve this answer

Before you destroy the OS you could remove anything sensitive and zerofill (using dd if=/dev/zero of=justabigfile).

And I believe most systems will survive a dd to a running system long enough to overwrite the entire disk. There is no way back if it doesn't, of course.

share|improve this answer
    
If you delete all of the files you are concerned about before you do this, swapoff your swap partition, wipe the swap partition (using wipe or dd), then the above should be pretty safe. You'll need to do it as root to get past the 5% reserved for root, and you might not wipe all of the filenames, but the data should be gone. –  Slartibartfast Jul 12 '10 at 1:20

The CentOS installer (anaconda) that ships with the PXE images includes a VNC server, so you can alter your grub config to boot the CentOS installer, passing the answers to the pre-stage 2 installer questions on the grub line, reboot and then VNC to the installer.

Now, if my memory serves me correctly, from within that installer you should be able to drop to a shell, from which you can access and destroy the disk.

Copy the vmlinuz and initrd files from the PXE dir in the CentOS distro (http://mirror.centos.org/centos/5/os/i386/images/pxeboot/) to /boot and modify your grub config:

default 0
timeout 5
title CentOS
root (hd0,0)
kernel /boot/vmlinuz.cent.pxe vnc vncpassword=PASSWORD headless ip=IP netmask=255.255.255.0 gateway=GATEWAYIP dns=8.8.8.8 ksdevice=eth0 method=http://mirror.centos.org/centos/5/os/i386/ lang=en_US keymap=us
initrd /boot/initrd.img.cent.pxe

Incidentally, any decent hosting company should be prepared to destroy your disks for you.

share|improve this answer
1  
They aren't a 'decent hosting company' hence my need to leave and wipe my disks. –  notpeter Jul 12 '10 at 2:54
    
I didn't use this method, but using GRUB to boot a minimal rescue image that's preconfigured to enable vnc (or even just SSH) is totally doable. If you mess up, you're potentially left with a system that requires manual intervention to boot properly again, so probably worth testing in a VM first. –  notpeter Jul 19 '10 at 19:49

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.