Home / server / Questions / 159401
Accepted
notpeter
Asked: 2010-07-12 09:52:04 +0800 CST

Securely wipe a headless remote linux server

  • 772

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 /

debian remote colocation secure-delete

8 Answers

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

    • 10

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

    • 8

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

    • 8
  4. Best Answer

    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.

    • 5

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

    • 1

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

    • 1

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

    • 0

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

    • 0