I have a client who was recently hit with a very new variant of Cryptolocker. Unfortunately the user who got hit had a high level of access to the system. Apparently there is no educating some people.

It occurs to me that it should be possible to mitigate damage if it were possible to make a copy of each file (eg onto SSD) whenever (but prior to) it being written, and delete these files out as they age overnight, but I do not know a way to do this.

Does anyone know of technical steps which can be taken on a Linux SAMBA server to mitigate Cryptolocker, and which does not rely on limiting user access or relying on AV. (Our AV software did not pick it up as the threat emerged only hours before the user was hit)

Putting data on an Logical Volume and taking regular snapshots has occurred to me, however I understand that snapshots have a huge penalty on performance which I'm hoping to avoid.


I have never been hit by one of these nasty cryptolocker variants, but short of having a backup of files, let it be via snapshots or some other method, is the only protection you can have.

Also whoever told you that the snapshots have a performance penalty, is not totally right. Yes, taking a snap shot takes away some resources, but depending of the size of your volume being snapshot, it might be negligibly small. It is hard to tell without knowing the size and nature of your data. But you have to have a way to backup those files, in case cryptolocker hits or hits again.

  • I found that write performance takes a dive (speeds slow to 20% when the snapshot is active) - and I'm not the only one - johnleach.co.uk/words/613/lvm-snapshot-performance and nikhef.nl/~dennisvd/lvmcrap.html – davidgo Feb 9 '16 at 18:18
  • I don't know what to tell you. It might happen in your case and some other anecdotal cases. When you do snapshots, it is normal to expect some sort of performance penalty. Again for how much and how long depends on your data, and using or not using it, depends on what your (users') pain threshold is, compared to the outcome of not doing this (i.e., total loss of data). Each case is unique. – MelBurslan Feb 9 '16 at 18:27

If LVM snapshots are not working for you, then you need to look into periodic (and possibly frequent backups), written to a location where malware does not have write-access. Then you would only have the LVM snapshot active long enough to take the backup.

Whether that means using Duplicity or borg-backup or rsync or rdiff-backup or rsnapshot, writing to an external USB drive or a server on the other end of a SSH connection, is up to you.

Personally, I prefer borg-backup, because it does:

  • De-duplication on variable-sized blocks
  • Compression
  • Works well over SSH
  • Creates a minimal number of files on the backup server
  • Is very fast after the initial backup

Borg is fast enough at creating incrementals, that I would consider creating an LVM snapshot of the source file system, backing it up with Borg, then removing the LVM snapshot. Depending on the amount of data and files being backed up that might be less then a minute or two per hour that the snapshot would be active.

Anecdote: Used to backup a 100GB MailDir-based mail server with rdiff-backup and it took 4-6 hours per day and created lots and lots of little files on the target file system. Using Attic (the predecessor to Borg) turned that into a 15-20 minute operation and created only a few hundred files on the target file system. So I'm no longer a fan of rsync-based backups due to the sheer number of files that gets created in the target directory.



As far as snapshotting goes, we are probably going to move towards ZFS which allows for much lower cost snapshots.

We also added the following lines to the appropriate shares which I believe offers some protection against some variants of cryptolocker by installing samba-vfs and backing up files which are deleted -

    vfs objects = recycle
    recycle:repository = .recycle
    recycle:keeptree = yes
    recycle:versions = yes

I have also found a post which goes into other mitigations - including turning on full auditing and using fail2ban to find common extensions used by cryptolocker renames to mitigate the threat.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.