Can I reliably use `dd` to wipe the root filesystem on a running Linux server?

2

I have a (physically) remote server I'd like to securely destroy. Unfortunately, the disk is partitioned with a single, large root partition and nothing else. Can I reliably use dd to wipe the device containing the root filesystem?

Something simple like:

$ sudo nohup dd if=/dev/urandom of=/dev/sda bs=1024

Obviously, I'll never see the output of the job, so I won't be able to verify that it completed successfully. The dd and nohup programs should be small enough and there's nothing else running on the server at this point, so there's no reason for those programs to be ejected from memory while they run. Will they run to completion, or will the kernel likely panic at some point before dd completes?

I'm contemplating other possibilities, but I'll ask about those in separate questions.

Christopher Schultz

Posted 2018-01-02T16:16:13.177

Reputation: 171

Answers

3

Yes, this is absolutely possible, but it requires some work.

Most of the answer is available on StackExchange, but I'll summarize here with links to the sources which have much more detail and deserve credit for excellent information.

  1. Build an in-memory base Linux environment and switch to it using pivot_root.
  2. Ensure you can access the server from the outside using ssh.
  3. Wipe the root device.

    # nohup dd if=/dev/urandom of=/dev/sda bs=512 > wipe.log &

  4. At intervals, feel free to check the progress of dd, since it doesn't usually give you any indication of progress.

    # kill -USR1 [ddpid]

  5. Come back later and verify the process has completed (check log file). Have a look at the disk to verify it's got random junk on it instead of a real filesystem. Wipe it a second (or third) time if you'd like.

  6. Decide what to do next.

    If you want, you can simply stop here and walk away. When the machine powers down, you'll have a non-bootable device that is as secure as you decide dd can make it.

    What I decided to do next is try something I haven't done before: build a Linux base system remotely. So I continued:

  7. Use fdisk to re-partition the root device as desired, and use mkfs to create filesystems on those partitions.

  8. Use debootstrap to install a base Debian environment on the (future) root filesystem.
  9. chroot to the new base environment, install additional packages (e.g. sshd) a kernel, and a bootloader (e.g. grub -- make sure the boot loader actually gets installed to the device -- don't just install the package).
  10. Use root_pivot to switch to the new environment in the same way you did in step #1 above. Bring-up all services (e.g. sshd) to ensure you'll be able to access the server e.g. through ssh.
  11. Reboot. Your fresh OS should be ready to go.

Christopher Schultz

Posted 2018-01-02T16:16:13.177

Reputation: 171

1

In an enterprise environment you would want to have some sort of Out-Of-Band Management like an IPMI, iDRAC, or other remote KVM solution. You would use that system to boot to a liveCD where the wipe could be performed and confirmed. If your goal is secure erase then you need to verify the operation. You can't just say "Well, that was supposed to work". Because even if it is supposed to work that doesn't mean that it did. Some IPMI systems allow you to remotely boot from an ISO that you have remotely. You could use something simple like a DBAN image.

HackSlash

Posted 2018-01-02T16:16:13.177

Reputation: 3 174

I've tried doing this with the OS booted and it failed. Doing it without the OS booted or with the OS running from a ramdisk seems to be the solution. Since you mentioned it is a server I assume out of band management is available making Hackslash's answer a good one. +1 – Hennes – 2018-01-02T19:19:52.950

Although appreciate your answer for its Truth, it doesn't really answer my actual question. – Christopher Schultz – 2018-01-02T19:49:24.483

Well Chris, the answer is that you can't be sure of what happens after the system goes down and you lose your remote connection. That answer is even less helpful. You have to assume that it failed if you can't confirm success. – HackSlash – 2018-01-02T19:52:51.140