[Plugin] Ransomware Protection - Deprecated


Squid

Recommended Posts

One problem though. The link to Ransomware on the share settings page just generates a 404 error.

Thanks, but even more importantly, now that I saw that screenshot (in non-tabbed mode), I realized that I'm not setting the disk shares to be read-only.  (I run in tabbed mode and don't use disk shares) Oops...
Link to comment

I just went to install the plugin and got this:

 

plugin: installing: https://raw.githubusercontent.com/Squidly271/ransomware.bait/master/plugins/ransomware.bait.plg
plugin: downloading https://raw.githubusercontent.com/Squidly271/ransomware.bait/master/plugins/ransomware.bait.plg
plugin: downloading: https://raw.githubusercontent.com/Squidly271/ransomware.bait/master/plugins/ransomware.bait.plg ... done
plugin: downloading: https://raw.github.com/Squidly271/ransomware.bait/master/archive/ransomware.bait-2016.10.07-x86_64-1.txz ... done

+==============================================================================
| Installing new package /boot/config/plugins/ransomware.bait/ransomware.bait-2016.10.07-x86_64-1.txz
+==============================================================================

Verifying package ransomware.bait-2016.10.07-x86_64-1.txz.
Installing package ransomware.bait-2016.10.07-x86_64-1.txz:
PACKAGE DESCRIPTION:
Package ransomware.bait-2016.10.07-x86_64-1.txz installed.



Warning: file_put_contents(/tmp/ransomware/stoppingService): failed to open stream: No such file or directory in /usr/local/emhttp/plugins/ransomware.bait/scripts/stopService.php on line 6
--------------------------------
Ransomware Protection Installed
Copyright 2016, Andrew Zawadzki
Version: 2016.10.07
--------------------------------
plugin: installed

 

Threw an error, yet claims to be installed.

 

It's shown in the list of installed apps, I clicked settings and it seems I don't have inotify installed. Any way to check for that during the install and throw a more useful notification, or even abort the install?

 

scurries off to install inotify


inotify installed, the plugin seems to be happy now & let me enable it. However, I don't see the bait files being created - I set them to be in every directory. Do I need to reinstall the plugin to be sure?

 

Also, minor typo, see attachment.

unRAID_ransomware_typo.PNG.c1fb944511539e8e6997bf8d10868b0d.PNG

Link to comment

I just went to install the plugin and got this:

 

plugin: installing: https://raw.githubusercontent.com/Squidly271/ransomware.bait/master/plugins/ransomware.bait.plg
plugin: downloading https://raw.githubusercontent.com/Squidly271/ransomware.bait/master/plugins/ransomware.bait.plg
plugin: downloading: https://raw.githubusercontent.com/Squidly271/ransomware.bait/master/plugins/ransomware.bait.plg ... done
plugin: downloading: https://raw.github.com/Squidly271/ransomware.bait/master/archive/ransomware.bait-2016.10.07-x86_64-1.txz ... done

+==============================================================================
| Installing new package /boot/config/plugins/ransomware.bait/ransomware.bait-2016.10.07-x86_64-1.txz
+==============================================================================

Verifying package ransomware.bait-2016.10.07-x86_64-1.txz.
Installing package ransomware.bait-2016.10.07-x86_64-1.txz:
PACKAGE DESCRIPTION:
Package ransomware.bait-2016.10.07-x86_64-1.txz installed.



Warning: file_put_contents(/tmp/ransomware/stoppingService): failed to open stream: No such file or directory in /usr/local/emhttp/plugins/ransomware.bait/scripts/stopService.php on line 6
--------------------------------
Ransomware Protection Installed
Copyright 2016, Andrew Zawadzki
Version: 2016.10.07
--------------------------------
plugin: installed

 

Threw an error, yet claims to be installed.

 

It's shown in the list of installed apps, I clicked settings and it seems I don't have inotify installed. Any way to check for that during the install and throw a more useful notification, or even abort the install?

 

scurries off to install inotify

Error fixed... (but wouldn't have affected anything anyways)

 

Inotify, I'll add a line in the plg file that'll state that its required, but it won't abort the install, as its irrelevant when its installed (before or after), because the settings won't let it run without inotify, and throws up the big popup detailing that.

Link to comment

scurries off to install inotify


inotify installed, the plugin seems to be happy now & let me enable it. However, I don't see the bait files being created - I set them to be in every directory. Do I need to reinstall the plugin to be sure?

 

Also, minor typo, see attachment.

Like the log entry states,
Oct 8 09:43:49 Server_B root: ransomware protection:Creating bait files, all folders of all shares. This may take a bit

 

Drives have to spin up, all the directories have to be scanned, etc.  A new log entry will appear once its finished (the operation is silent because the same thing happens at array start, etc)

 

btw, pet peeve.  Don't edit a pre-existing post with a new question after your original question has already been answered.  Odds are very good that the person (myself) will miss it, since people don't see the edits you made unless they reload the thread.

 

 

Link to comment

scurries off to install inotify


inotify installed, the plugin seems to be happy now & let me enable it. However, I don't see the bait files being created - I set them to be in every directory. Do I need to reinstall the plugin to be sure?

 

Also, minor typo, see attachment.

Like the log entry states,
Oct 8 09:43:49 Server_B root: ransomware protection:Creating bait files, all folders of all shares. This may take a bit

 

Drives have to spin up, all the directories have to be scanned, etc.  A new log entry will appear once its finished (the operation is silent because the same thing happens at array start, etc)

Yeah, saw them being created. Guess I read the log, but not that closely. I figured that if you could detect a file being deleted & shut down SMB within 0.2 seconds, it shouldn't take more than, what, maybe 10 or 20 seconds to create all the files?  :)

 

btw, pet peeve.  Don't edit a pre-existing post with a new question after your original question has already been answered.  Odds are very good that the person (myself) will miss it, since people don't see the edits you made unless they reload the thread.

 

Roger. Will be sure not to.

Link to comment

Yeah, saw them being created. Guess I read the log, but not that closely. I figured that if you could detect a file being deleted & shut down SMB within 0.2 seconds, it shouldn't take more than, what, maybe 10 or 20 seconds to create all the files?  :)

All depends on how many files it has to create.  Right now I'm doing the same steps you followed on my backup server, so it's going to wind up creating ~700,000 files.

 

But here's the thing... If you've got more than ~120,000 folders don't run it in all folders until tomorrow.  Setting the max# of watches is on today's todo list, and right now it'll probably immediately stop the array because inotify is going to error out.  And it may be in a kinda catch-22 situation because everything gets regenerated on a restart of the service etc.  beta is beta

 

EDIT:  Took it 20 minutes for it to create and begin monitoring 236,412 files

 

 

Link to comment

120k directories? Yikes!!

 

I've got 200k photos, but nowhere near that many directories (I shouldn't think).

 

Here's the latest bit from my log:

Oct 8 08:52:32 NAS emhttp: cmd: /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugin install https://raw.githubusercontent.com/Squidly271/ransomware.bait/master/plugins/ransomware.bait.plg
Oct 8 08:52:32 NAS root: plugin: creating: /boot/config/plugins/ransomware.bait/ransomware.bait-2016.10.07-x86_64-1.txz - downloading from URL https://raw.github.com/Squidly271/ransomware.bait/master/archive/ransomware.bait-2016.10.07-x86_64-1.txz
Oct 8 08:52:33 NAS root: plugin: checking: /boot/config/plugins/ransomware.bait/ransomware.bait-2016.10.07-x86_64-1.txz - MD5
Oct 8 08:52:33 NAS root: plugin: running: /boot/config/plugins/ransomware.bait/ransomware.bait-2016.10.07-x86_64-1.txz
Oct 8 08:52:33 NAS root: plugin: running: anonymous
Oct 8 08:52:33 NAS root: ransomware protection:Ransomware protection service not running
Oct 8 08:52:33 NAS root: ransomware protection:No bait files were found
Oct 8 08:52:34 NAS root: ransomware protection:No Settings Defined For Ransomware Protection - Exiting
Oct 8 09:07:44 NAS emhttp: cmd: /usr/local/emhttp/plugins/NerdPack/scripts/packagemanager --download undefined undefined
Oct 8 09:07:44 NAS nerdpack: Processing Packages...
Oct 8 09:07:45 NAS nerdpack: Downloading perl-5.22.2-x86_64-1.txz package...
Oct 8 09:07:51 NAS nerdpack: perl-5.22.2-x86_64-1.txz package download sucessful!
Oct 8 09:07:51 NAS nerdpack: Installing perl-5.22.2 package...
Oct 8 09:08:00 NAS nerdpack: utempter-1.1.6 used by plugin: preclear.disk
Oct 8 09:08:00 NAS nerdpack: All packages processed...
Oct 8 09:11:43 NAS emhttp: cmd: /usr/local/emhttp/plugins/NerdPack/scripts/packagemanager --download undefined undefined
Oct 8 09:11:43 NAS nerdpack: Processing Packages...
Oct 8 09:11:43 NAS nerdpack: Downloading inotify-tools-3.14-x86_64-1.txz package...
Oct 8 09:11:44 NAS nerdpack: inotify-tools-3.14-x86_64-1.txz package download sucessful!
Oct 8 09:11:44 NAS nerdpack: Installing inotify-tools-3.14 package...
Oct 8 09:11:45 NAS nerdpack: perl-5.22.2 package up to date, checksum ok.
Oct 8 09:11:45 NAS nerdpack: utempter-1.1.6 used by plugin: preclear.disk
Oct 8 09:11:45 NAS nerdpack: All packages processed...
Oct 8 09:12:24 NAS emhttp: cmd: /usr/local/emhttp/plugins/NerdPack/scripts/packagemanager --download undefined undefined
Oct 8 09:12:24 NAS nerdpack: Processing Packages...
Oct 8 09:12:24 NAS nerdpack: inotify-tools-3.14 package up to date, checksum ok.
Oct 8 09:12:25 NAS nerdpack: perl-5.22.2 package up to date, checksum ok.
Oct 8 09:12:25 NAS nerdpack: utempter-1.1.6 used by plugin: preclear.disk
Oct 8 09:12:26 NAS nerdpack: All packages processed...
Oct 8 09:14:51 NAS root: ransomware protection:Ransomware protection service not running
Oct 8 09:14:51 NAS root: ransomware protection:No bait files were found
Oct 8 09:14:52 NAS root: ransomware protection:Creating bait files, all folders of all shares. This may take a bit

 

Doesn't look like it's finished creating all the bait files yet, and it's been over an hour (unless it doesn't log a finish?). However, I'm seeing them wherever I look, and I've already warned the wife not to delete them. ("What, don't delete the files that say 'Do-not-delete'? I'd have never thought of that!", yeah, that's why I married her. :))

Link to comment

Since it hasn't stated that its finished yet, it should still be running.

 

You can view the progress with this:

tail -f /tmp/ransomware/filelist

 

Assuming (yes, I know) that it works its way through the shares, then the directory structure alphanumerically, it should be done now.

 

Thanks for that. Other than installing updates, I really, really hope I never think about this plugin again!

 

I appreciate your efforts and that you've put this together.

Link to comment

Does this file exist: /boot/config/plugins/ransomware.bait/filelist  If it does, then it is indeed done

 

There's already been some changes to the system based upon your experience thus far

 

- On stopping the array, the bait files will no longer get deleted automatically (Since this can potentially take some time, don't want to unnecessarily delay array stopping in case of a power failiure)

- It's always logged the # of files created after it's finished (not sure why you're not seeing this however), but now it'll also log when inotify has finished setting up all the watches (as this also takes some time)

- Checking the # watches available became a priority todo

- In the event of a power failure while it's creating the files, the /tmp/ransomware/filelist file is copied over to the flash drive so that when the system starts back up again, it'll wind up deleting those files already created, rather than leaving them "orphaned" (and since they were pre-existing, they wouldn't get monitored)

 

Link to comment

Does this file exist: /boot/config/plugins/ransomware.bait/filelist  If it does, then it is indeed done

It does indeed, so it must be done.

There's already been some changes to the system based upon your experience thus far

Woohoo! I've been useful, not just a complainer!!!  I do always feel bad complaining about stuff like this since I've got no knowledge of how to fix it. Glad I could be helpful.

- On stopping the array, the bait files will no longer get deleted automatically (Since this can potentially take some time, don't want to unnecessarily delay array stopping in case of a power failiure)

Sounds like a great plan!

 

Just curious, how do I go about intentionally deleting the bait files without triggering the watcher?

 

Scenario A)

It excluded "appdata", but I still have the old "apps" directory on my cache drive from when I was running 5.x (a few weeks ago). I really need to get rid of "apps" now that I've got everything functional, but there are a lot of bait files there.

 

Scenario B)

My wife likes to rearrange, copy & move pictures around the server, and I need to teach her to create links or get her to tag them in Piwigo. Once I do that, I'll have some directories she's created for custom collections that will need to be removed to get rid of duplicate images. That will include deleting bait files and triggering an SMB shutdown.

Link to comment

Woohoo! I've been useful, not just a complainer!!!  I do always feel bad complaining about stuff like this since I've got no knowledge of how to fix it. Glad I could be helpful.

I think one of the biggest problem any programmer has is knowing too much about how stuff actually works under the hood, and therefore never thinking that someone would do something out of the ordinary.  Its the feedback that gets stuff fixed because it forces us to think about how something works for users instead of for us

Just curious, how do I go about intentionally deleting the bait files without triggering the watcher?

Stop the service

Scenario A)

It excluded "appdata", but I still have the old "apps" directory on my cache drive from when I was running 5.x (a few weeks ago). I really need to get rid of "apps" now that I've got everything functional, but there are a lot of bait files there.

That's why excluded folders on high on my todo list

Scenario B)

My wife likes to rearrange, copy & move pictures around the server, and I need to teach her to create links or get her to tag them in Piwigo. Once I do that, I'll have some directories she's created for custom collections that will need to be removed to get rid of duplicate images. That will include deleting bait files and triggering an SMB shutdown.

Its a fundamental problem with tossing bait files everywhere.  It vastly increases the odds of an inadvertent triggering.  Why the settings default to root only (not as good protection, but chances of inadvertent triggering drops way way down.

 

Excluded folders will help alleviate it, and selectable depth to traverse when creating the files, but no matter how you cut it, the less bait files on the array, the lower chances of catching an attack, but the more bait files on the array the greater chances of inadvertent triggering.  Its a training issue for the users of this plugin.

 

You're ultimately going to have to figure out what is going to work best for you in your situation.  Either way, even by lowering the # of bait files available, you're still far better off than before this plugin existed.

 

But, as garycase loves to state, nothing beats a good backup plan for the stuff you just can't lose, and my own philosophy on security with users is to make it as limiting as possible (ie: Only I have full and complete RW access to all shares.  The wife / other users has RW access to the shares she actually modifies herself, RO to everything else.  And no guest has RW access to anything (ie: no public shares).  (Why would I want to allow my HTPC write access to my documents share?) 

Link to comment

What if a ransomeware author reads this thread and codes the ransomeware to avoid modifying the bait files?

 

How about an option to change or randomise file names?

Option has been there since day 1 to pick your own names, file types, etc.  Throw them into boot/config/plugins/ransomware.bait/bait

 

Randomization is actually not a bad idea though...

Link to comment

Nice plugin, do we know if ransomware purposfully avoids hidden files? I like to keep things looking clean so copied the bait files to flash and renamed them to .squidbait... and hid the dot files in samba settings. The plugin didn't behave how i'd have expected in this situation, it looks like it constantly gets triggered and gave me a stream of notifications until I disabled it.

Link to comment

Another idea - don't know if you'll like it or if it is easily feasible - 'target dilution'.

 

Right now, each drive is target rich, and even after adding bait files, it is still almost entirely valid data files, relatively few bait files.  So what if we add numerous dummy folders to the root with bait and additional subfolders to them with more bait.  Let's say we add 100 dummy folders, each with 100 dummy folders, and each of them with 100 folders, all with bait files.  Now our real folders are a tiny percentage of the possible branches from the root, even if we haven't added numbers comparable to the actual data file count.  It has suddenly become a very diluted target, and that could allow us to remove all bait files from our true data folders and exclude them, possibly fewer watches needed.  It still looks rich to the attacker, because they can't know which folder branch is valid, but the odds are much higher that they first go after bait files only.  (I doubt unRAID will be important enough for quite awhile, for unRAID customized attack strategies.)

 

There's always a downside, the first one I can think of is whether you can design the top level names such that Mover will ignore them.  Does Mover still ignore folders that begin with a period?  If so, then that would work great.  If an attacker cares at all, then an attacker may actually be *more* interested in a dotted folder, because they may especially want to encrypt whatever the user is trying to hide.

Link to comment

Nice plugin, do we know if ransomware purposfully avoids hidden files? I like to keep things looking clean so copied the bait files to flash and renamed them to .squidbait... and hid the dot files in samba settings. The plugin didn't behave how i'd have expected in this situation, it looks like it constantly gets triggered and gave me a stream of notifications until I disabled it.

Since I don't write ransomware, all I can go by is this: if you hide dot files so that you can't see them over the network easily, any standard scan of the shares performed by a ransomware attack won't see them (and you'd pretty much have to know the exact filename in order to get at it anyways)

 

Net result is that it would be a bad idea to hide them.  You want the files to be front and center and a big target.

 

But on the other hand I'll have to try that situation anyways, as I'm sure it'll come up again....  (the fix may already be in though on the next rev., because its not that its being constantly triggered, but rather that inotifywait is erroring out, and I ran into the constant restart loop tons of times while I was doing the excluded folder option    ;)  )

Link to comment

Since I don't write ransomware, all I can go by is this: if you hide dot files so that you can't see them over the network easily, any standard scan of the shares performed by a ransomware attack won't see them (and you'd pretty much have to know the exact filename in order to get at it anyways.

 

They're pretty easy to see over the network from Windows, just need to have Explorer set to show hidden files and they'll all be visible, I haven't messed around with Windows programming for a good 10 years but I was thinking if you used the windows APIs to get the contents of a directory it would include hidden files so ransomware would likely attempt to encrypt them too, I might set up a Windows VM and test.

Link to comment

Another idea - don't know if you'll like it or if it is easily feasible - 'target dilution'.

Do I ever like any of your ideas?  ;D

Right now, each drive is target rich, and even after adding bait files, it is still almost entirely valid data files, relatively few bait files.  So what if we add numerous dummy folders to the root with bait and additional subfolders to them with more bait.  Let's say we add 100 dummy folders, each with 100 dummy folders, and each of them with 100 folders, all with bait files.  Now our real folders are a tiny percentage of the possible branches from the root, even if we haven't added numbers comparable to the actual data file count.  It has suddenly become a very diluted target, and that could allow us to remove all bait files from our true data folders and exclude them, possibly fewer watches needed.  It still looks rich to the attacker, because they can't know which folder branch is valid, but the odds are much higher that they first go after bait files only.  (I doubt unRAID will be important enough for quite awhile, for unRAID customized attack strategies.)

 

There's always a downside, the first one I can think of is whether you can design the top level names such that Mover will ignore them.  Does Mover still ignore folders that begin with a period?  If so, then that would work great.  If an attacker cares at all, then an attacker may actually be *more* interested in a dotted folder, because they may especially want to encrypt whatever the user is trying to hide.

I'll have to look at this later (say a couple of weeks or so).  Don't want to get sidetracked with different approaches right now while this is still in flux.  Remind me in 2 weeks...

 

But, I will say that Mover doesn't affect any of the bait files (I just moved 4000 bait files from the cache to the array without it tripping).

 

(As an aside though, I actually just tried hiding the .dot files on one of my shares, and it still showed up via Windows (regardless of the show settings), so I'm not quite sure that the option works correctly on 6.3 / win 10)

Link to comment

What if a ransomeware author reads this thread and codes the ransomeware to avoid modifying the bait files?

 

How about an option to change or randomise file names?

Option has been there since day 1 to pick your own names, file types, etc.  Throw them into boot/config/plugins/ransomware.bait/bait

 

Randomization is actually not a bad idea though...

Ah, missed that.  Thx.

Link to comment

Another idea - don't know if you'll like it or if it is easily feasible - 'target dilution'.

 

Right now, each drive is target rich, and even after adding bait files, it is still almost entirely valid data files, relatively few bait files.  So what if we add numerous dummy folders to the root with bait and additional subfolders to them with more bait.  Let's say we add 100 dummy folders, each with 100 dummy folders, and each of them with 100 folders, all with bait files.  Now our real folders are a tiny percentage of the possible branches from the root, even if we haven't added numbers comparable to the actual data file count.  It has suddenly become a very diluted target, and that could allow us to remove all bait files from our true data folders and exclude them, possibly fewer watches needed.  It still looks rich to the attacker, because they can't know which folder branch is valid, but the odds are much higher that they first go after bait files only.  (I doubt unRAID will be important enough for quite awhile, for unRAID customized attack strategies.)

 

There's always a downside, the first one I can think of is whether you can design the top level names such that Mover will ignore them.  Does Mover still ignore folders that begin with a period?  If so, then that would work great.  If an attacker cares at all, then an attacker may actually be *more* interested in a dotted folder, because they may especially want to encrypt whatever the user is trying to hide.

k have some downtime from development while the family is down for Thanksgiving and watching a movie.

 

Multiple Dummy Shares with multiple folders etc.  Understand where you're going with that and can do that as an option.  It would have to be however an addition to the base method, because all you need is an attack to pick a share at random, not pick one of the bait ones and you've lost everything.  But, it will increase the amount of bait available so it will also increase the chances of an attack being caught.  And additionally, it would decrease the chances of inadvertent tripping because now the users just have to avoid shares instead of individual files within the shares they are used to working in.

 

And I'm not particularly worried about increasing the number of watches required.  While each additional watch does slow down the response time of inotify, the bulk of those additional watches are going to be specifically in the bait folders, so its not a real big deal,  if inotify takes an extra 1/100th of a second to catch an attack, the next file due to be encrypted would also be odds on in the bait folder so its no big deal). 

 

Congratulations - you just made it to tomorrow's todo list  ;D  (RP is going to take on my usual release schedule - release often, release small -> small changes per release, but often....  Autoupdate anyone?)

 

Have to think about how to design the root folders.  Maybe something like adding double the amount of bait shares as there are real shares...

 

An additional bonus is that with outright bait shares, limited filenames / types become less important.  Can outright randomize them or say pick three words from a dictionary to create them, and can create a larger base of the actual base files to choose from.

Link to comment

width=175http://angelstarcreations.com/special/computerfunny/images/Cartoon-6.jpg[/img]

 

- Added: Separate read-only SMB / AFP Settings

- Added: Disk shares now set to be read-only (Still need to do UD Mounted disk shares)

- Added: Check and increase inotify watches if required

- Changed: Deletion of bait files now happens when service starts up

- Added: Log when inotify wait is actually ready, willing, and able

- Fix: Remove possibiilty of orphaned bait files on reboots

- Added: Ability to exclude folders

- Added: In the case of changed file according to inotifywait, but md5 hasn't changed, check the md5 again a second later to confirm not just a delayed write.

 

The excluded folder browser library that I'm using only allows you to select entire shares without a major rewrite of the entire library, but if you want to add in *sub folder* of a particular share, I do allow you to type in the appropriate path to the folder to exclude.  (Use a comma to separate entries)

 

Also, starting to think about help text / manual which means that this plugin is basically almost at release stage.  Handle RobJ's ideas, and I think that we're there.

 

Link to comment

With Ransomware Protection version: 2016.10.09, I am getting the following:

 

Time Of Attack:Sun, 09 Oct 2016 17:43:19 -0400

 

 

Samba version 4.4.5

PID    Username    Group        Machine                                  Protocol Version  Encryption          Signing

----------------------------------------------------------------------------------------------------------------------------------------

 

Service      pid    Machine      Connected at                    Encryption  Signing

---------------------------------------------------------------------------------------------

 

No locked files

 

Link to comment

I've upgraded to 2016.10.09.  I really like the automatic popup when you're on the RW page :)

 

The new version is definitely faster!  My windows box loses write access in about 1/10 of a second now:

 

9:13:57.59 - About to delete bait
9:13:57.60 - 0.txt created
9:13:57.60 - 1.txt created
9:13:57.60 - 2.txt created
9:13:57.61 - 3.txt created
9:13:57.61 - 4.txt created
9:13:57.61 - 5.txt created
9:13:57.62 - 6.txt created
9:13:57.62 - 7.txt created
9:13:57.63 - 8.txt created
9:13:57.63 - 9.txt created
9:13:57.64 - 10.txt created
9:13:57.65 - 11.txt created
9:13:57.65 - 12.txt created
9:13:57.66 - 13.txt created
9:13:57.66 - 14.txt created
9:13:57.67 - 15.txt created
9:13:57.68 - 16.txt created
9:13:57.69 - 17.txt created
9:13:57.69 - 18.txt created
9:13:57.70 - 19.txt NOT created
Access is denied.

 

One minor thing, it adds some lines to the syslog that don't have timestamps.  I'm thinking that might confuse other tools that expect each line to start with a timestamp?

 

Oct  9 15:32:24 TowerVM root: ransomware protection:Starting Background Monitoring Of Bait Files
Setting up watches.
Watches established.
Oct  9 15:43:16 TowerVM emhttp: cmd: /usr/local/emhttp/plugins/dynamix/scripts/tail_log syslog

 

 

Also... without this plugin, my VM boots in 25 seconds.  With the plugin installed, it is almost 3 minutes before there is a login prompt on the console or the gui is available.

 

Diagnostics are attached.  It seems to spend a bit of time with vsftpd?  Or is it trying to place the bait files before the array is online?

 

Oct  9 15:29:49 TowerVM root: plugin: installing: /boot/config/plugins/ransomware.bait.plg
Oct  9 15:29:49 TowerVM root: plugin: skipping: /boot/config/plugins/ransomware.bait/ransomware.bait-2016.10.09-x86_64-1.txz already exists
Oct  9 15:29:49 TowerVM root: plugin: running: /boot/config/plugins/ransomware.bait/ransomware.bait-2016.10.09-x86_64-1.txz
Oct  9 15:29:49 TowerVM root: 
Oct  9 15:29:49 TowerVM root: +==============================================================================
Oct  9 15:29:49 TowerVM root: | Installing new package /boot/config/plugins/ransomware.bait/ransomware.bait-2016.10.09-x86_64-1.txz
Oct  9 15:29:49 TowerVM root: +==============================================================================
Oct  9 15:29:49 TowerVM root: 
Oct  9 15:29:49 TowerVM root: Verifying package ransomware.bait-2016.10.09-x86_64-1.txz.
Oct  9 15:29:49 TowerVM root: Installing package ransomware.bait-2016.10.09-x86_64-1.txz:
Oct  9 15:29:49 TowerVM root: PACKAGE DESCRIPTION:
Oct  9 15:29:49 TowerVM root: Package ransomware.bait-2016.10.09-x86_64-1.txz installed.
Oct  9 15:29:49 TowerVM root: 
Oct  9 15:29:49 TowerVM root: 
Oct  9 15:29:49 TowerVM root: plugin: running: anonymous
Oct  9 15:29:49 TowerVM root: Stopping the service and deleting pre-existing bait files.  This may take a bit
Oct  9 15:29:49 TowerVM vsftpd[2814]: connect from 127.0.0.1 (127.0.0.1)
Oct  9 15:29:50 TowerVM vsftpd[2820]: connect from 127.0.0.1 (127.0.0.1)
Oct  9 15:29:52 TowerVM vsftpd[2830]: connect from 127.0.0.1 (127.0.0.1)
Oct  9 15:29:55 TowerVM vsftpd[2844]: connect from 127.0.0.1 (127.0.0.1)
Oct  9 15:29:59 TowerVM vsftpd[2862]: connect from 127.0.0.1 (127.0.0.1)
Oct  9 15:30:04 TowerVM vsftpd[2884]: connect from 127.0.0.1 (127.0.0.1)
Oct  9 15:30:10 TowerVM vsftpd[2910]: connect from 127.0.0.1 (127.0.0.1)
Oct  9 15:30:17 TowerVM vsftpd[2940]: connect from 127.0.0.1 (127.0.0.1)
Oct  9 15:30:25 TowerVM vsftpd[2974]: connect from 127.0.0.1 (127.0.0.1)
Oct  9 15:30:34 TowerVM vsftpd[3012]: connect from 127.0.0.1 (127.0.0.1)
Oct  9 15:30:44 TowerVM vsftpd[3054]: connect from 127.0.0.1 (127.0.0.1)
Oct  9 15:30:54 TowerVM vsftpd[3096]: connect from 127.0.0.1 (127.0.0.1)
Oct  9 15:31:04 TowerVM vsftpd[3138]: connect from 127.0.0.1 (127.0.0.1)
Oct  9 15:31:14 TowerVM vsftpd[3180]: connect from 127.0.0.1 (127.0.0.1)
Oct  9 15:31:24 TowerVM vsftpd[3222]: connect from 127.0.0.1 (127.0.0.1)
Oct  9 15:31:34 TowerVM vsftpd[3264]: connect from 127.0.0.1 (127.0.0.1)
Oct  9 15:31:44 TowerVM vsftpd[3306]: connect from 127.0.0.1 (127.0.0.1)
Oct  9 15:31:54 TowerVM vsftpd[3348]: connect from 127.0.0.1 (127.0.0.1)
Oct  9 15:32:04 TowerVM vsftpd[3390]: connect from 127.0.0.1 (127.0.0.1)
Oct  9 15:32:14 TowerVM vsftpd[3432]: connect from 127.0.0.1 (127.0.0.1)
Oct  9 15:32:14 TowerVM root: ransomware protection:Ransomware protection service not running
Oct  9 15:32:14 TowerVM root: Restarting the background service
Oct  9 15:32:14 TowerVM root: --------------------------------
Oct  9 15:32:14 TowerVM root: Ransomware Protection Installed
Oct  9 15:32:14 TowerVM root: This plugin requires inotify-tools (available within the NerdPack plugin) to operate
Oct  9 15:32:14 TowerVM root: Copyright 2016, Andrew Zawadzki
Oct  9 15:32:14 TowerVM root: Version: 2016.10.09
Oct  9 15:32:14 TowerVM root: --------------------------------
Oct  9 15:32:14 TowerVM root: plugin: installed
Oct  9 15:32:14 TowerVM root: Starting go script

towervm-diagnostics-20161009-1544.zip

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.