[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 08/12/13 22:50, Rob Beard wrote: > Hi folks, > > With the recent outbreak of CryptoLocker it got me thinking a bit more > about backing up data and how to hopefully reduce the risk of losing data > if a machine got infected (which hopefully wouldn't happen, but I guess > it's one of those things that could accidentally be opened). > > I gather that CryptoLocker not only encrypts and deletes files on local > hard drives and USB sticks but also on shared network drives (not sure > about Cloud storage too like Dropbox etc that uses a special folder and > syncs data). > > Other than running daily backups of PCs and servers, I wondered if there > was anything at the filesystem level that could be done to say take regular > snapshots or backups which were then made read only (so any changes saved > were saved into a fresh copy)? > > I have briefly read up on Copy On Write on BTRFS and ZFS this weekend > (only very briefly though) and I wondered if this would be the solution. > Am I right in thinking if a file is changed, the original data is kept and > a copy is made with the changes so the original file always stays intact? > > What I'm thinking, is in the (hopefully unlikely) event that a machine did > get hit by CryptoLocker, if any files on network shares were deleted or > overwritten they would still be available on the file system to restore > from a previous time (say an hour earlier) so that the file could be easily > recovered (probably by an admin rather than end user). > > Rob > There's nothing here that won't be taken care of by your backups: presumably your backups aren't stored in any networked resource that a typical end user machine can even see, let alone mount and then get R/W permissions on. So in the case of Cryptolocker hitting your organisation, just grab the good files from backup and start worrying about your many, many other problems like bare metal restores and figuring out how it got in in the first place. If you've got Windows boxes then you can set roaming profiles to come from a Server 2012/2012r2 machine hosting them on the new ReFS filesystem, which is Microsoft's new CoW filesystem. Correct permission masks and snapshotting on the backend could natively guard against exactly the problem you're worried about, but still no better than your existing backups and at the cost of needing Server 2012/r2 (licences are expensive, as are the CALs to access them) plus some non-trivial admin configuration. If those shared network drive resources are instead being hosted on Linux boxes with Samba, then yes, BTRFS, ZFS or old-fashioned LVM snapshotting could also provide protection in pretty much the way you outline, but it would be a slightly strange approach. If you bear in mind that BTRFS just isn't stable, ZFS on Linux can be fiddly (and on heavily I/O-biased workloads requires insane hardware specs) and that your servers should all have LVM configured on their storage volumes already, the choice is clear if you want to experiment a bit. Snapshotting with CoW filesystems really wasn't designed to fix this specific problem, although it would accidentally fall within their remit I suppose. Don't forget that CoW snapshots work by calculating deltas between previous versions of files and the current on disk content - if something like Cryptolocker comes along and basically encrypts all user files then by definition those deltas are going to be massive and will chew through disk space like nothing on earth. People frequently don't realise what kind of filesystem overhead regular snapshotting will cause and will run out of disk space surprisingly quickly. You probably want to carry on with your backup routine and concentrate on making sure that stuff like Cryptolocker can't get into your network in the first place, and that users are well briefed. Regards -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq