Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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)

.

share|improve this question
    
possible duplicate of Securely Deleting Files on Linux Journaled Filesystem –  Michael Hampton Aug 9 '12 at 19:44
    
possibly duplicate of Securely wipe an entire Linux server with itself –  Stone Aug 9 '12 at 19:51
    
@MichaelHampton A part of the problem, nonetheless the OP has physical access to the Linux system. –  pl1nk Aug 9 '12 at 19:51
    
@Stone Well the referred question brings some interesting but still not seeing any "appropriate answer". –  pl1nk Aug 9 '12 at 19:59
1  
Why would you shred the filesystem, rather than the underlying block device, if you wanted to nuke all the data? Shred's caveats about journalled filesystems is only applicable if you want to shred files in a filesystem, rather than the whole thing. –  womble Aug 9 '12 at 23:42

4 Answers 4

up vote 1 down vote accepted

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.

share|improve this answer

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

share|improve this answer
    
Also assuming the files being shredded aren't on a copy-on-write filesystem. On the other hand, shredding the device directly won't care about the filesystem. –  Charles Aug 9 '12 at 19:35
    
The server has ext3 partitions, as attached in my question, shred is not effective against ext3 partition types --among others. –  pl1nk Aug 9 '12 at 19:46
    
In that case, your question is definitely a duplicate; see the referenced question. –  Michael Hampton Aug 9 '12 at 19:50
    
@MichaelHampton The OP has physical access to the system, quoted: ...I'm not worried about securing the drive when it's time is up; I can stick it in front of a huge magnent and toss it in a volcano if I need to... –  pl1nk Aug 9 '12 at 20:02
    
@pl1nk The other poster's ability to throw the drive in a volcano makes no difference to the accepted answer on the use of shred in ext3. –  DerfK Aug 9 '12 at 22:18

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

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.