D&C GLug - Home Page

[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]

Re: [LUG] CryptoLocker and Samba

 

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