2

Which is the best way to shred all data from a live dedicated server?

I have no physical access nor any out of band remote management functionality to the server, only SSH access.

Server is running Debian 6

Update

Server has ext3 partitions.

From shred man page:

   CAUTION:    Note  that  shred relies on a very important assumption: that
   the file system overwrites data in place.  This is the traditional  way
   to  do  things, but many modern file system designs do not satisfy this
   assumption.  The following are examples of file systems on which    shred
   is not effective, or is not guaranteed to be effective in all file sys-
   tem modes:

    

  • log-structured or journaled file systems, such as those supplied with
    • 



AIX and Solaris (and JFS, ReiserFS, XFS, Ext3, etc.)



    

  • compressed file systems
    • 



In  the    case  of  ext3 file systems, the above disclaimer applies (and
   shred is thus of limited    effectiveness)  only  in  data=journal  mode,
   which  journals    file  data  in addition to just metadata.  In both the
   data=ordered (default) and data=writeback modes, shred works as    usual.
   Ext3  journaling    modes  can  be  changed  by adding the data=something
   option to the mount  options  for  a  particular    file  system  in  the
   /etc/fstab file, as documented in the mount man page (man mount)

.

pl1nk
  • 481

4 Answers4

4

If for some reason you want to shred the ENTIRE disk instead of just the sensitive data while the system is running, the only way you will be able to do this for sure is by creating a tmpfs (or other ramdisk) mount, copying the core utilities to it, then using pivot_root to move the root filesystem to the ramdisk, then unmounting the partition to shred it as per Womble's answer here. Actually doing this is a challenge, I tried once to see if it's possible, and was able to get just about everything but init working from the ramdisk, but had trouble getting init to move its control pipe (/dev/initctl) so I could unmount the partition.

Alternatively, based on this answer you can try shutting everything that might try to write a log file down, kill everything else not necessary, use lsof to find processes with open files and kill them, then try shredding the partition. If you're lucky the process will complete before the kernel discovers the filesystem is corrupt and panics. If you're not, the kernel will panic, shred will stop, and the system will definitely be unbootable with no way to finish shredding.

Otherwise, if you just need to shred the data, then I think you can be reasonably sure of doing so if the journal is set to data=ordered or writeback per shred's manpage, then shred the existing datafiles (if it's not set to a supported mode, it looks like changing it requires a reboot). To shred the unallocated space where data files may have once existed, use dd to fill the drive with large files, then shred those as well. Note that this option may leave various bits of metadata (directory entries with filenames, ownership, filesizes, etc) intact. The dd process will need to be run as root in order to guarantee it fills the drive since (by default) space is reserved for root's use that can't be filled by a regular user. You may want to stop logging (or log to a separate partition or tmpfs) during this since problems will arise once the drive is completely full.

Community
  • 1
DerfK
  • 19,826
2

Assuming the server uses spinning disks, try the shred command.

Michael Hampton
  • 252,907
0

shred and srm are two commands you can use to securely delete data. Read their man pages for more info.

MichaelB
  • 541
0

Secure and Safe: Get secure and safe hard discs that encrypt the data.

Then instruct the disc to destroy the cryptographic key and make a new one.

Millisecond safe delete.

This is a standard option on most SAS discs these days.

TomTom
  • 52,109
  • 7
  • 59
  • 142