Ransomware resistance


RobJ

Recommended Posts

Another idea would be a new security permission level: Read & Append

Users could read files, and add uniquely named files, but not overwrite or delete existing files.

This would be good for our media shares that are mostly cold storage, as well as being a good fight against malware.

One would stay logged in at this level for day to day activity, then switch to a higher level login for cleaning and file maintenance.

This would be great, perfect to secure Movies and TV shows from ransomeware.

 

Sounds nice but as far as I know there is nothing in linux resembling that... So will not fly I think..

Link to comment

Another idea would be a new security permission level: Read & Append

Users could read files, and add uniquely named files, but not overwrite or delete existing files.

This would be good for our media shares that are mostly cold storage, as well as being a good fight against malware.

One would stay logged in at this level for day to day activity, then switch to a higher level login for cleaning and file maintenance.

This would be great, perfect to secure Movies and TV shows from ransomeware.

 

Sounds nice but as far as I know there is nothing in linux resembling that... So will not fly I think..

Would it not be possible so that before every write, unraid will check if the file already exist, and if it does. Then refuse the write.

Or change the permissions after a write has happend.

 

I am not a programmer, so I actually have not clue if this could work, just an idea.

Link to comment

Another idea would be a new security permission level: Read & Append

Users could read files, and add uniquely named files, but not overwrite or delete existing files.

This would be good for our media shares that are mostly cold storage, as well as being a good fight against malware.

One would stay logged in at this level for day to day activity, then switch to a higher level login for cleaning and file maintenance.

This would be great, perfect to secure Movies and TV shows from ransomeware.

 

Sounds nice but as far as I know there is nothing in linux resembling that... So will not fly I think..

Would it not be possible so that before every write, unraid will check if the file already exist, and if it does. Then refuse the write.

Or change the permissions after a write has happend.

 

I am not a programmer, so I actually have not clue if this could work, just an idea.

 

From how I envision it...

 

That security layer would be impossible to enforce using standard drive shares like /mnt/cache/ or /mnt/disk#/. It would only be possible via the user shares, and then it would likely slow down all file open and write operations. I don't know how large of a penalty that would be.

 

There could also be issues with certain programs using it, depending on how they write the file. Some programs might create a new file, write some parts to it, close the file, then later on reopen the file to write the next chunk of data.

 

It would also be complicated to allow for certain files to be writable in the shares, such as metadata scrapper based files like .txt, .nfo, .xml, etc, while protecting the larger files. Maybe the protection level would only trigger once a file reaches a certain critical size? But then that might cause issues if one tries to directly download from torrent programs to the share.

Link to comment

Another idea would be a new security permission level: Read & Append

Users could read files, and add uniquely named files, but not overwrite or delete existing files.

This would be good for our media shares that are mostly cold storage, as well as being a good fight against malware.

One would stay logged in at this level for day to day activity, then switch to a higher level login for cleaning and file maintenance.

This would be great, perfect to secure Movies and TV shows from ransomeware.

 

Sounds nice but as far as I know there is nothing in linux resembling that... So will not fly I think..

Would it not be possible so that before every write, unraid will check if the file already exist, and if it does. Then refuse the write.

Or change the permissions after a write has happend.

 

I am not a programmer, so I actually have not clue if this could work, just an idea.

 

From how I envision it...

 

That security layer would be impossible to enforce using standard drive shares like /mnt/cache/ or /mnt/disk#/. It would only be possible via the user shares, and then it would likely slow down all file open and write operations. I don't know how large of a penalty that would be.

 

There could also be issues with certain programs using it, depending on how they write the file. Some programs might create a new file, write some parts to it, close the file, then later on reopen the file to write the next chunk of data.

 

It would also be complicated to allow for certain files to be writable in the shares, such as metadata scrapper based files like .txt, .nfo, .xml, etc, while protecting the larger files. Maybe the protection level would only trigger once a file reaches a certain critical size? But then that might cause issues if one tries to directly download from torrent programs to the share.

You could also lock the files after X minutes with inactivity?

Or if you use chache, the files on the cache have rw access, but when moved to the array they are changed to read only.

Link to comment

The rest is not going to work.. Unraid uses a standard file system.. The stuff discussed might be technically feasable, but it would make a total Linux change necessary and that is not going to happen..

 

The crashplan trick works.. Also solves general backup issues..

 

 

Verzonden vanaf mijn iPhone met Tapatalk

Link to comment

I thought about this today. And I believe this is common.

I have several fast computers in my house for gaming, but all PC's just have a small SSD with no space to install games.

Therefore am I using a Games-Share to stream my games to several comupters in my house. I have read/write access to it since it's non-essential data and makes it easy to update the games from any PC.

 

All other essential shares on my unraid I only use read-access.

 

But I wonder if my Games-Share (mnt/user/Games/) is getting encrypted, since I use like 40% of the array for the Games-Share and the rest % for other files.

Can the encrypted files be deleted? Deleteing the share, or do I have to format all the disks that the Games-Share-files relied on?

 

Does anyone know this?

Link to comment

I thought about this today. And I believe this is common.

I have several fast computers in my house for gaming, but all PC's just have a small SSD with no space to install games.

Therefore am I using a Games-Share to stream my games to several comupters in my house. I have read/write access to it since it's non-essential data and makes it easy to update the games from any PC.

 

All other essential shares on my unraid I only use read-access.

 

But I wonder if my Games-Share (mnt/user/Games/) is getting encrypted, since I use like 40% of the array for the Games-Share and the rest % for other files.

Can the encrypted files be deleted? Deleteing the share, or do I have to format all the disks that the Games-Share-files relied on?

 

Does anyone know this?

 

Not 100% sure and not sure how every ransomware will behave (since this could change) however I would think it would encrypt the files and you would have the choice of deleting them.  What they are hoping is that they hit files that you don't want to delete or lose I don't think it formats the whole disk.

Link to comment
  • 2 weeks later...

Would this work?

  • Share the source folder on network as SMB
  • Set up unRAID share that is hidden and protected (i.e. not even read-only)
  • Use Unassigned Devices to mount the SMB source folders as mnt on unRAID
  • Use Dynamix Scheduler to run periodic rsnapshot to backup the UD mnt to the protected unRAID share
  • Use Crashplan to back up the unRAID share to their cloud

 

I found the limitation of my previous Crashplan-only arrangement is that I don't have a readily-usable mirror and restoring is a very long and painful process.

Hence, perhaps having a local mirror + off-site backup is better in term of "quality of life" kinda thing.

Link to comment

I think I have found the solution!  ;D

 

I set up Syncthing on unRAID (via docker) + my workstation. Then it appears to be a simple matter to setting up the workstation side as "Master" and the unRAID side with "Staggered" versioning. Then set up Crashplan to backup the Syncthing folder on unRAID but exclude the version folder.

 

In this way, I will always have a readily usable mirror for quick and easy restore for day-to-day usage i.e. just copy it back.

 

Assuming I'm under attack, below are the Swiss cheese layers

[*]The virus spreads very quickly on my mostly-ssd-based workstation. This should trigger a massive number of sync breaks and thus heavy activity. I should notice (a) my connection is unexpectedly continuously saturated, (b) my server HDD ligh is flashing high activity when there should be none and © a sudden massive increase in number of sync breaks. These would be the "brace for impact" warning.

[*]The syncthing share is set to private and hidden. Hence, a typical ransomware would not see the network drives to encrypt. A more advance ransomware would not see any SMB share to encrypt - not that it can do anything as private = no writing from outside of the server.

[*]Sync speed is limited by network speed (1Gbps). Hence, it is highly likely that the ransomware would have finished all the encryption of the workstation way before it can be fully replicated on the server. Presumably it would then pop up its "pay me or else" screen so I know for sure I'm under attack. I can then stop any potential further damage by (a) unplug the workstation and/or (b) use tablet to access the GUI and stop the Syncthing docker

[*]Even if for some reasons I didn't stop the sync on time and all damages are replicated on the server (assuming it hasn't run out of space before that), the "Staggered versioning" option would mean I still have a good copy - in fact, the whole version folder is now my good copy.

[*]If all above layers fail (e.g. a very advance virus that can encrypt via syncthing connection), Crashplan <-- it's almost too true in this sense  ::).

 

Any critic / hole spotting is highly highly appreciated. Kudos!  ;)

Link to comment

Here is the problem:

 

I should notice

 

A better approach is to create "canary" files that you will never modify, but will be certain targets of ransomware.  Set a process to monitor the canary files and to fire off notifications/alarms/fireworks if they are touched or deleted.

Link to comment

A better approach is to create "canary" files that you will never modify, but will be certain targets of ransomware.  Set a process to monitor the canary files and to fire off notifications/alarms/fireworks if they are touched or deleted.

 

Canaries are good!

 

NAS originally suggested something like that, and I've been hoping someone would be interested in creating a 'Canary' plugin, which would establish the canaries by configuration, monitor them, and start the fireworks when triggered.  Plugin would have configurable notifications, alarms, and actions, one being to stop the array, perhaps even shut down the system, after logging the detections and explaining any actions taken.  But even a simple plugin would be a nice start - create a few fixed canary files, monitor them, and stop the array if they change.

Link to comment

A better approach is to create "canary" files that you will never modify, but will be certain targets of ransomware.  Set a process to monitor the canary files and to fire off notifications/alarms/fireworks if they are touched or deleted.

 

Canaries are good!

 

NAS originally suggested something like that, and I've been hoping someone would be interested in creating a 'Canary' plugin, which would establish the canaries by configuration, monitor them, and start the fireworks when triggered.  Plugin would have configurable notifications, alarms, and actions, one being to stop the array, perhaps even shut down the system, after logging the detections and explaining any actions taken.  But even a simple plugin would be a nice start - create a fewer fixed canary files, monitor them, and stop the array if they change.

I like this idea! If we could identify where the encryption process starts (Internet cache?), and have the canary file in there, we could mitigate the majority of the damage without complicated backup schemes... Not to say that a concurrent backup plan wouldn't also make good sense

Link to comment

Another relatively easy way to provide resistance is to have another field on the "Global Share Settings" page (or per share) which says

 

"Lock File System Read-Only Y/N"

 

Then if locked, have another option appear with a drop down menu

 

"Temporarily Unlock File System for.......1/2/4/8/16/32/64/128 minutes"

 

If you use mover, it could unlock it temporarily

 

Link to comment

Another relatively easy way to provide resistance is to have another field on the "Global Share Settings" page (or per share) which says

 

"Lock File System Read-Only Y/N"

 

Then if locked, have another option appear with a drop down menu

 

"Temporarily Unlock File System for.......1/2/4/8/16/32/64/128 minutes"

 

If you use mover, it could unlock it temporarily

 

Lately that's the process I've been using, basically if I want to write to my shares I toggle them to Read-Write, and then write then toggle them back. Working fine so far. Just a bit tedious, a nice "one click" button would be cool.

Link to comment

I've just started toggling Read-Only/Read-Write myself, it's just a bit tedious.

 

I wasn't in the least bit worried about ransomware (until someone mentioned it, ignorance was bliss).

Same here. It was a bit of a pain to set it up but now I'm more confident that I won't lose my data to lowly ransomware attack

Link to comment

Another relatively easy way to provide resistance is to have another field on the "Global Share Settings" page (or per share) which says

 

"Lock File System Read-Only Y/N"

 

Then if locked, have another option appear with a drop down menu

 

"Temporarily Unlock File System for.......1/2/4/8/16/32/64/128 minutes"

 

If you use mover, it could unlock it temporarily

I don't think mover would need to unlock it since it runs as root. I assume you are just trying to protect from ransomware running on another machine on the network and not actually executing on unRAID itself.
Link to comment
  • 1 month later...

For those who haven't seen this -

  http://www.cise.ufl.edu/~traynor/papers/scaife-icdcs16.pdf

 

This is an important and useful study of ransomware, talks of methods they use, the file types they go after, their priorities of attack, and many other things about them.  I suspect it will change your ideas, it did mine.  Ignore the primary discussion of a new tool in Windows to battle it, it doesn't seem useful to us, at least not running on unRAID.

Link to comment
  • 1 month later...

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.

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.