22

I have remote ssh access and root access. I do not have physical access. I'm not looking for solutions involving booting into anything, I want to do this from what is currently running.

OS is SL6. Is there a way to load everything needed into RAM, and use dd or similar to securely wipe the entire disk? Obviously this will result in a non-functioning box in the end, my intended result.

It seems like this should be possible.

Two more interesting additions:

  1. Be able to ssh in, run screen, run the dd command and detach. Log in a week later once it has finished. :)

  2. Somehow have a progress bar?

Update: I am now going with the chroot option. Currently doing:

mkdir /dev/shm/ramdisk/ && cd ramdisk && mkdir bin lib64 && cd /lib64 && cp ld-linux-x86-64.so.2 libc.so.6 libdl.so.2 libpthread.so.0 librt.so.1 libtinfo.so.5 /dev/shm/ramdisk/lib64 && cd /bin && cp bash dd /dev/shm/ramdisk/bin && cd /dev/shm/ramdisk && chroot .

Which works(!) but I still need /dev/zero and /dev/sda. Any ideas there?

Update 2012-07-20:

mkdir /dev/shm/ramdisk/ && cd /dev/shm/ramdisk && mkdir bin lib64 && cd /lib64 && cp ld-linux-x86-64.so.2 libc.so.6 libdl.so.2 libpthread.so.0 librt.so.1 libtinfo.so.5 /dev/shm/ramdisk/lib64 && cd /bin && cp bash dd /dev/shm/ramdisk/bin && mkdir /dev/shm/ramdisk/dev && cd /dev/shm/ramdisk/dev && cp -a /dev/zero . && cp -a /dev/sda . && cd .. && chroot . dd if=/dev/zero of=/dev/sda bs=1M

Which appears to be doing something, but I would like to have some sort of progress indicator if possible, as well as a way to detach and then establish a new ssh connection later.

7
  • 3
    Try it ;) Eventually in a VM first.
    – Frederik
    Jul 17, 2012 at 19:16
  • 2
    When you say booting is not an option, are you saying that touching the console/inserting media is not an option, or that the machine cannot be rebooted at all? Because you potentially could add a livecd image on your disk. When the system reboots it boots the livecd image, loads to memory and starts an SSH server.
    – Zoredache
    Jul 17, 2012 at 19:18
  • Indeed, I have no physical access. At any rate, I am aware of the live cd solution, so I am interested in learning another solution, specifically with the conditions posed in this problem. Thanks!!
    – cat pants
    Jul 17, 2012 at 19:23
  • Pure speculation: I wonder if chrooting into a RAMdisk may help with this. Second speculation: partition a part of the drive, rewrite grub, and reboot.
    – Hyppy
    Jul 17, 2012 at 19:47
  • There is only one secure option, if data confidentiality is truly a concern: you must destroy the disk. Normal options are: 1) degausser, 2) disk sander, 3) ball peen hammer. If you can reboot, then there is an option to run some DoD-level disk-wipe tools but you have eliminated reboots as an option. Jul 18, 2012 at 22:20

3 Answers 3

12

Create an image in a ramdisk containing whatever tools you require to nuke the system, then pivot_root into it, run the tool, away you go. Pivoting out of a full system isn't trivial, but it can be done if you know what you're doing.

1
  • 1
    That's a cool idea. So the question then becomes: what is the bare minimum for me to throw into a ram disk to be able to accomplish this? Let me try and figure that out on my own, then I will either comment on here or post a new thread if I can't figure it out. Thanks!
    – cat pants
    Jul 18, 2012 at 0:19
9

i've done it few times executing

dd if=/dev/zero of=/dev/sda

no additional preparations. it worked. system was running fine for days after dd finished [responding to pings, forwarding packets].

14
  • 2
    A single pass with /dev/zero wouldn't be very secure depending on how secure the OP needs it. Jul 17, 2012 at 19:24
  • 1
    Just tried this, and the result was a kernel panic. I have about ten more machines I can try this on though. What should I try next?
    – cat pants
    Jul 17, 2012 at 19:25
  • 2
    Do you have specific partitions with confidential data? You can try sandblasting those first before doing anything that may take down the box.
    – cjc
    Jul 17, 2012 at 19:36
  • 2
    I was under the impression that needing more than one pass is a common misconception. anti-forensics.com/disk-wiping-one-pass-is-enough I believe that there is a challenge to recover data after a single pass with /dev/zero, and so far no one has been able to do it.
    – cat pants
    Jul 17, 2012 at 21:38
  • 4
    @catpants: Lock the necessary files into memory with vmtouch then run whatever you need.
    – womble
    Jul 17, 2012 at 22:55
0

Suggestion: use wipe rather than dd - it supports multi-pass secure wiping.

Another suggestion: stop as many services and delete as many packages as possible. Delete every piece of data that you don't need, and all of your old log files and data. Fill as much as possible of the resultant free space with a single file, then run wipe on that file. Don't delete that file. That will take care of wiping most of the disk before you make the system unusable.

The chroot ramdisk idea would then be necessary to get you past any dramas with getting back into the box, but you'll probably want to quiesce the system as much as possible before doing the final wipe, because logging and other daemons that write to disk could mean that real data is written to free data blocks while the wipe is happening, before the filesystem structure is fully corrupted.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .