[Plugin] Ransomware Protection - Deprecated


Squid

Recommended Posts

I went to /mnt/user/ in mc and deleted the shares recursively. Are you saying I need to go to /mnt/diskX/ in mc and delete again?

Yes.  6.1 doesn't support hardlinks on user shares and those shares are nothing but hardlinks.  Deleting the shares on each disk should work.  Still mobile and can't test though

 

Sent from my LG-D852 using Tapatalk

 

 

Link to comment

 

 

Wow, Squid!

 

I jumped in early on this, but uninstalled it while I was migrating my drives from ReiserFS to XFS. I've been following development, but not paying really close attention. I gotta say, this looks fantastic now! I was all kinds of prepared to ask a bunch of configuration questions, but everything is covered very clearly in your help section and the whole thing looks really professional!

 

I do have a few questions for you:

  • Dracula? Why does he get credit? Yes, I read all of the help
  • .mp3 files. If I wanted to add an mp3 file as a bait target, would I just create /config/plugins/ransomware.bait/bait/squidbait.mp3 and all is good?
  • Protecting other computers. If I were to use Unassigned Devices to remote mount the root of my local machine's hard drive as an SMB share, share that from unRAID, then set RP to protect that share too, what do you think the odds are that it would actually work and detect a file deletion? I realize that shutting down the share from the server would NOT protect the local machine from the ransomware running locally on that machine, but it would likely serve to protect the server that much earlier (possibly before the nasty gets to a share), and would be very explicit as to which machine the attack originated from. Obviously, there would be a lot of work to explicitly exclude machine-local directory structures that get updated frequently (\temp, for example - others based on the OS). Your warnings about RP not protecting local machines got me thinking about this.
  • Tabs. What happened to the nice tabbed interface shown in your screen grabs from the OP? I think they're quite a bit nicer than the long scrolling list of options that are available in the 2017.01.01 version I just pulled today. It would bring the help page much closer to the relevant options, as well, thus making it easier to relate the help to the option (minimizing scrolling), and might minimize questions that are covered in the help files (especially if help is always displayed on the tab).

 

Again - FANTASTIC job with this!

 

Bram stoker gets credit as the random word dictionary is chapter one of dracula.

 

For custom baits you have to add all the ones you want to use.  The files if it exists overrides the defaults. 

 

The system only works with the built in shares. 

 

Tabbed display.  You have settings display settings set to non tabbed.  I was going to override and force it to always be tabbed the next time I update the plugin.

 

 

 

Sent from my LG-D852 using Tapatalk

 

 

Link to comment

Bram stoker gets credit as the random word dictionary is chapter one of dracula.

Got it!

 

For custom baits you have to add all the ones you want to use.  The files if it exists overrides the defaults. 

Thought so, just wanted to confirm

 

The system only works with the built in shares. 

Would have been an interesting experiment...

 

Tabbed display.  You have settings display settings set to non tabbed.  I was going to override and force it to always be tabbed the next time I update the plugin.

Wow... I think I turned that off at one point not realizing that it effected everything, then completely forgot about it.

 

 

Well, I can say that categorically, this system works!

I was running a mirror backup from a project I'm working on on my desktop machine to the server. I didn't have the bait files on my desktop, so the moment the backup software deleted A bait file, everything came to a screeching halt!

 

Clicking the big button to reset permissions followed by copying the bait files to my local directory got things working again with no issues.

 

Thanks again, Squid!!

  • Upvote 1
Link to comment

I have another idea for your consideration, a new mode of ransomware protection that may work better for some users and some situations.  If you call the current method the bait file method or the honey pot method, this new one would be called the no-delete method or the home alarm system method.

 

The user would enable and configure it for a list of shares, one or more shares to protect.  Each share list should be named.  You would then monitor ALL of the files in those shares for changes, by inotifywatches I suppose.  If ANY file is deleted, you immediately lock down the system, the same way you do now if a bait file is messed with.  Optionally, the user could also configure it to trigger on any file modification too, within that list of shares.  They are always allowed to make file additions.  By default, the protection is ON, armed.  If the user wishes to work on one of these shares, modifying and deleting files, they must first request permission by one of several methods, which they configure, in effect the temporary disarming of the system, turning OFF the protection for the share list.

 

1. The 'please' file method - they configure an absolute path to a file of their choosing, not in the root, in order to make it difficult for hackers to find.  If the file (in that exact path) exists, you disarm the system for that share list, and allow any file changes.  Once they remove the file (or modify it in an agreed and configured way), then you rearm the system, disallowing all deletions, and optionally all modifications too.  (I'm thinking it could be called the 'please' file, as it politely requests permission to edit files.)  The user would be expected to make the appropriate macros or shortcuts that arm and disarm the system (create and remove the 'please' file, or edit it correctly).

 

2. If the requesting user has access to the unRAID server, then they could toggle a button in your plugin, to arm and disarm the appropriate share list.  A nice enhancement would be an additional option to disarm for a configurable or user-entered time period (e.g. disarm for 30 minutes), which you would then manage - disarm then rearm after time interval completes.  If no time period, then it's indefinite, and the user is expected to remember to toggle again to rearm the system.

 

3. Scheduled or scripted signaling - your plugin can monitor for a signal that includes the list name and the time interval wanted, then the plugin disarms and rearms automatically, according to the schedule or signal.  This would be ideal for workstation backups.  The scheduler or external script would initiate the disarming, their backup would execute, then the plugin would rearm the share list.

 

4. I'm sure others can think of other ways too, to securely notify the plugin, requesting permission to temporarily disarm the protected shares.

 

I've looked at other anti-ransomware tools out there, and the sophisticated mechanisms they use to try and detect specific ransomware behaviors, and they can still allow a number of encryptions to happen before lockdown occurs.  What I particularly like about this method is it's so simple, nothing at all sophisticated, yet could lock down with the loss of only one file, possibly 2 or 3 if the malware is working really fast before you disable their access.  And instead of low level OS hooking, you're just letting the OS notify you of file changes.  That's all you need (that and knowing the change is more than a file addition).

 

Additional enhancements:

- add optional password on toggle button, and script signal, and within 'please' file (so even if a ransomware is knowledgeable about this plugin, it's blocked by the unknown password and 'please' file)

- allow relative paths within the share list, to limit even further the folders being protected, allowing very specific protections (e.g. limited relative paths: Movies/action, Finances/current/Joes taxes)

 

One gotcha I could see is if a user included a share in more than one protected share list, then disarmed one but not both and deleted a file within that share.  Seems a user responsibility issue to me.  But since overlap seems likely to me in some situations, you may have to detect it and disallow the triggering in the overlapped and still armed share list.  Possibly doable by reordering the list of share lists so that disarmed ones are checked first.  Once you decide a deletion is allowed, then exit, so it isn't even checked in the armed list.

Link to comment

I have another idea for your consideration...

 

That sounds pretty slick!

 

It would absolutely have to have scripted signaling so people using CouchPotato, SickBeard, torrents or any of the other automated downloaders could function.

 

It would also need to be hooked into the Mover somehow so it can do its job without bringing the whole system down.

 

I think the password protected 'Please' method would work well for scripted activities from desktop machines. For example, I run SyncBack to do backups to the server - I can have it execute a batch file to copy/create the key file before the backup starts, then another (or, gasp! the same one with parameters!) to remove it when the backup finishes.

Link to comment

I have another idea for your consideration...

 

That sounds pretty slick!

 

It would absolutely have to have scripted signaling so people using CouchPotato, SickBeard, torrents or any of the other automated downloaders could function.

 

It would also need to be hooked into the Mover somehow so it can do its job without bringing the whole system down.

 

I think the password protected 'Please' method would work well for scripted activities from desktop machines. For example, I run SyncBack to do backups to the server - I can have it execute a batch file to copy/create the key file before the backup starts, then another (or, gasp! the same one with parameters!) to remove it when the backup finishes.

Nothing Squid likes more than feature creep! ;D
Link to comment

It would absolutely have to have scripted signaling so people using CouchPotato, SickBeard, torrents or any of the other automated downloaders could function.

 

It would also need to be hooked into the Mover somehow so it can do its job without bringing the whole system down.

 

I think the password protected 'Please' method would work well for scripted activities from desktop machines. For example, I run SyncBack to do backups to the server - I can have it execute a batch file to copy/create the key file before the backup starts, then another (or, gasp! the same one with parameters!) to remove it when the backup finishes.

 

This is an avenue I hadn't thought of, worth consideration.  As you know, the current method and the new method I've discussed are strictly for protecting shares from attack from *externally* infected machines.  They assume the unRAID server itself is safe, uninfected.  So when an attack is detected, the lockdown is simply closing the gates to the outside world, blocking write access.  We were not worried about software packages (whether plugins, Dockers, or VM's) running on the server, so they have essentially unrestricted access to whatever folders they are configured for.

 

You are suggesting a variant of this new method, that could be used to detect a local infection (something that has infected the unRAID software), and initiate some sort of array lockdown.  Certainly it could be used with little change to detect an attack, detect any deletions in /mnt.  Mechanisms for arming and disarming would have to be different, not sure how that would work, perhaps a detection of a specific process, or some file that is changed when a software package starts and exits.  And the lockdown process really needs some thought.  It's simple to initiate stopping the array, but it takes time, and that allows increased encryptions.  Array stop has to wait for all VM's and containers to shut down, not necessarily a quick process.  Worse yet, the array stop can be easily blocked by opening files on each data drive, blocking the unmounts.  We need some kind of hard termination, forced quick unmounts, but with minimal corruption of the VM and container installations.  This may be tough to do.  Might be better to delay this, give it more time and thought.  For now, it's best to keep our systems patched and updated, as uninfectable as possible.

 

For many users who are running their Plex's and other software non-stop, there's no disarming, they are always 'disarmed', and deleting files at any time.  If detection was limited to only those data folders they don't access (archive folders, personal collections, bait folders), then it would become more of a smoke detector that has the power to shut the system down.

Link to comment

I have another idea for your consideration...

 

That sounds pretty slick!

 

It would absolutely have to have scripted signaling so people using CouchPotato, SickBeard, torrents or any of the other automated downloaders could function.

 

It would also need to be hooked into the Mover somehow so it can do its job without bringing the whole system down.

 

I think the password protected 'Please' method would work well for scripted activities from desktop machines. For example, I run SyncBack to do backups to the server - I can have it execute a batch file to copy/create the key file before the backup starts, then another (or, gasp! the same one with parameters!) to remove it when the backup finishes.

Nothing Squid likes more than feature creep! ;D

I dare you to find an example    ;)
Link to comment

It would absolutely have to have scripted signaling so people using CouchPotato, SickBeard, torrents or any of the other automated downloaders could function.

 

It would also need to be hooked into the Mover somehow so it can do its job without bringing the whole system down.

 

I think the password protected 'Please' method would work well for scripted activities from desktop machines. For example, I run SyncBack to do backups to the server - I can have it execute a batch file to copy/create the key file before the backup starts, then another (or, gasp! the same one with parameters!) to remove it when the backup finishes.

 

This is an avenue I hadn't thought of, worth consideration.  As you know, the current method and the new method I've discussed are strictly for protecting shares from attack from *externally* infected machines.  They assume the unRAID server itself is safe, uninfected.  So when an attack is detected, the lockdown is simply closing the gates to the outside world, blocking write access.  We were not worried about software packages (whether plugins, Dockers, or VM's) running on the server, so they have essentially unrestricted access to whatever folders they are configured for.

 

Don't have the time right now to sit down and the last couple of posts (I'll get to it this weekend) but I will pipe in here and say that the above isn't 100% true.  The current system does indeed protect against access to a user share via a VM  utilizing anything but 9p sharing.  Dockers and plugins however are a different story since they do not access the shares over a network protocol.
Link to comment

This is an avenue I hadn't thought of, worth consideration.  As you know, the current method and the new method I've discussed are strictly for protecting shares from attack from *externally* infected machines.  They assume the unRAID server itself is safe, uninfected.  So when an attack is detected, the lockdown is simply closing the gates to the outside world, blocking write access.  We were not worried about software packages (whether plugins, Dockers, or VM's) running on the server, so they have essentially unrestricted access to whatever folders they are configured for.

 

And that is something that I hadn't really realized.

 

I would think that protecting the server against Windoze based attacks is the #1 priority, and anything else is just gravy on top.

Link to comment

I have another idea for your consideration, a new mode of ransomware protection that may work better for some users and some situations.  If you call the current method the bait file method or the honey pot method, this new one would be called the no-delete method or the home alarm system method.

 

The user would enable and configure it for a list of shares, one or more shares to protect.  Each share list should be named.  You would then monitor ALL of the files in those shares for changes, by inotifywatches I suppose.  If ANY file is deleted, you immediately lock down the system, the same way you do now if a bait file is messed with.  Optionally, the user could also configure it to trigger on any file modification too, within that list of shares.  They are always allowed to make file additions.  By default, the protection is ON, armed.  If the user wishes to work on one of these shares, modifying and deleting files, they must first request permission by one of several methods, which they configure, in effect the temporary disarming of the system, turning OFF the protection for the share list.

 

1. The 'please' file method - they configure an absolute path to a file of their choosing, not in the root, in order to make it difficult for hackers to find.  If the file (in that exact path) exists, you disarm the system for that share list, and allow any file changes.  Once they remove the file (or modify it in an agreed and configured way), then you rearm the system, disallowing all deletions, and optionally all modifications too.  (I'm thinking it could be called the 'please' file, as it politely requests permission to edit files.)  The user would be expected to make the appropriate macros or shortcuts that arm and disarm the system (create and remove the 'please' file, or edit it correctly).

 

2. If the requesting user has access to the unRAID server, then they could toggle a button in your plugin, to arm and disarm the appropriate share list.  A nice enhancement would be an additional option to disarm for a configurable or user-entered time period (e.g. disarm for 30 minutes), which you would then manage - disarm then rearm after time interval completes.  If no time period, then it's indefinite, and the user is expected to remember to toggle again to rearm the system.

 

3. Scheduled or scripted signaling - your plugin can monitor for a signal that includes the list name and the time interval wanted, then the plugin disarms and rearms automatically, according to the schedule or signal.  This would be ideal for workstation backups.  The scheduler or external script would initiate the disarming, their backup would execute, then the plugin would rearm the share list.

 

4. I'm sure others can think of other ways too, to securely notify the plugin, requesting permission to temporarily disarm the protected shares.

 

I've looked at other anti-ransomware tools out there, and the sophisticated mechanisms they use to try and detect specific ransomware behaviors, and they can still allow a number of encryptions to happen before lockdown occurs.  What I particularly like about this method is it's so simple, nothing at all sophisticated, yet could lock down with the loss of only one file, possibly 2 or 3 if the malware is working really fast before you disable their access.  And instead of low level OS hooking, you're just letting the OS notify you of file changes.  That's all you need (that and knowing the change is more than a file addition).

 

Additional enhancements:

- add optional password on toggle button, and script signal, and within 'please' file (so even if a ransomware is knowledgeable about this plugin, it's blocked by the unknown password and 'please' file)

- allow relative paths within the share list, to limit even further the folders being protected, allowing very specific protections (e.g. limited relative paths: Movies/action, Finances/current/Joes taxes)

 

One gotcha I could see is if a user included a share in more than one protected share list, then disarmed one but not both and deleted a file within that share.  Seems a user responsibility issue to me.  But since overlap seems likely to me in some situations, you may have to detect it and disallow the triggering in the overlapped and still armed share list.  Possibly doable by reordering the list of share lists so that disarmed ones are checked first.  Once you decide a deletion is allowed, then exit, so it isn't even checked in the armed list.

Everything is doable.  An API to allow deletions would take the most thought. 

 

Initial downsides to the monitoring for any deletion is a ton of applications (MS Office) wind up writing .tmp files which are ultimately deleted.  But for every problem there is always a solution.

 

I'll get to it at some point... But not for at least a couple of weeks.

Link to comment

Its 6.2.x but it still wont show. I even updated the Community Applications plugin

 

btw a .xml file ? Will it install the same way a regular .plg file is installed?

oops...  That's what happens when you're rushed before your first coffee of the day

 

https://raw.githubusercontent.com/Squidly271/ransomware.bait/master/plugins/newransomware.bait.plg

 

A search within CA for ransomware or virus should bring it up

Link to comment
  • 2 weeks later...

Ok done and done awesome thanks.

 

Last question though, is there anyway to hide it in the Dashboard?

What I do is change the share names to be zzz-Squidbait so that while they show they are at least at the bottom of the lists

 

Sent from my LG-D852 using Tapatalk

 

 

Link to comment
  • 2 weeks later...

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.