Ransomware resistance


RobJ

Recommended Posts

I've been thinking...  NAS and LimeTech have been doing great work in keeping unRAID vulnerability-free, in the software department.  But the number one vulnerability that users have is not things like Shell-shock and the like, it's malware from other local stations.  And I'd really like to see some brainstorming as to how this can be better addressed.  Yes, you could say it's not our problem, because it's mostly related to user behavior, but it's not necessarily the unRAID user's behavior, it's more likely the behavior of a non-technical relative on their network.  Ransomware is not going to go away, and is becoming a very serious problem for *everyone*, not just the non-technical, especially with the newer phishing methods.

 

And I can't help thinking there's a great opportunity here, for unRAID.  It would require some development effort, but if unRAID could advertise as the first file storage product with ransomware resistance features, that should draw some great industry attention!

 

So what to do...  The easiest first step is educational, add plain and prominent warnings to EVERY writable share, that ALL shares that are writable are vulnerable to ransomware.  That at least could get users thinking about the problem, thinking of how to set it up to be safer.  That's a critical first step.  I believe share defaults should ALWAYS be read only, and if they change it, a big warning should pop up.

 

Then comes the harder part, how to create default modes and permissions that encourage safe setups.  I wanted a way to set up a single mode where existing files are read only (can't be modified, renamed, or deleted), but still have create permissions (files could be added).  I looked into how Linux permissions work (broken in my view, with no way to independently control delete permissions, except the sticky bit), and I looked at Samba controls (perhaps there's a way, but I couldn't find it).  So unless you Linux wizards know of a way, or how to develop a way (modify the Linux kernel), then this idea seems out.

 

There's always the tried and true method of setting up shares twice, one with read only permissions for public use, and a separate one that's almost identical except it requires secure authentication and allows read write access for maintenance of the share (like adding and deleting files of the share).  But this is extra work, and so far, seems to be resisted by many, wrongly perhaps.  But we want to come up with ways that are easy and defaulting.

 

I've been playing with the idea of an additional share mode that's more resistant (don't know yet what to call it - read/write-on-demand?).  It's a hybrid setup, a single share with 2 different users/user groups, plus time limiting on the writable access.  You would set up the default access for public use (user=nobody I assume), read only of course, then set up a second user or user group that has writable permissions, but is not logged in without a separate and manual, securely authenticated login.  Then time limiting techniques are applied, and this user is automatically logged out.  So essentially anyone will have full read access to the files of the share, but when updating is needed, a secure user can briefly log in and do what's needed, then log out or be logged out if they forget.

 

Time limiting could work several ways.  At secure login time, a default time limit (perhaps one hour?) is presented, but is configurable if much larger updates are needed.  Or a method based on write activity, once writing has stopped for say 10 minutes (configurable), user is logged out.

 

I'm sure others have ideas too, let the brain-storming begin...  I really believe *something* has to be done, and that it may be more important than even the CVE's.  But it would also be nice to have a feature-to-beat in comparisons between NAS type products.

  • Upvote 1
Link to comment

Certainly not a bad idea to be as bullet-proof as possible.    I've seen two cases of encrypting ransomware in the past 3 months, and these are NASTY infections => if you have any mapped drives to your server the ransomware will indeed destroy all of the data on those "drives".    Fortunately neither of the cases I've seen impacted data beyond the PC that was infected (neither person had an UnRAID server; but they did have other PC's in their home that were networked -- they just didn't have any mapped drives).

 

Link to comment

The problem in the enterprise is some applications require full user access to directories from which they run on the server, I put it down to lazy programming. I have one customer who runs their main application this way, each user who runs the app must be a local admin and then must have full permission to the directory on the server. So far they haven't been hit by ransomeware and we have good backups but its crazy.

Link to comment

Good inaccessible backups are an acceptable strategy.  It requires equivalent extra storage space though, not an option for everyone.  And as we all know, it's not enforceable!  We can't make people do the right thing.  Thankfully, almost all of the most important files are smaller, don't require much backup space, leaving no excuse for them not being backed up.  But videos are a different story, huge, and many don't bother (I'm one!).

Link to comment

... many don't bother (I'm one!).

 

"... I'm one ..."  ==>  Shame on you !!  :) :)

 

;D

Money is tight!  They're just TV recordings, compressed, that I haven't had time to watch.  It wouldn't kill me to lose some of them.

 

I assume you know I said the above with tongue firmly implanted in cheek  :) :)

Link to comment

This is an excellent area to discuss, nice idea !

 

OK so from my POV I am not so much interested in permissions and teaching users. That is something we have always tried to do and it just wont ever work in a scale big enough to protect enough users.

 

But there are other things we could do:

 

Such as....

 

We could have trap files that if touched put unRAID into RO mode and alert.

We could watch samba logs for file write walking and after some trigger put unRAID into RO mode and alert.

We could watch for file becoming encrypted (header) and if we see it put unRAID into RO mode and alert.

We could have a proper IDS/Snort option

We could have anonmoly usage detection based on times of day

 

None of these are 100% but the advantage is they could ship with defaults that dont need user skills to understand, maintain or enable

  • Like 2
Link to comment

Unfortunately there's no "best" way to protect the arrays -- it depends very much on the usage pattern.    For example, many users have arrays that are essentially read-only 99% of the time ... i.e. large media collections that are updated perhaps a few times a month but are primarily just streamed for viewing/listening.    For these users, an extra layer of write protection (e.g. an extra password) wouldn't be much of a burden;  but for those who are constantly using their arrays as primary storage with very frequent writes this would be a significant hassle.

 

One thing I've noted in the few instances of the encrypting randsomware infections I've seen:  they only seem to access networked resources if there's a drive mapping to the resource.    So simply NOT using mapped drives seems to provide a fair amount of protection against these infections.  But I do NOT know if this is generally true, as I've only seen a small sampling of these infections [fortunately never on one of my systems  :) ].

 

 

Link to comment

If nothing else this thread has done me a service in getting me to audit my share settings and rethink who really needs write permission. After thinking about it some I fit the category of users who very rarely writes to his system (mostly for video files that I've ripped for Plex / Emby)

 

I do have one automatic backup that Windows does via.... whatever Windows calls it's timemachine knock-off every night, but I could make all the other shares read-only and have a "DropBox" for purposes of moving data onto the array. This would only be a minor inconvenience for me, but if it improves security it sounds like a good idea.

Link to comment

If nothing else this thread has done me a service in getting me to audit my share settings and rethink who really needs write permission. After thinking about it some I fit the category of users who very rarely writes to his system (mostly for video files that I've ripped for Plex / Emby)

 

I do have one automatic backup that Windows does via.... whatever Windows calls it's timemachine knock-off every night, but I could make all the other shares read-only and have a "DropBox" for purposes of moving data onto the array. This would only be a minor inconvenience for me, but if it improves security it sounds like a good idea.

 

 

you could just CRON a script that copys over daily like mover does

Link to comment

We could have trap files that if touched put unRAID into RO mode and alert.

We could watch samba logs for file write walking and after some trigger put unRAID into RO mode and alert.

We could watch for file becoming encrypted (header) and if we see it put unRAID into RO mode and alert.

We could have a proper IDS/Snort option

We could have anonmoly usage detection based on times of day

 

None of these are 100% but the advantage is they could ship with defaults that dont need user skills to understand, maintain or enable

 

Those are some cool ideas!  I'm thinking put a jpg on the root of every file system (call it nude.jpg? financials.jpg? but actually be a pic of a horses back end, or a lime).  In the root, it should likely be among the first to be read or opened.  Then constantly monitor it (or the first 512 bytes of it?).  Any file operation on it at all would trip the alarm, setting a system event (malware_trap_tripped?), and initiating notifications, and either setting unRAID read-only system-wide (any Linux wizard know how to do that?), or looping through all open file systems and remounting as read-only any that aren't already, or just stop the array.

 

One of the first core features we may want to request therefore is a lockdown mode and a way to trigger this, a way to quickly change all file systems to read-only.  Then we let ingenious plugin writers think of ways to detect malicious activity and trigger this lockdown feature.

 

There's nothing stopping someone from writing a plugin now that detects bad behavior and raises notifications and calls for an array stop.  Anyone?

  • Like 2
Link to comment

The problem in the enterprise is some applications require full user access to directories from which they run on the server, I put it down to lazy programming.

The 'way things have always been done' has to change some times.  New enemies with new weapons means new defenses.  Change or die.

 

I have one customer who runs their main application this way, each user who runs the app must be a local admin and then must have full permission to the directory on the server.

An app that requires admin access?  They should talk to the people behind that app and DEMAND changes.  Or demand shared liability?  ;)

Sounds like placing the master key to your entire business under a flower pot up front and hoping no one finds it.  Once the hacker finds a way in, they have full malicious access to everything.

 

So far they haven't been hit by ransomeware and we have good backups but its crazy.

The key words are "so far".  Most people never think you have to lock the barn door until the horse is gone.  Most people don't get backup religion until after a major file loss.  Sooner or later you are likely to be hacked.  Somewhere on your network is a user who is going to do something dumb.

Link to comment

I wonder if there is a way to use rsync's (read mover...) --existing, --ignore-existing and --link-dest options in such a way that you could prevent modified files (read encrypted) from getting moved over top of the existing files, instead keeping the original and the modified file... (I know that last part is possible as there are guides to using rsync and -link-dest to create time machine like backups), which would kind of "vaccinate" you against ransomware at the cost of having to manually delete older versions of files when you intentionally modify files...

 

I really wish I had a test server right now... maybe I'll hook up a raspberry pi and mess around with rsycn and see what I can get it to do...

Link to comment

To add to this I have set all my users shares/disk shares to secure.

 

But what is the default setting for linux security settings? I only ask as ls -l shows the following for /mnt/disk1 as an example

 

drwxrwxrwx+  7 nobody users 176 Jan  2 15:02 files/

drwxrwxrwx  12 nobody users 336 Mar 22 20:09 media/

drwxrwxrwx  4 nobody users  96 Jan  3 15:25 unRAID_Monthly/

drwxrwxrwx  3 nobody users  80 Apr  8 19:56 unRAID_Test/

 

What would be the recommended chmod settings for the above and do I apply it to Disk share (/mnt/disk1) or each user share?

 

Link to comment

To add to this I have set all my users shares/disk shares to secure.

 

But what is the default setting for linux security settings? I only ask as ls -l shows the following for /mnt/disk1 as an example

 

drwxrwxrwx+  7 nobody users 176 Jan  2 15:02 files/

drwxrwxrwx  12 nobody users 336 Mar 22 20:09 media/

drwxrwxrwx  4 nobody users  96 Jan  3 15:25 unRAID_Monthly/

drwxrwxrwx  3 nobody users  80 Apr  8 19:56 unRAID_Test/

 

What would be the recommended chmod settings for the above and do I apply it to Disk share (/mnt/disk1) or each user share?

you probably do not want to change those!  The Samba security settings which apply to the network shares are independent of the Linux level permissions (other than that the Linux level must be permissive enough to allow the Samba level to function as expected).
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.