19

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 /

notpeter
  • 3,505
  • 1
  • 24
  • 44

8 Answers8

10

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.

upasaka
  • 1,365
  • 9
  • 6
  • 3
    They aren't a 'decent hosting company' hence my need to leave and wipe my disks. – notpeter Jul 12 '10 at 02: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
  • 1
    A word on the order in which things are wiped could be useful. By first wiping all partitions except the one containing `/boot`, you'd be able to start over in case the machine got rebooted in the middle of the process. If `/boot` happens to be on the `/` partition, one can delete all files outside of `/boot` and wipe the free space before finally wiping the entire partition. This would minimize the amount of data left on the disk in case it got rebooted once you had wiped so much, that you would no longer be able to boot it. – kasperd Mar 29 '15 at 09:46
8

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.

Joris
  • 5,939
  • 1
  • 15
  • 13
  • 5
    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 01:20
8

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!

moparisthebest
  • 99
  • 2
  • 4
5

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.

Fahad Sadah
  • 1,496
  • 11
  • 21
  • 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 07:07
  • 11
    This is not secure. The data is not wiped and undeletion is still possible. Better to `dd` over the disk instead. – qris Mar 31 '15 at 13:37
1

You can just use dd to overwrite the whole partition/disk on a running server without any worries. We use it at work a lot (when customer doesn't want to pay for secure physical disk destroy).

You actually wipe the data without mounted filesystem knowing it, so filesystem will begin to freak out as its metadata are being lost, then OS itself will begin to "collapse". However what is already in cache still works. So you can monitor the progress via remote console or KVM (didn't try it via ssh). System is kept running even after dd is finished, however no command will work and all daemons are probably already dead.

I use these commands: dd if=/dev/zero of=/dev/sda bs=1M & and then kill -HUP %1 to monitor the progress (dd will print out current speed and amount of data written). Setting block-size (bs) is very important for achieving the HDD seq write speed with dd.

Each time dd was able to wipe the disk to its end and I was able to issue the kill command (shell built-in) until the end. If you have software raid, you can wipe either the md device itself, or each component device individually.

Marki555
  • 1,488
  • 1
  • 14
  • 27
1

The ATA protocol has a "secure erase" command, which, as its name indicates, should securely wipe the entire HDD.

See the Kernel wiki article for details, but mind the warnings at the top:

https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase

Vladimir Panteleev
  • 1,705
  • 4
  • 20
  • 34
  • 2018 update: I've successfully used this on several occasions to remotely wipe servers, even as they're running off the filesystem being wiped. Since the program just issues an ATA command and waits for a response, no code needs to be executed on the CPU during the wipe process. – Vladimir Panteleev Jan 18 '18 at 18:05
0

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..

Kedare
  • 1,766
  • 4
  • 20
  • 36
  • As someone who doesn't know better, why are people down voting this? Is this not a good practice? – Canadian Luke Mar 30 '15 at 17:07
  • @CanadianLuke The question is about securely erasing an already running server. You can't write to a mounted drive like this, so it won't work. – longneck Mar 30 '15 at 18:39
  • @longneck Thanks. For some reason, I thought root could do that... Although I've never tried, so I'll take your word for it. Thanks for explaining though – Canadian Luke Mar 30 '15 at 18:40
  • @longneck ya you can, added the comment above but i had a really paranoid coworker do that. Actually you can completely unplug your hard drive and linux will still keep on running everything in memory without anything more than a bunch of application error messages. – Some Linux Nerd Apr 01 '15 at 00:17
0

Whatever you choose to do, get onto another provider and test it.

Get a similar instance on AWS (or gcloud or ...) and try it there, keeping the disk and then attaching it to another instance as additional storage and scanning it. dd if=sdb | hd

Just about all of your sensitive material should be in 

/home
/opt
/var
/etc
/usr

It is the config files with embedded passwords that bother most people. If you know what they are, search the whole filesystem to root them out.

rm will delete files, but a hex editor will still read the disk. So zero afterwards. Have a look at shred. You should have a log of your config files and where they are for DR purposes right ? Don't forget crontab files if you have passwords in those, say.

The CentOS install, or any ramdisk solution is sound. The kernel will be in memory, you need dd and some bin content. But if you reboot in recovery mode you may not have networking or SSH and cut yourself off.

N.B. Kedare has a good idea, and if you are running from ram on your next reboot (ramdisk) this is possible, it is very hard to recover from /dev/zero writes to begin with so it does not really add value unless your life depends upon it ?

mckenzm
  • 254
  • 2
  • 7