Hi,
I need to securely wipe out a disk on a remote machine, but I don't have access to that machine. Therefore I cannot use the LiveCD+shred (or dd) combination. Besides manually shreding known data files, I am wondering if there is a (free) tool that can be used in my case. Thanks.
On 01/08/2013 05:06 PM, Yungwei Chen wrote:
I need to securely wipe out a disk on a remote machine, but I don't have access to that machine. Therefore I cannot use the LiveCD+shred (or dd) combination. Besides manually shreding known data files, I am wondering if there is a (free) tool that can be used in my case. Thanks.
I hoping that you mean to physical access but you can make an ssh connection. If so, here are the steps. Note that you'll need to replace /dev/sdXX with the device of your swap part- ition and /dev/sdX with the device of the hard drive. It will run for several hours and leave you with a blank hard drive.
1) connect using ssh and stop all services 2) swapoff /dev/sdXX 3) shred -n5 -z -v /dev/sdX 4) echo 1 > /proc/sys/kernel/sysrq 6) echo o > /proc/sysrq-trigger
c
Thanks. Is it possible that shred exit abnormally in any case (for example, some files that it relies on have been shreded)?
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Carl T. Miller Sent: Tuesday, January 08, 2013 4:36 PM To: CentOS mailing list Subject: Re: [CentOS] wiping out data on a disk (no physical acess to the machine)
On 01/08/2013 05:06 PM, Yungwei Chen wrote:
I need to securely wipe out a disk on a remote machine, but I don't have access to that machine. Therefore I cannot use the LiveCD+shred (or dd) combination. Besides manually shreding known data files, I am wondering if there is a (free) tool that can be used in my case. Thanks.
I hoping that you mean to physical access but you can make an ssh connection. If so, here are the steps. Note that you'll need to replace /dev/sdXX with the device of your swap part- ition and /dev/sdX with the device of the hard drive. It will run for several hours and leave you with a blank hard drive.
1) connect using ssh and stop all services 2) swapoff /dev/sdXX 3) shred -n5 -z -v /dev/sdX 4) echo 1 > /proc/sys/kernel/sysrq 6) echo o > /proc/sysrq-trigger
c
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Tue, 8 Jan 2013 18:57:03 -0500 Yungwei Chen wrote:
Thanks. Is it possible that shred exit abnormally in any case (for example, some files that it relies on have been shreded)?
Without physical access to the machine so you can see (and control) what is actually going on, there is no way to 100% guarantee that the data is completely destroyed.
Many things could theoretically cause the process to end before completion, including someone on the other end simply disconnecting the power.
If it absolutely has to be destroyed, then the only completely reliable way is to physically take control of the machine and carry on from there.
Thanks. Is it possible that shred exit abnormally in any case (for example, some files that it relies on have been shreded)?
Without physical access to the machine so you can see (and control) what is actually going on, there is no way to 100% guarantee that the data is completely destroyed.
If you had some disk space could you create a partition and install a minimalistic Linux version, set your system to boot the minimalistic Linux version, log in and completely destroy any partition you want and you could just leave the minimalistic Linux version.
Ken godee wrote:
Thanks. Is it possible that shred exit abnormally in any case (for example, some files that it relies on have been shreded)?
Without physical access to the machine so you can see (and control) what is actually going on, there is no way to 100% guarantee that the data is completely destroyed.
If you had some disk space could you create a partition and install a minimalistic Linux version, set your system to boot the minimalistic Linux version, log in and completely destroy any partition you want and you could just leave the minimalistic Linux version.
Dumb question: why can't you have whoever has the drive pull it and ship it to you?
mark
On 01/08/2013 02:36 PM, Carl T. Miller wrote:
- connect using ssh and stop all services
- swapoff /dev/sdXX
- shred -n5 -z -v /dev/sdX
I assume that all of the disks are to be shredded. Shredding non-system disks wouldn't be difficult enough to ask about. If you shred a mounted filesystem, the kernel will probably panic if it tries to read from the filesystem after shred starts overwriting data.
- echo 1 > /proc/sys/kernel/sysrq
- echo o > /proc/sysrq-trigger
You wouldn't be able to do that once shred had run.
On 01/12/2013 07:03 PM, Gordon Messmer wrote:
On 01/08/2013 02:36 PM, Carl T. Miller wrote:
- connect using ssh and stop all services
- swapoff /dev/sdXX
- shred -n5 -z -v /dev/sdX
I assume that all of the disks are to be shredded. Shredding non-system disks wouldn't be difficult enough to ask about. If you shred a mounted filesystem, the kernel will probably panic if it tries to read from the filesystem after shred starts overwriting data.
- echo 1> /proc/sys/kernel/sysrq
- echo o> /proc/sysrq-trigger
You wouldn't be able to do that once shred had run.
Hmm. I find it odd that you're saying something doesn't work when I've seen it work. Don't forget shred is loaded into memory and that echo is an internal command and hence stored in memory. The final command turns off the system, effectively clearing the memory.
c
On 01/13/2013 05:10 AM, Carl T. Miller wrote:
Hmm. I find it odd that you're saying something doesn't work when I've seen it work. Don't forget shred is loaded into memory and that echo is an internal command and hence stored in memory. The final command turns off the system, effectively clearing the memory.
Well, it won't work reliably. If the kernel tries to read the filesystem, it's going to panic (which I've also seen; your anecdote does not prove the process to be reliable). Even *fixing* a broken filesystem while it's mounted can cause a panic. Try running fsck on a mounted filesystem (even one mounted read-only). You'll be warned not to do that for a reason.
On 01/08/2013 02:06 PM, Yungwei Chen wrote:
I need to securely wipe out a disk on a remote machine, but I don't have access to that machine. Therefore I cannot use the LiveCD+shred (or dd) combination.
If you have enough RAM to hold the live disk, you can boot the whole thing from grub, probably using memdisk. If you boot a live image with memdisk, you can safely wipe the hard disks without the running kernel crashing.
On Sat, Jan 12, 2013 at 7:05 PM, Gordon Messmer yinyang@eburg.com wrote:
On 01/08/2013 02:06 PM, Yungwei Chen wrote:
I need to securely wipe out a disk on a remote machine, but I don't have access to that machine. Therefore I cannot use the LiveCD+shred (or dd) combination.
If you have enough RAM to hold the live disk, you can boot the whole thing from grub, probably using memdisk. If you boot a live image with memdisk, you can safely wipe the hard disks without the running kernel crashing.
at $long_ago_job we'd use a pxe-netboot image; effectively DBAN (http://www.dban.org/). which only really works if you have another server in the remote location to act as the pxe server. maybe if you were really playful (and had throw away hardware to try it on) you could figure a way to extract the dban iso into the boot partition of the remote machine, do a reboot and let it go?
about all I can think of.
On 01/12/2013 04:33 PM, zGreenfelder wrote:
at $long_ago_job we'd use a pxe-netboot image; effectively DBAN (http://www.dban.org/). which only really works if you have another server in the remote location to act as the pxe server.
Anything that you can PXE boot, you should also be able to load from GRUB.
http://ralintech.blogspot.com/2011/02/remote-wipe-with-dban.html
If DBAN features SSH, this would work. I assume that it does, since the blog is specifically about remotely wiping a system.
On Sat, Jan 12, 2013 at 8:36 PM, Gordon Messmer yinyang@eburg.com wrote:
On 01/12/2013 04:33 PM, zGreenfelder wrote:
at $long_ago_job we'd use a pxe-netboot image; effectively DBAN (http://www.dban.org/). which only really works if you have another server in the remote location to act as the pxe server.
Anything that you can PXE boot, you should also be able to load from GRUB.
http://ralintech.blogspot.com/2011/02/remote-wipe-with-dban.html
If the OP has a BMC/ILO in his server, he could set the next boot device to a PXE server he controls. Then issue a reboot via serial over LAN and it can boot whatever live Linux image (benefit being SSH is available) and shred from there. DBAN is nice as it is/can be automated, but it may not be a suitable solution for this situation. The OP will not have any SSH access with DBAN nor access to the console (I'm thinking serial over LAN) because DBAN does not likely output to a serial port.
If DBAN features SSH, this would work. I assume that it does, since the blog is specifically about remotely wiping a system.
To the best of my knowledge DBAN has not had SSH support added. The original/primary developer no longer works on the project.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-
Carl T. Miller -
Frank Cox -
Gordon Messmer -
Ken godee -
m.roth＠5-cent.us -
SilverTip257 -
Yungwei Chen -
zGreenfelder