[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 08/12/2013 23:24, bad apple wrote:
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.
Fair enough, the machines are backed up daily and we're moving over to Roaming Profiles for most users.
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.
We currently don't use Windows server, all of our servers run Linux, although being a charity we do get a very big discount on Windows Server and Exchange, although there is the cost of getting a machine to run it hence why I'd like to do it on Samba.
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.
I was watching some interesting videos on BTRFS, I'll probably have a play with it when I have some time. But before that I'll check and double check the backups :-)
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.
Good point, although I don't think we have a great deal of data (probably in the gigabytes range rather than TB).
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.
Yep, our users are pretty savy, even if they're not very technical, if they get anything that looks suspicious they will flag it up, I figure it's probably better for them to flag up something innocent than blindly open it.
Rob -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq