Ransomware resistance


RobJ

Recommended Posts

Here's a thought I just had. What if all shares are read only, except the cache disk. Throughout the course of the day, files would be written to cache as usual. At some predetermined time (say 3am), unRAID kills the network connection, sets the shares to writeable, and the mover does its thing. Once the transfer is complete, the shares are changed back to read only, and the network connection is restored. This would safeguard data on the server in the event of another PC on the network becoming infected.

 

The problem with this would be modifying existing files.

 

Let's say you open a word doc on your read-only share. Modify it and save it to this cache share. Now you want to open it again, which one does it open?

 

The idea is great, but I dont think it's practical.

 

 

What I'd suggest is a background service that watches files being written and if it see's these weird extensions .crypt or whatever kills network sharing and sends out a notification to investigate. While this won't prevent ransomware (which I think is not possible for unraid while maintaining usability) it will most certainly minimize the damage.

Link to comment

Here's a thought I just had. What if all shares are read only, except the cache disk. Throughout the course of the day, files would be written to cache as usual. At some predetermined time (say 3am), unRAID kills the network connection, sets the shares to writeable, and the mover does its thing. Once the transfer is complete, the shares are changed back to read only, and the network connection is restored. This would safeguard data on the server in the event of another PC on the network becoming infected.

The mover does not use smb or nfs shares. It writes directly to the shares mounted in unraid.

 

Ransomware is a threat through exported shares via smb or nfs.

 

Lock down share exports and you'll be good to go

Link to comment

Just came across this thread and I haven't read most of it so I don't know if this has been addressed yet.

 

The way I mitigate Ransomeware with my PC backups is to create a different user who can access the backup shares but my own personal user can't. My backup tool uses that user to authenticate against the shares to do the backups.

 

Concerning other files on the NAS, the only option I can see is to have a 2nd server for backing up your primary server which you do not have any drive mappings to and preferably, only on while performing backups of your main server.

Link to comment
  • 3 months later...

Anyone tried this:

 

https://ransomfree.cybereason.com/

 

Free and supposed to stop 99% of ransomware strains.

 

For Windows only, but it's something to keep an eye on.  Apparently, there's a new version coming out in a few weeks (mid January 2017), that should address some of the issues that have been found.  It's free (always interesting), and does seem very good at dealing with *some* of the ransomware families, but everyone seems to feel there's no one piece of anti-ransomware software that deals with all ransomware variants.  In particular, RansomFree doesn't yet handle MBR infecting types like Petya.

 

What's also interesting is that it seems to take a honeypot approach like Squid's anti-ransomware plugin, dropping lots of files around the drive.

 

It does appear to use very limited resources, low CPU usage.  And they claim high expertise, military offensive cyber-warfare experience.  They also claim they want to keep this free.  We'll see.  MalwareBytes 3.0 is coming out soon, with anti-ransomware protection, but a rather high price!

Link to comment
  • 4 months later...

I've been giving this problem some thought, and did some experimenting. If you set a file to read-only permissions (chmod 444 file.ext), and set it to an owner other than your own userid (e.g., root), that file cannot be deleted or written to from a Windows box via SMB, no matter the share settings. I tested with the DOS/Windows "attrib -R" command, and it was unable to make the file writable (if the owner is me, attrib WOULD make the file writable). I believe that no virus operating through SMP, AFS, NFS, or other sharing protocols would be able to alter a file set to read-only. If true, this would make the files read-only for user shares as well as disk shares. (This is my theory - and very interested if others believe there is a way I have not thought of short of hacking into unRAID and getting to an SSH command line.)

 

If true, seems a good and convenient practice for those using rippers/converters or downloaders with post processing, to post process media files to set them up like this. Meta-data, resume files, movie posters, fan-art, etc can all continue to be left read/write so that can be written to, overwritten, deleted, etc as they were designed. They would be vulnerable to attack. But if the big media file survives, the rest is trivial to recreate with modern tools. In this mode the shares are always writable for new files. A nice side effect is that this protects you, albeit not quite so securely, from your #1 threat for data loss. Yourself! It is much harder to accidentally delete a read-only file!

 

Once a big media file is written to its final home, it is infrequent to have to alter it. Unlike shares themselves that might need frequent flipping to do what is needed, the individual files can be made readonly seemingly forever.

 

If needed, the unRAID newperms script could quickly reset the file permissions on a file, folder, user share, or drive level through ssh or a plugin. And it wouldn't be hard to write a Linux one-liner that would mark all files with a certain extension or over a certain filesize as read-only. This would allow one to do a bunch of rearranging and reapply the read only settings when done.

 

This would likely work for many people's moves, tv shows, photo/image collections, PDF libraries, ISO images, ZIP files, music files, and long term backup files.

 

It would not work well for everyday word and excel documents that are frequently edited. But this is not what most of us use our servers for.

 

Thoughts?

  • Upvote 4
Link to comment

I like it. I think I'm going to do exactly that on my media shares for any file larger than 100 Megs (or whatever size is just a bit larger than the trailers videos).

 

I might start off with the scripts for the Accelerator Drives but invert the checks and change out the action so it operates on the large files instead.

  • Upvote 1
Link to comment
1 hour ago, BRiT said:

I like it. I think I'm going to do exactly that on my media shares for any file larger than 100 Megs (or whatever size is just a bit larger than the trailers videos).

 

I might start off with the scripts for the Accelerator Drives but invert the checks and change out the action so it operates on the large files instead.

 

I like the application to files larger than xx bytes in size.  Any idea on command line for such?  a chmod -R | grep something about file size?  (My bash knowledge is sorely lacking!)

Link to comment
32 minutes ago, bman said:

 

I like the application to files larger than xx bytes in size.  Any idea on command line for such?  a chmod -R | grep something about file size?  (My bash knowledge is sorely lacking!)

 

A good starting point would be from @NAS s post in the Accelerator Drives thread. I would start with a "find" command and piped to exec.

 

The -ls parameter does a file listing of the results.

 

So to find all the files larger than 10 Megs in size and give a listing:

find /mnt/user/Media/ -type f -size +10M -ls

 

To find files smaller than 10 Megs in size and give a listing:

find /mnt/user/Media/ -type f -size -10M -ls

 

Other units available for size is 'k' for Kilobytes, 'c' for bytes, 'M' for Megabytes, and 'G' for Gigabytes.

 

 

To change permissions to READ only for files larger than 10 Megs in size:

find /mnt/user/Media/ -type f -size +10M -exec chmod 444 {} \;

 

Then to change owner to ROOT for files larger than 10 Megs in size:

find /mnt/user/Media/ -type f -size +10M -exec chown root {} \;

Edited by BRiT
  • Upvote 2
Link to comment

Oooh, good call BRiT.  I'll start playing around with that. This could prove useful at work where I use unRAID for video archives. Lots of students using all sorts of computers and OS's doing who knows what, and some of them have brief access to the primary archive server to drop on their newly-finished masterpieces.  If all the previous works were root-owned and RO that could potentially save days of rsyncing from the backup server if something unsavoury happened.

 

Cheers!

  • Upvote 1
Link to comment
  • 5 months later...
On 16.5.2017 at 3:56 AM, BRiT said:

So to find all the files larger than 10 Megs in size and give a listing:

find /mnt/user/Media/ -type f -size +10M -ls

 

To find files smaller than 10 Megs in size and give a listing:

find /mnt/user/Media/ -type f -size -10M -ls

 

Other units available for size is 'k' for Kilobytes, 'c' for bytes, 'M' for Megabytes, and 'G' for Gigabytes.

 

To change permissions to READ only for files larger than 10 Megs in size:

find /mnt/user/Media/ -type f -size +10M -exec chmod 444 {} \;

 

Then to change owner to ROOT for files larger than 10 Megs in size:

find /mnt/user/Media/ -type f -size +10M -exec chown root {} \;

Oh, nice! 
Need to add this to a schedule in the user scripts plugin. Changing permissions every monday night on my movies and locking them down.. 

B|

Link to comment

Hmm. I am sure I missed something, but can't figure out what. 
Way too long since I was active on unraid.. :$

 

Tried to applying the commands, but I still can delete the files from windows..

I removed the size part since I want to "lock" down my srt files too. 

find /mnt/user/Movies/ -type f -exec chmod 444 "{}" \;
find /mnt/user/Movies/ -type f -exec chown root "{}" \;

 

ls -l "Forrest Gump (1994)"
total 11465972
-r--r--r-- 1 root users      121133 Feb 14  2016 Forrest\ Gump\ (1994).english.srt
-r--r--r-- 1 root users 11740930048 Feb 14  2016 Forrest\ Gump\ (1994).mkv
-r--r--r-- 1 root users       98793 Feb 14  2016 Forrest\ Gump\ (1994).norweigan.srt

 

Link to comment
On 8/31/2016 at 5:12 PM, aptalca said:

The mover does not use smb or nfs shares. It writes directly to the shares mounted in unraid.

 

Ransomware is a threat through exported shares via smb or nfs.

 

Lock down share exports and you'll be good to go

I traditionally keep file server shares read-only with the exception of accesses from a few trusted Linux machines.

 

So to move files from a Windows machine I have the file server mount the Windows volume and pull the files. Or I use an intermediary Linux machine that mounts both the Windows share and the file server share.

 

But in the end, there are no open shares for a hijacked Windows machine to destroy.

 

If editing a word document, the Windows machine has to create a new revision of the document, and rsync may later come and fetch the new revision and store on the read-only share.

Link to comment
11 hours ago, pwm said:

You have now write-protected the files, i.e. blocked programs from changing them.

 

You also want to write-protect the directories, to block programs from deleting files.

Thanks, now I can't delete the files from windows browser. 
Then my folder and files look like this.

root@Tower:/mnt/user/Movies# ls -l
dr--r--r-- 1 root        users 117 Nov 18 23:06 Forrest\ Gump\ (1994)/

root@Tower:/mnt/user/Movies/Forrest Gump (1994)# ls -l
total 11465972
-r--r--r-- 1 root users      121133 Feb 14  2016 Forrest\ Gump\ (1994).english.srt
-r--r--r-- 1 root users 11740930048 Feb 14  2016 Forrest\ Gump\ (1994).mkv
-r--r--r-- 1 root users       98793 Nov 19 10:59 Forrest\ Gump\ (1994).norweigan.srt

 

Tried opening a file in windows notepad and I can't edit the file, but if I go into Notepad++ and select "Clear Read-Only Flag" I can edit the file again.

Anyone has any tips? 

root@Tower:/mnt/user/Movies/Forrest Gump (1994)# ls -l
total 11465972
-r--r--r-- 1 root users      121133 Feb 14  2016 Forrest\ Gump\ (1994).english.srt
-r--r--r-- 1 root users 11740930048 Feb 14  2016 Forrest\ Gump\ (1994).mkv
-rw-rw-rw- 1 root users       98793 Nov 19 11:06 Forrest\ Gump\ (1994).norweigan.srt

 

Link to comment

First off - you should use 4+1 = 5 for directory access to allow read+execute - execute is used to traverse the directory.

Without this, you shouldn't even be able to see the files in the directory.

 

 

What are your settings for the share?

 

If the Windows machine is user "win" and belonging to group "users", and your share allows write access for "win" then the Windows machine should be able to change access rights for files owned by "win". It should be allowed to change any files that specifically allows write access, but not to change any access rights for a file owned by root.

 

 

The normal Samba access rights checking happens in two layers.

 

The first layer is the samba share settings. So the share settings may have:

    "valid users <user1> <user2> ..." to specify which users that may access the share.

And

    "write list <user1> <user2> ..." to specify which users that it will accept writes from.

 

Alternatively, the share may allow read or write from all users.

 

 

But below that, there is the unix file access rights that must also be fulfilled.

 

Your Windows account belongs to the group "users".

So read and write accesses given to "users" will allow the Windows machine to read and write.

 

But I fail to see why you are allowed to change the access rights for files/directories owned by root.

 

If I test in a directory, I get the following.

Before Windows tries to change access rights:

root@n54l-3:/mnt/disk2/isos/test# ls -l
total 68
-r--r--r-- 1 nobody    nobody  18 Nov 19 15:16 nobody-nobody-444
-rw-r--r-- 1 nobody    nobody  18 Nov 19 15:16 nobody-nobody-644
-rw-rw-r-- 1 nobody    nobody  18 Nov 19 15:16 nobody-nobody-664
-r--r--r-- 1 radium    nobody  18 Nov 19 15:16 radium-nobody-444
-rw-r--r-- 1 radium    nobody  18 Nov 19 15:16 radium-nobody-644
-rw-rw-r-- 1 radium    nobody  18 Nov 19 15:16 radium-nobody-664
-r--r--r-- 1 radium    nogroup 19 Nov 19 15:16 radium-nogroup-444
-rw-r--r-- 1 radium    nogroup 19 Nov 19 15:16 radium-nogroup-644
-rw-rw-r-- 1 radium    nogroup 19 Nov 19 15:16 radium-nogroup-664
-r--r--r-- 1 radium    users   17 Nov 19 15:16 radium-users-444
-rw-r--r-- 1 radium    users   17 Nov 19 15:16 radium-users-644
-rw-rw-r-- 1 radium    users   17 Nov 19 15:16 radium-users-664
-r--r--r-- 1 root      root    14 Nov 19 15:16 root-root-444
-rw-r--r-- 1 root      root    14 Nov 19 15:16 root-root-644
-r--r--r-- 1 root      users   15 Nov 19 15:16 root-users-444
-rw-r--r-- 1 root      users   15 Nov 19 15:16 root-users-644
-rw-rw-r-- 1 root      users   15 Nov 19 15:16 root-users-664

After:

root@n54l-3:/mnt/disk2/isos/test# ls -l
total 68
-r--r--r-- 1 nobody    nobody  18 Nov 19 15:16 nobody-nobody-444
-rw-r--r-- 1 nobody    nobody  18 Nov 19 15:16 nobody-nobody-644
-rw-rw-r-- 1 nobody    nobody  18 Nov 19 15:16 nobody-nobody-664
-rw-rw-rw- 1 radium    nobody  18 Nov 19 15:16 radium-nobody-444
-rw-r--r-- 1 radium    nobody  18 Nov 19 15:16 radium-nobody-644
-rw-rw-r-- 1 radium    nobody  18 Nov 19 15:16 radium-nobody-664
-rw-rw-rw- 1 radium    nogroup 19 Nov 19 15:16 radium-nogroup-444
-rw-r--r-- 1 radium    nogroup 19 Nov 19 15:16 radium-nogroup-644
-rw-rw-r-- 1 radium    nogroup 19 Nov 19 15:16 radium-nogroup-664
-rw-rw-rw- 1 radium    users   17 Nov 19 15:16 radium-users-444
-rw-r--r-- 1 radium    users   17 Nov 19 15:16 radium-users-644
-rw-rw-r-- 1 radium    users   17 Nov 19 15:16 radium-users-664
-r--r--r-- 1 root      root    14 Nov 19 15:16 root-root-444
-rw-r--r-- 1 root      root    14 Nov 19 15:16 root-root-644
-r--r--r-- 1 root      users   15 Nov 19 15:16 root-users-444
-rw-r--r-- 1 root      users   15 Nov 19 15:16 root-users-644
-rw-rw-r-- 1 root      users   15 Nov 19 15:16 root-users-664

As you can see, the entries owned by radium (the Windows machine account) did change -r--r--r-- into -rw-rw-rw.

Any entries owned by nobody or root could not have the file attributes changes.

Link to comment

Created a test share to look at this closer.

 

My windows account is named bjonness406 and the SMB share settings is set to "Private" and "Read/Write" for user bjonness406.

As you can see I still can make the file writeable from notepad++

I can't delete the folder or the file itself from windows explorer, or add new files into the Permissions folder. 

If I try to edit the file with windows notepad, it will not let me and tells me the file is write protected. 

root@Tower:~# cd /mnt/user/Testing/
root@Tower:/mnt/user/Testing# ls -l
total 0
drwxrwxrwx 1 bjonness406 users 29 Nov 19 15:56 Permissions/
root@Tower:/mnt/user/Testing# cd Permissions/
root@Tower:/mnt/user/Testing/Permissions# ls -l
total 4
-rw-rw-rw- 1 bjonness406 users 5 Nov 19 15:57 Try\ to\ edit.txt
root@Tower:/mnt/user/Testing/Permissions# cd ..
root@Tower:/mnt/user/Testing# chmod 544 Permissions/
root@Tower:/mnt/user/Testing# chown root Permissions/
root@Tower:/mnt/user/Testing# ls -l
total 0
dr-xr--r-- 1 root users 29 Nov 19 15:56 Permissions/
root@Tower:/mnt/user/Testing# cd Permissions/
root@Tower:/mnt/user/Testing/Permissions# ls -l
total 4
-rw-rw-rw- 1 bjonness406 users 5 Nov 19 15:57 Try\ to\ edit.txt
root@Tower:/mnt/user/Testing/Permissions# chmod 444 Try\ to\ edit.txt
root@Tower:/mnt/user/Testing/Permissions# chown root Try\ to\ edit.txt
root@Tower:/mnt/user/Testing/Permissions# ls -l
total 4
-r--r--r-- 1 root users 5 Nov 19 16:01 Try\ to\ edit.txt
root@Tower:/mnt/user/Testing/Permissions# ls -l
total 4
-rw-rw-rw- 1 root users 10 Nov 19 16:01 Try\ to\ edit.txt
root@Tower:/mnt/user/Testing/Permissions#

 

Tried to change the group to root also, but I still can make the file writeable with notepad++! 

root@Tower:/mnt/user/Testing/Permissions# chown root:root Try\ to\ edit.txt
root@Tower:/mnt/user/Testing/Permissions# ls -l
total 4
-r--r--r-- 1 root root 10 Nov 19 16:01 Try\ to\ edit.txt
root@Tower:/mnt/user/Testing/Permissions# ls -l
total 4
-rw-rw-rw- 1 root root 16 Nov 19 16:23 Try\ to\ edit.txt
root@Tower:/mnt/user/Testing/Permissions#

 

Link to comment
45 minutes ago, BRiT said:

@Bjonness406

 

Has anyone tried using chattr? :ph34r:

 

Nope, never heard of before!

This works great, even without changing permissions or owner if the files. 

So if I want to make all the files uneditable, can I run this command?

find /mnt/disk1/Media/ -type f -exec chattr +i "{}" \;
find /mnt/disk2/Media/ -type f -exec chattr +i "{}" \;

 

And If I need to edit the files again, I run this command?

find /mnt/disk1/Media/ -type f -exec chattr -i "{}" \;
find /mnt/disk2/Media/ -type f -exec chattr -i "{}" \;

 

There is no need to do this on folder too? I could at least not delete any folders with a file that is immutable.

Link to comment
  • 4 weeks later...

I wonder if its possible to setup a method using Shares with Read/Write to Cache and then ReadOnly on the Array unless something is disabled. I'm guessing that could be performed with the chattr in a Cron script a while after the mover runs. 

 

find /mnt/disk1/Media/ -type f -exec chattr +i "{}" \;

 

I did tinker a few times with setting chatter +i and chatter -i and it appears to work rather well and even if your root you can't appear to do much. 

 

I however didn't try moving any files or folders after running chattr to see if it denied or disabled the command. 

Link to comment
15 minutes ago, kizer said:

I wonder if its possible to setup a method using Shares with Read/Write to Cache and then ReadOnly on the Array unless something is disabled.

You could remount the array disks read-only, would still be able to wite to those shares if set to cache "yes", though you'd need to remount read/write before the mover ran.

Link to comment
  • 6 months later...
On 11/19/2017 at 5:57 PM, Bjonness406 said:

Nope, never heard of before!

This works great, even without changing permissions or owner if the files. 

So if I want to make all the files uneditable, can I run this command?


find /mnt/disk1/Media/ -type f -exec chattr +i "{}" \;
find /mnt/disk2/Media/ -type f -exec chattr +i "{}" \;

 

And If I need to edit the files again, I run this command?


find /mnt/disk1/Media/ -type f -exec chattr -i "{}" \;
find /mnt/disk2/Media/ -type f -exec chattr -i "{}" \;

 

There is no need to do this on folder too? I could at least not delete any folders with a file that is immutable.

 

Is it possible for a developer to add a button next to the share name in "shares" tab that toggles +i and -i commands on the share?

 

That would make it very easy to set this attribute quickly and safely.

 

  • Like 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.