1

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
  • 451
  • 5
  • 22
  • possible duplicate of [Securely Deleting Files on Linux Journaled Filesystem](http://serverfault.com/questions/70521/securely-deleting-files-on-linux-journaled-filesystem) – Michael Hampton Aug 09 '12 at 19:44
  • possibly duplicate of [Securely wipe an entire Linux server with itself](http://serverfault.com/questions/408614/securely-wipe-an-entire-linux-server-with-itself) – Stone Aug 09 '12 at 19:51
  • @MichaelHampton A part of the problem, nonetheless the OP has physical access to the Linux system. – pl1nk Aug 09 '12 at 19:51
  • @Stone Well the referred question brings some interesting but still not seeing any "appropriate answer". – pl1nk Aug 09 '12 at 19:59
  • There's nothing about the `shred` command or changing your journal type that can't be done remotely. – Michael Hampton Aug 09 '12 at 20:04
  • 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 09 '12 at 23:42
  • @womble How can I do this from a live system? I'm not familiar with shred that's why I asked. I would like to be 99.999999% sure that is going to work. – pl1nk Aug 10 '12 at 09:47
  • Good luck with that level of reliability, especially if you're not willing to test it beforehand. If you read the previous question Stone posted you already dismissed, you'll find an answer that will work quite effectively. – womble Aug 10 '12 at 10:03
  • You must take into consideration that pl1nk does not have physical access to the system: @pl1nk : You are referring to the OP, in your own question, please refer to them by their username. Also, you might want to contact provider hosting your server and ask them to do it for you. As, what you are asking is probably only going to work, with having physical access. – NeoH4x0r Apr 11 '14 at 10:23

4 Answers4

3

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,313
  • 2
  • 35
  • 51
2

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

Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
  • 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 09 '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 09 '12 at 19:46
  • In that case, your question is definitely a duplicate; see the referenced question. – Michael Hampton Aug 09 '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 09 '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 09 '12 at 22:18
  • @DerfK so shred /dev/xxx would suffice to shred the all the data from the hardisk, while the system is running? – pl1nk Aug 10 '12 at 09:56
  • @pl1nk probably not, but if you remount the drive with the journal off or not in data mode, you could shred the sensitive data files (ie not executables), then `dd if=/dev/zero of=/somefile bs=1M` to fill all the unallocated space that may have once had sensitive data in it, then `shred /somefile`. If it's an enormous filesystem you may hit max filesize and have to use multiple files to fill the drive completely. – DerfK Aug 10 '12 at 12:48
  • @DerfK I see.. I don't know what is the problem with my question, do I need to describe more clearly that I want to shred all the data while server is running? – pl1nk Aug 10 '12 at 13:14
  • @pl1nk The answer to your question is "no". If you try to shred a live partition, the kernel will panic as soon as it reads or writes to the filesystem and discovers that it is corrupt, and your shred will stop. As in the other questions cited you might get away with it by creating a tmpfs chroot and using `pivot_root` so you can unmount the partition, or shut everything you can down and pray that nothing tries to open a file. My idea is a third workaround by shredding the individual data files then the empty space, but it assumes that you don't have to shred the system executables. – DerfK Aug 10 '12 at 14:46
0

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

MichaelB
  • 531
  • 4
  • 10
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
  • 50,857
  • 7
  • 52
  • 134