Topic 'File Shredder for Network Drives' in forum 'Security' - dslreports.com

Re: File Shredder for Network Drives

Wed, 17 Apr 2013 02:18:10 EDT

salahx posted : Deleting free space using a remote filesystem (for Windows, that would be CIFS) in general can't work. A given share may only export part of volume, or a single share could be multiple volume stiched together via path mounts (like bind mounts under Linux), it could be a disk cluster, in fact the underlying share would even be another network filesystem (under Linux, re-exporting NFS shares to CIFS is a common trick), a disk cluster, or even a virtual filesystem (like FUSE) with no storage at all!

Access to the device at the block (disk) layer is needed: either by running directly from the host, or remotely via nbd, iSCSI or AoE (ATA over Ethernet).

Re: File Shredder for Network Drives

Tue, 16 Apr 2013 09:26:09 EDT

norwegian posted : »www.piriform.com/business/cclean···-edition

This also is a free space file erase.

Re: File Shredder for Network Drives

Tue, 16 Apr 2013 07:30:23 EDT

markmvps posted : Hello,

I want to recommend you Kernel File Shredder Tool which helps in permanently deleting the vital information or database records of organizations from the client’s network.

Re: File Shredder for Network Drives

Mon, 04 Feb 2013 16:38:22 EDT

angussf posted : This program claims to do it:

Delete Files Permanently Portable 5.0, 4.0, 3.3/3.2, Delete Files Permanently Portable 3.1, 3.0
»www.deletefilespermanently.com/h···New.html
... * you can wipe free space on network drives mapped by the drive letter.

No personal experience with it, and it's not freeware.

Re: File Shredder for Network Drives

Mon, 04 Feb 2013 14:16:02 EDT

dave posted :

You need more than standard file access. When you're accessing a network share you only have file level access.

I don't believe that to be the case. Here, for example, is how Russinovich's sdelete works:

said by sysinternals :
The second approach, and the one SDelete takes, is to indirectly overwrite free space. First, SDelete allocates the largest file it can. SDelete does this using non-cached file I/O so that the contents of the NT file system cache will not be thrown out and replaced with useless data associated with SDelete's space-hogging file. Because non-cached file I/O must be sector (512-byte) aligned, there might be some left over space that isn't allocated for the SDelete file even when SDelete cannot further grow the file. To grab any remaining space SDelete next allocates the largest cached file it can. For both of these files SDelete performs a secure overwrite, ensuring that all the disk space that was previously free becomes securely cleansed.

That's all normal file-access stuff. Non-cached writethrough I/O is a simple option in the CreateFile API (welll, two separate options, to be exact).

I'm not sure where the "don't do this over SMB" restriction arises. I think you could code it up reasonably well; maybe it's just related to being a good network citizen. NAS is typically shared (that's why SMB has "shares") and it's not nice to consume all of shared storage.

cipher /w operates in pretty much the same way.

The sysinternals writeup does present an alternative approach:

quote:
Cleaning free space presents another challenge. Since FAT and NTFS provide no means for an application to directly address free space, SDelete has one of two options. The first is that it can, like it does for compressed, sparse and encrypted files, open the disk for raw access and overwrite the free space. This approach suffers from a big problem: even if SDelete were coded to be fully capable of calculating the free space portions of NTFS and FAT drives (something that's not trivial), it would run the risk of collision with active file operations taking place on the system. For example, say SDelete determines that a cluster is free, and just at that moment the file system driver (FAT, NTFS) decides to allocate the cluster for a file that another application is modifying. The file system driver writes the new data to the cluster, and then SDelete comes along and overwrites the freshly written data: the file's new data is gone. The problem is even worse if the cluster is allocated for file system metadata since SDelete will corrupt the file system's on-disk structures.

In other words, an implementer would be nutty to attempt to do it like that.

Re: File Shredder for Network Drives

Mon, 04 Feb 2013 11:28:59 EDT

Kilroy posted : I'm not sure you can do this. There is a reason that you need to have the drives connected. You need more than standard file access. When you're accessing a network share you only have file level access.

I don't see being able to do this if the NAS doesn't have some security type setting and/or pulling the drive and connecting it locally.
--
�Progress isn't made by early risers. It's made by lazy men trying to find easier ways to do something.� � Robert A. Heinlein

Re: File Shredder for Network Drives

Mon, 04 Feb 2013 09:06:24 EDT

dave posted : What file system does this NAS use?

You need a program that runs on Windows, and supports the file system used on the NAS.

If it's a low-end consumer NAS, it's likely running Linux, Samba, and some Linux-supported file system.

Why's it matter? Because on some file systems, a honking great file of zeroes doesn't necessarily occupy any disk space ('sparse file support').

Can you get to the shell on this NAS? If so, perhaps there's a Linux utility you can use.

Re: File Shredder for Network Drives

Sun, 03 Feb 2013 23:45:52 EDT

bbear2 posted : Thanks for those points about speed. My situation is such that I only need to wipe the free space and won't be doing it that often, so 2 hours (or whatever) would be acceptable. Still frustrating that I can't find a simple solution as for direct attached.

Re: File Shredder for Network Drives

Sun, 03 Feb 2013 17:02:56 EDT

dave posted : I don't know of one, but it seems like it would have to be inefficient. The way a "wipe free space on file system" utility tends to work is to create a file that uses up the rest of the free space, write zeroes (or random patterns) into that file, and then delete the file.

So if you've got 500GB of freespace, that's 500GB of writing per pass. Assuming you have USB 3.0 (5 Gb/s) and a 1 Gb/s network, the network is the bottleneck even if you can drive it at full speed. So you're looking at about 2 hours per pass minimum.

If your router can't drive a gigabit connection at full speed, multiply accordingly. And at some point the USB connection is the bottleneck.

Re: File Shredder for Network Drives

Sun, 03 Feb 2013 16:35:33 EDT

bbear2 posted : I should have mentioned that the network drive is a USB drive connected off of a NAS router.

Re: File Shredder for Network Drives

Sun, 03 Feb 2013 08:17:37 EDT

Cudni posted : Also in
»Need Drive Wipe Util for Network Drive

Cudni

Re: File Shredder for Network Drives

Sun, 03 Feb 2013 08:03:45 EDT

therube posted : Maybe Using psExec to Open a Remote Command Window then running SDelete?

Even if it works, very possible that it could be quite a bit slower then running locally?

Might be worth testing both ways to see if one is particularly longer then the other?

File Shredder for Network Drives

Sat, 02 Feb 2013 23:45:39 EDT

bbear2 posted : Any recommendations for a utility that wipes free space from a network drive? Seems like all the file shredders I've tried only do direct attached drives.