samba - Jun 2017 - ransomware etc

On Wed, Jun 28, 2017 at 8:42 AM, David Disseldorp via samba
<samba at lists.samba.org> wrote:
> Hi,
>
> On Wed, 28 Jun 2017 11:08:11 +0200, mj via samba wrote:
>
>> Hi all,
>>
>> Just out of curiosity: is there anything we can do, on the samba side,
>> to counter the recent ransomware attacks? (or limit the damage done)
>>
>> I'm thinking like: limit the number of files per second a client
>> (workstation) is allowed to edit, or some other smart tricks..?
>>
>> It would be nice if samba could be an extra layer of defense.
>>
>> Something perhaps a vfs module could help with..?
>>
>> Anyone with tips, trics, ideas?
>
> Although not bullet proof, I'd suggest taking periodic snapshots of the
> Samba share using Btrfs, LVM, ZFS, etc. This will give you a read-only
> restore point, should clients start misbehaving.
>
> With Btrfs you could use the Snapper VFS module to expose the read-only
> snapshots to clients via the Windows Previous Versions UI.
Or, for oldsters like myself, rsnapshot reading from the current
filesystem. It's often much, much simpler to implement and lends
itself fell to finer tuning and restoration of old content than a
filesystem based backup.

29.06.2017 3:58, Nico Kadel-Garcia via samba пишет:
> Or, for oldsters like myself, rsnapshot reading from the current
> filesystem. It's often much, much simpler to implement and lends
> itself fell to finer tuning and restoration of old content than a
> filesystem based backup.
How often you are run rsnapshot ?
And what are you doing if files are broken, but rsnapshot backed it up 
already ?

-- 
Administrator

On Thu, Jun 29, 2017 at 12:23 AM, Mike Lykov via samba
<samba at lists.samba.org> wrote:
> 29.06.2017 3:58, Nico Kadel-Garcia via samba пишет:
>
>> Or, for oldsters like myself, rsnapshot reading from the current
>> filesystem. It's often much, much simpler to implement and lends
>> itself fell to finer tuning and restoration of old content than a
>> filesystem based backup.
>
>
> How often you are run rsnapshot ?
> And what are you doing if files are broken, but rsnapshot backed it up
> already ?
>
> --
> Administrator
How often to run it depends on your resources and requirements. For
many applications and environments, a nightly rsnapshot to a different
server or at least to a different disk, with the last week and month
exposed in read-only mode via Samba or NFS, is far more useful than
more complex filesystem based snapshots that require additional kernel
level resources and disk on the local working host. This is mostly
because the bigger risk to most working environments isn't ransomware.
It's "rm -rf" or accidentally selecting the wrong files or
directories
in a GUI.

The key to recovery with any backup system is *when* did the file
break., If it was broken after the rsnapshot, you have the old
snapshots to revert. That's part of the point of a backup system.

I've worked successfully with Samba and fielesystem based snapshot
systems, such as LVM (which only supports keeping one snspahost).
There are significant difficulties planning such snapshots for
databases: the schedule for them may not match when your database has
been completely written to disk. I've actually successfully used LVM
in collaboration with rsnapshot, to  pause a database, take an LVM
snapshot, and rsnapshot from *that. That's a very good time to
snapshot that database to another host and/or separate physical media
for rsnapshot or other less expensive backup systems. on different
physical media where it's less vulnerable to hardware or kernel
failures and much less vulnerable to "Bobby Tables"
https://xkcd.com/327/ .

More significantly powerful snapshotting systems, like NetApp's
multiple hourly or daily snapshots, do take significant resources from
the hosting storage system. In many cases it's serous system overkill.
You can spend the hardware budget on a backup host, or on external
drives elsewhere, to provide one of the key features of a backup
system. *Get it off the live server* onto different physical media.