On Sun, May 15, 2016 at 7:07 AM, Helmut Hullen <Hullen at t-online.de> wrote:> Hallo, ToddAndMargo, > > Du meintest am 15.05.16: > >> Is there anything in Samba that will help protect >> against ransomware? > > The linux principle is "one job - one tool". Antivirus software exists. > It doesn't help against really new malware, it doesn't help against > "social engineering", it doesn't help against a bona fide user.It was a basic UNIX principle, back in BSD when I first encountered it. It's not always followed: witness "systemd" and "gnome". Samba has some advantages. If the core file server is Linux or UNIX, it can be much faster and cheaper to make regular snapshots of your filesystem and write them to a basically read-only structure, running on Linux or UNIX. Much, much, much cheaper than trying to run Windows based backup software: just getting read access to "open" files, such as the user's mailbox files that are the most important files to back up on their whole system, be a nightmare requiring serious privilege escalation that the local users should *not* need to do. File system snapshot tools like LVM snapshots, or the more sophisticated snapshots of ZFS or of a backend NetApp, can also be invaluable. Those can also often be made accessible by Samba as read-only CIFS shares, for people to recover their own files. It's invaluable for people not to have to bother their local sysadmin to get last night's copy of the files they just accidentally deleted. They will appreciate your thoughtfulness, and you can get back to playing Minecraft. If you're on a budget tools like the venerable "rsnapshot" perl script, writing to cheap local storage, can provide similar capabilities with the added expense in resources of rsnapshot having to actually scan and rsync against the filesystems it is backing up, and having to be *very careful* to expose the backups as read-only. That exposure of backups can be via CIFS using Samba, or even via NFS. Since rsnapshot relies on hardlinks among the snapshots, if you corrupt one, you've potentially corrupted them all, and you *never* want to expose those backups to ordinary userland. Does Samba provide some subtle brilliance to block ransomware from being able to act at atll? Not really, no. The CIFS network file system for providing authorized access to data doesn't *analyze* the requests to read or write data to files for their legitimacy or lack of malice: that's a job for the client side, for the virus scanners or security on the client side. If Samba started trying to say "I smell a witch!!!" based on the transformation of data requested..... oh, dear lord, that could get very resource intensive and very, very messy.> Perhaps "ClamAV" may fulfill some of your wishes. > > Viele Gruesse! > HelmutThat's a related, but distinct, problem. ClamAV has limits: Constantly morphing attack binaries, and the use of encrypted zip files with "use this password" make such attacks more and more difficult to pre-analyze.
Am 20.05.2016 um 15:31 schrieb Nico Kadel-Garcia:> On Sun, May 15, 2016 at 7:07 AM, Helmut Hullen <Hullen at t-online.de> wrote: >> Hallo, ToddAndMargo, >> >> Du meintest am 15.05.16: >> >>> Is there anything in Samba that will help protect >>> against ransomware? >> >> The linux principle is "one job - one tool". Antivirus software exists. >> It doesn't help against really new malware, it doesn't help against >> "social engineering", it doesn't help against a bona fide user. > > It was a basic UNIX principle, back in BSD when I first encountered > it. It's not always followed: witness "systemd" and "gnome"please stop spreading that nonsense again and again there is no difference between having for each of the tools one upstream repository and different people working on different components or having a ton of isolated projects trying to work somehow together -rwxr-xr-x 1 root root 1,5M 2016-02-11 15:32 systemd -rwxr-xr-x 1 root root 16K 2016-02-11 15:32 systemd-ac-power -rwxr-xr-x 1 root root 53K 2016-02-11 15:32 systemd-activate -rwxr-xr-x 1 root root 98K 2016-02-11 15:32 systemd-backlight -rwxr-xr-x 1 root root 49K 2016-02-11 15:32 systemd-binfmt -rwxr-xr-x 1 root root 105K 2016-02-11 15:32 systemd-bootchart -rwxr-xr-x 1 root root 362K 2016-02-11 15:32 systemd-bus-proxyd -rwxr-xr-x 1 root root 277K 2016-02-11 15:32 systemd-cgroups-agent -rwxr-xr-x 1 root root 106K 2016-02-11 15:32 systemd-coredump -rwxr-xr-x 1 root root 93K 2016-02-11 15:32 systemd-cryptsetup -rwxr-xr-x 1 root root 110K 2016-02-11 15:32 systemd-export -rwxr-xr-x 1 root root 306K 2016-02-11 15:32 systemd-fsck -rwxr-xr-x 1 root root 33K 2016-02-11 15:32 systemd-hibernate-resume -rwxr-xr-x 1 root root 342K 2016-02-11 15:32 systemd-hostnamed -rwxr-xr-x 1 root root 122K 2016-02-11 15:32 systemd-import -rwxr-xr-x 1 root root 367K 2016-02-11 15:32 systemd-importd -rwxr-xr-x 1 root root 281K 2016-02-11 15:32 systemd-initctl -rwxr-xr-x 1 root root 309K 2016-02-11 15:32 systemd-journald -rwxr-xr-x 1 root root 354K 2016-02-11 15:32 systemd-localed -rwxr-xr-x 1 root root 639K 2016-02-11 15:32 systemd-logind -rwxr-xr-x 1 root root 485K 2016-02-11 15:32 systemd-machined -rwxr-xr-x 1 root root 41K 2016-02-11 15:32 systemd-machine-id-commit -rwxr-xr-x 1 root root 53K 2016-02-11 15:32 systemd-modules-load -rwxr-xr-x 1 root root 752K 2016-02-11 15:32 systemd-networkd -rwxr-xr-x 1 root root 126K 2016-02-11 15:32 systemd-networkd-wait-online -rwxr-xr-x 1 root root 204K 2016-02-11 15:32 systemd-pull -rwxr-xr-x 1 root root 37K 2016-02-11 15:32 systemd-quotacheck -rwxr-xr-x 1 root root 37K 2016-02-11 15:32 systemd-random-seed -rwxr-xr-x 1 root root 53K 2016-02-11 15:32 systemd-remount-fs -rwxr-xr-x 1 root root 33K 2016-02-11 15:32 systemd-reply-password -rwxr-xr-x 1 root root 505K 2016-02-11 15:32 systemd-resolved -rwxr-xr-x 1 root root 313K 2016-02-11 15:32 systemd-resolve-host -rwxr-xr-x 1 root root 73K 2016-02-11 15:32 systemd-rfkill -rwxr-xr-x 1 root root 143K 2016-02-11 15:32 systemd-shutdown -rwxr-xr-x 1 root root 73K 2016-02-11 15:32 systemd-sleep -rwxr-xr-x 1 root root 94K 2016-02-11 15:32 systemd-socket-proxyd -rwxr-xr-x 1 root root 57K 2016-02-11 15:32 systemd-sysctl -rwxr-xr-x 1 root root 343K 2016-02-11 15:32 systemd-timedated -rwxr-xr-x 1 root root 143K 2016-02-11 15:32 systemd-timesyncd -rwxr-xr-x 1 root root 446K 2016-02-11 15:32 systemd-udevd -rwxr-xr-x 1 root root 37K 2016-02-11 15:32 systemd-update-done -rwxr-xr-x 1 root root 281K 2016-02-11 15:32 systemd-update-utmp -rwxr-xr-x 1 root root 37K 2016-02-11 15:32 systemd-user-sessions -rwxr-xr-x 1 root root 45K 2016-02-11 15:32 systemd-vconsole-setup -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: <http://lists.samba.org/pipermail/samba/attachments/20160520/b3d2373c/signature.sig>
On 05/20/2016 06:31 AM, Nico Kadel-Garcia wrote:> Those can also > often be made accessible by Samba as read-only CIFS shares, for people > to recover their own files. It's invaluable for people not to have to > bother their local sysadmin to get last night's copy of the files they > just accidentally deleted. They will appreciate your thoughtfulness, > and you can get back to playing Minecraft.Hi Nico, That is actually brilliant idea. I have a Samba server coming up in a few weeks. I think I will implement that. Thank you! -T -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Computers are like air conditioners. They malfunction when you open windows ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ToddAndMargo <ToddAndMargo at zoho.com> writes:> On 05/20/2016 06:31 AM, Nico Kadel-Garcia wrote: >> Those can also >> often be made accessible by Samba as read-only CIFS shares, for people >> to recover their own files. It's invaluable for people not to have to >> bother their local sysadmin to get last night's copy of the files they >> just accidentally deleted. They will appreciate your thoughtfulness, >> and you can get back to playing Minecraft. > > Hi Nico, > > That is actually brilliant idea. I have a Samba server coming up > in a few weeks. I think I will implement that. Thank you!There are pros and cons to an easy recovery mechanism. Sure, at first it eases the life of the people who manage the system, but some users may start relying to heavily on the recovery service, in a way that becomes unhealthy, back-up being used as a secondary storage instead of being what it is meant to be: a back-up. That is why I rather beleive in a strong policy that defines what are the valid motives for restoration: crashes, etc. (reckless file deletion not being a valid one) and a loosy enforcement of the policy, and also having users jumps thought enough hoops so that they do not abuse the service. BR, Olivier