21

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.

mgorven
  • 30,036
  • 7
  • 76
  • 121
cat pants
  • 2,139
  • 10
  • 33
  • 44
  • 3
    Try it ;) Eventually in a VM first. – Frederik Jul 17 '12 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 '12 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 '12 at 19:23
  • Pure speculation: I wonder if `chroot`ing into a RAMdisk may help with this. Second speculation: partition a part of the drive, rewrite grub, and reboot. – Hyppy Jul 17 '12 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. – Mike Pennington Jul 18 '12 at 22:20
  • Use `pv` to do progressbar, like: `dd if=/dev/zero | pv | dd of=/dev/sda` – Stone Jul 20 '12 at 18:01
  • And for your new system: put all of your private data plus the swapspace onto encrypted partitions. Saves you from later headaches. – ott-- Jul 20 '12 at 18:17

3 Answers3

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.

womble
  • 95,029
  • 29
  • 173
  • 228
  • 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 '12 at 00: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].

pQd
  • 29,561
  • 5
  • 64
  • 106
  • 1
    A single pass with /dev/zero wouldn't be very secure depending on how secure the OP needs it. – Aaron Copley Jul 17 '12 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 '12 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 '12 at 19:36
  • @Copley sure - if we're talking about more formal requirements - shred is a more suitable tool. but if author does not have a physical access - it's an illusion of security really. – pQd Jul 17 '12 at 19:40
  • 2
    I was under the impression that needing more than one pass is a common misconception. http://www.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 '12 at 21:38
  • 1
    @cjc I do not have specific data or partitions in mind, basically just need to do a single pass on the entire disk. The security requirements are my own, so no help is needed there. My goal with this question is simply to learn a specific answer to this specific problem with the defined parameters. Google was unable to reveal anything so far! Basically, looking for just a one liner system wipe. :) Make the assumption I have only /dev/sda. – cat pants Jul 17 '12 at 21:43
  • I think at this point, I just need a command that ensures that all important standard libraries + kernel + (*my knowledge lacking*) are loaded in memory before executing "dd if=/dev/zero of=/dev/sda" so that I don't get a kernel panic when executing said command. Does that sound right? (I was sure to turn swap off, would that even matter though? :P ) – cat pants Jul 17 '12 at 21:46
  • 4
    @catpants: Lock the necessary files into memory with [vmtouch](http://hoytech.com/vmtouch/) then run whatever you need. – womble Jul 17 '12 at 22:55
  • 1
    @catpants Try remounting the root filesystem read-only first. – mgorven Jul 17 '12 at 23:05
  • @mgorven Sounds good, but then how do I nuke the root filesystem? :) (Wiping the root filesystem is probably not needed, but I am just curious as to how to keep everything in RAM and do it that way) – cat pants Jul 18 '12 at 00:16
  • @catpants The same as pQd suggested; remounting it read-only may prevent the kernel panic. – mgorven Jul 18 '12 at 00:39
  • 1
    @mgorven Ok, very stupid question: How do I remount the root filesystem as read only without getting "mount: / is busy"? Thanks! – cat pants Jul 18 '12 at 18:20
  • @catpants mount -o remount,ro / – mgorven Jul 18 '12 at 19:02
  • 1
    @mgorven sorry, should have said "mount -o remount,ro /" is the command that gives me "mount: / is busy" (open files probably, how to easily kill them all?) – cat pants Jul 18 '12 at 21:18
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.

Paul Gear
  • 3,938
  • 15
  • 36