Jump to content
Squid

[Plugin] Ransomware Protection - Deprecated

434 posts in this topic Last Reply

Recommended Posts

- Since no one has come forward with AFP/NFS assistance as of yet, I'm going to be taking those options out of the settings.

Be glad to test AFP. Don't use NFS though.

Share this post


Link to post

Now that inotify is back in 6.3 I don't seem to be able to reinstall this plugin. Just get the "puzzle piece" icon on the Plugins page for ransomware.bait, and nothing for it in the Settings page.

Share this post


Link to post

Now that inotify is back in 6.3 I don't seem to be able to reinstall this plugin. Just get the "puzzle piece" icon on the Plugins page for ransomware.bait, and nothing for it in the Settings page.

Never tried that.  I just reverted yesterday so I could develop

 

Sent from my LG-D852 using Tapatalk

 

 

Share this post


Link to post

- Since no one has come forward with AFP/NFS assistance as of yet, I'm going to be taking those options out of the settings.

Be glad to test AFP. Don't use NFS though.

Ok thx.  I'll try and come up with some code for you to try

 

Sent from my LG-D852 using Tapatalk

 

 

Share this post


Link to post

how to get last release ?  Plugins page say that version from 2016-10-02 is the latest (initial release).  Also, just upgrade Unraid to 6.2.1 version that was just made available.  Seems to work fine.

Share this post


Link to post

Now that inotify is back in 6.3 I don't seem to be able to reinstall this plugin. Just get the "puzzle piece" icon on the Plugins page for ransomware.bait, and nothing for it in the Settings page.

Never tried that.  I just reverted yesterday so I could develop

 

Sent from my LG-D852 using Tapatalk

I will be rebooting in the next day or so to upsize my cache pool. Will try again after the reboot.

Share this post


Link to post

10.2 is the latest public release.  Hopefully tonight or tomorrow at the latest

 

Sent from my LG-D852 using Tapatalk

 

 

Share this post


Link to post

Now that inotify is back in 6.3 I don't seem to be able to reinstall this plugin. Just get the "puzzle piece" icon on the Plugins page for ransomware.bait, and nothing for it in the Settings page.

Never tried that.  I just reverted yesterday so I could develop

 

Sent from my LG-D852 using Tapatalk

I will be rebooting in the next day or so to upsize my cache pool. Will try again after the reboot.

It's a typo in the plugin file (basically, it was saving the downloaded txz under a different name than it was uninstalling it under    >:(  )

 

Uninstall it again, and reinstall, and it'll pull the updated .plg file with the correction...  ( Only affected people who try and uninstall it.  If you've never tried to uninstall it, no need to do anything.  The updated .plg will automatically get installed with today / tomorrow's update)

 

You'd almost think that I knew what I was doing by now    :o

Share this post


Link to post

Now that inotify is back in 6.3 I don't seem to be able to reinstall this plugin. Just get the "puzzle piece" icon on the Plugins page for ransomware.bait, and nothing for it in the Settings page.

Never tried that.  I just reverted yesterday so I could develop

 

Sent from my LG-D852 using Tapatalk

I will be rebooting in the next day or so to upsize my cache pool. Will try again after the reboot.

It's a typo in the plugin file (basically, it was saving the downloaded txz under a different name than it was uninstalling it under    >:(  )

 

Uninstall it again, and reinstall, and it'll pull the updated .plg file with the correction...  ( Only affected people who try and uninstall it.  If you've never tried to uninstall it, no need to do anything.  The updated .plg will automatically get installed with today / tomorrow's update)

 

You'd almost think that I knew what I was doing by now    :o

I went ahead and rebooted before I saw your post. And then it installed fine. Then I read your post, so just to test the uninstall for you I uninstalled it and reinstalled it again. All OK. Noticed it doesn't seem to put any bait in my Backup share though. Don't know if this is intentional or not. This is the same share I use for CA backup among other things.

Share this post


Link to post

Appdata and CA backups are automatically excluded so that inotify doesn't have a heart attack trying to keep track of potentially hundreds of thousands of files.

 

Sent from my LG-D852 using Tapatalk

 

 

Share this post


Link to post

computer-condom.jpg

 

- Add in PDF bait file

- Add in SMB Readonly mode option

- Add in ability to set Readonly mode anytime

- Add in ability to include appdata for bait

- Add in ability to change emhttp communication port (only needed if stopping the array)

- Add in logging to determine where attack originated from

 

I'm thinking that the next update (in a day or two depending if the wife stops watching movies) will be the last beta.

 

Right now, what I'm interested in is if after triggering the read-only mode (would probably be prudent to turn off the stop array option in the settings) is if after a minute or so if its possible to punch a hole through smb and modify / delete any file anywhere on the array (except on the flash drive).  If you guys can try it and let me know how it goes.  What I'm looking for it the most messed-up way you can think of to try and  modify / delete a file over the network via SMB.

 

During the first minute or so after triggering read-only mode, smb is going to bounce up and down a couple of times.  Basic process is that immediately after an attack, a very fast reconfigure of smb takes place to set read-only mode, and then the plugin works on setting it up properly in the unRaid environment (which takes a couple of seconds).  unRaid itself then reconfigures the smb settings to properly set a read-only mode.  Whole process from start to end is up to a minute, but the files should be read-only throughout the entire process.

 

Upshot of all the reconfiguring (and today's adventure yelling at my server  >:( ) is that I'm fairly sure that adding back in AFP/NFS is going to be a cakewalk. (on tomorrow's todo list along with additional optional excluded folders)

 

 

Share this post


Link to post

(and FTP?)

Problem with FTP is that there are multiple ways of running a server (built-in, plugins, numerous dockers)  How do you detect and stop them all?  FTP will remain on the backburner for a while.

 

By default, FTP runs on port 21 and sFTP on port 22. Would it be possible to block those ports as part of the defenses?

 

It wouldn't be 100%, but it would stop FTP no matter how it was set up. You can add the port limitation as a disclaimer, or, possibly, add in an option to specify the FTP ports if the user is not using defaults. Security through obscurity FTW! ???

 

All in all, this sounds like a fantastic plug-in, and I'm definitely monitoring this for future use!

Share this post


Link to post

I feel like if it is triggered it should send a "wuphf" http://theoffice.wikia.com/wiki/WUPHF.com_(Website)

A 404 error?

 

Sent from my LG-D852 using Tapatalk

Tapatalk butchering the link. Copy paste with the last close parenthesis

 

Fine, I'll post the bit here:

 

On the latest episode of The Office, temp Ryan founds his own social media startup, WUPHF. The service purportedly sends a message to friends on all their channels, Facebook, chat, SMS and Twitter. It even prints out a ‘wuphf’ (pronounced “woof,” the sitcom’s version of a ‘tweet’) on the nearest printer.

Share this post


Link to post

Hi Squid, I installed this on a VM and then deleted one of the bait files.  Everything went read-only pretty quickly, very nice!  Restoring to normal mode was easy too.

 

I decided to see just *how quickly* the server was able to switch to read-only mode.

 

Here is a batch file to run from Windows.  It deletes a bait file from a test directory and then tries creating a bunch of test files:

 

@echo off
REM for simplicity, don't use spaces in TESTDIR
REM TESTDIR should be empty, other than the bait files
SET TESTDIR=\\TOWERVM\DataVM
SET MAXFILES=75
ECHO %TESTDIR%

REM clean up previous run
SET /a "x = 0"
:clean1
if %x% leq %MAXFILES% (
  IF EXIST %TESTDIR%\%x%.txt (
    DEL %TESTDIR%\%x%.txt
  )
  SET /a "x = x + 1"
  GOTO :clean1
)

DIR /O:N %TESTDIR%

REM if "clean" was passed in, exit before beginning next run
IF %1.==clean. (
  GOTO end
)

REM delete the bait
ECHO %TIME% - About to delete bait
DEL %TESTDIR%\SquidBait-DO_NOT_DELETE.jpg

REM loop through and create as many files as possible
SET /a "x = 0"
:while1
if %x% leq %MAXFILES% (
  ECHO hi > %TESTDIR%\%x%.txt
  IF EXIST %TESTDIR%\%x%.txt (
    ECHO %TIME% - %x%.txt created
  ) ELSE (
    ECHO %TIME% - %x%.txt NOT created
  )
  SET /a "x = x + 1"
  GOTO :while1
)
DIR /O:N %TESTDIR%

:end

 

I ran it multiple times, and on my system, it is able to write around 50 files after deleting the bait:

 

C:\stuff\ransomewaredetect>test_rw_prot.bat
\\TOWERVM\DataVM
Volume in drive \\TOWERVM\DataVM is DataVM
Volume Serial Number is 6EE2-FEAD

Directory of \\TOWERVM\DataVM

10/07/2016  12:33 PM    <DIR>          .
10/07/2016  09:23 AM    <DIR>          ..
10/07/2016  10:53 AM            10,807 SquidBait-DO_NOT_DELETE.docx
10/07/2016  10:53 AM             6,685 SquidBait-DO_NOT_DELETE.jpg
10/07/2016  10:53 AM           216,611 SquidBait-DO_NOT_DELETE.pdf
10/07/2016  10:53 AM             8,947 SquidBanking-DO_NOT_DELETE.xlsx
10/07/2016  10:53 AM    <DIR>          top level
               4 File(s)        243,050 bytes
               3 Dir(s)   4,133,871,616 bytes free
12:34:32.49 - About to delete bait
12:34:32.49 - 0.txt created
12:34:32.49 - 1.txt created
12:34:32.50 - 2.txt created
12:34:32.50 - 3.txt created
12:34:32.50 - 4.txt created
12:34:32.51 - 5.txt created
12:34:32.51 - 6.txt created
12:34:32.51 - 7.txt created
12:34:32.52 - 8.txt created
12:34:32.52 - 9.txt created
12:34:32.52 - 10.txt created
12:34:32.53 - 11.txt created
12:34:32.53 - 12.txt created
12:34:32.54 - 13.txt created
12:34:32.54 - 14.txt created
12:34:32.54 - 15.txt created
12:34:32.55 - 16.txt created
12:34:32.55 - 17.txt created
12:34:32.55 - 18.txt created
12:34:32.56 - 19.txt created
12:34:32.56 - 20.txt created
12:34:32.57 - 21.txt created
12:34:32.57 - 22.txt created
12:34:32.57 - 23.txt created
12:34:32.58 - 24.txt created
12:34:32.58 - 25.txt created
12:34:32.59 - 26.txt created
12:34:32.59 - 27.txt created
12:34:32.59 - 28.txt created
12:34:32.60 - 29.txt created
12:34:32.60 - 30.txt created
12:34:32.60 - 31.txt created
12:34:32.61 - 32.txt created
12:34:32.61 - 33.txt created
12:34:32.61 - 34.txt created
12:34:32.62 - 35.txt created
12:34:32.62 - 36.txt created
12:34:32.63 - 37.txt created
12:34:32.63 - 38.txt created
12:34:32.63 - 39.txt created
12:34:32.64 - 40.txt created
12:34:32.64 - 41.txt created
12:34:32.65 - 42.txt created
12:34:32.65 - 43.txt created
12:34:32.65 - 44.txt created
12:34:32.66 - 45.txt created
12:34:32.66 - 46.txt created
12:34:32.67 - 47.txt created
12:34:32.67 - 48.txt created
12:34:32.67 - 49.txt created
12:34:32.68 - 50.txt created
12:34:32.68 - 51.txt created
12:34:32.69 - 52.txt created
12:34:32.69 - 53.txt created
12:34:32.70 - 54.txt created
An unexpected network error occurred.
12:34:32.70 - 55.txt NOT created
Access is denied.
12:34:36.36 - 56.txt NOT created
Access is denied.
12:34:37.20 - 57.txt NOT created
Access is denied.
12:34:37.21 - 58.txt NOT created
Access is denied.
12:34:37.22 - 59.txt NOT created
Access is denied.
12:34:37.23 - 60.txt NOT created
Access is denied.
12:34:37.24 - 61.txt NOT created
Access is denied.
12:34:37.25 - 62.txt NOT created
Access is denied.
12:34:37.26 - 63.txt NOT created
Access is denied.
12:34:37.26 - 64.txt NOT created
Access is denied.
12:34:37.27 - 65.txt NOT created
Access is denied.
12:34:37.28 - 66.txt NOT created
Access is denied.
12:34:37.28 - 67.txt NOT created
Access is denied.
12:34:37.29 - 68.txt NOT created
Access is denied.
12:34:37.29 - 69.txt NOT created
Access is denied.
12:34:37.30 - 70.txt NOT created
Access is denied.
12:34:37.30 - 71.txt NOT created
Access is denied.
12:34:37.30 - 72.txt NOT created
Access is denied.
12:34:37.31 - 73.txt NOT created
Access is denied.
12:34:37.31 - 74.txt NOT created
Access is denied.
12:34:37.31 - 75.txt NOT created
Volume in drive \\TOWERVM\DataVM is DataVM
Volume Serial Number is 6EE2-FEAD

Directory of \\TOWERVM\DataVM

10/07/2016  12:34 PM    <DIR>          .
10/07/2016  09:23 AM    <DIR>          ..
10/07/2016  12:34 PM                 5 0.txt
10/07/2016  12:34 PM                 5 1.txt
10/07/2016  12:34 PM                 5 10.txt
10/07/2016  12:34 PM                 5 11.txt
10/07/2016  12:34 PM                 5 12.txt
10/07/2016  12:34 PM                 5 13.txt
10/07/2016  12:34 PM                 5 14.txt
10/07/2016  12:34 PM                 5 15.txt
10/07/2016  12:34 PM                 5 16.txt
10/07/2016  12:34 PM                 5 17.txt
10/07/2016  12:34 PM                 5 18.txt
10/07/2016  12:34 PM                 5 19.txt
10/07/2016  12:34 PM                 5 2.txt
10/07/2016  12:34 PM                 5 20.txt
10/07/2016  12:34 PM                 5 21.txt
10/07/2016  12:34 PM                 5 22.txt
10/07/2016  12:34 PM                 5 23.txt
10/07/2016  12:34 PM                 5 24.txt
10/07/2016  12:34 PM                 5 25.txt
10/07/2016  12:34 PM                 5 26.txt
10/07/2016  12:34 PM                 5 27.txt
10/07/2016  12:34 PM                 5 28.txt
10/07/2016  12:34 PM                 5 29.txt
10/07/2016  12:34 PM                 5 3.txt
10/07/2016  12:34 PM                 5 30.txt
10/07/2016  12:34 PM                 5 31.txt
10/07/2016  12:34 PM                 5 32.txt
10/07/2016  12:34 PM                 5 33.txt
10/07/2016  12:34 PM                 5 34.txt
10/07/2016  12:34 PM                 5 35.txt
10/07/2016  12:34 PM                 5 36.txt
10/07/2016  12:34 PM                 5 37.txt
10/07/2016  12:34 PM                 5 38.txt
10/07/2016  12:34 PM                 5 39.txt
10/07/2016  12:34 PM                 5 4.txt
10/07/2016  12:34 PM                 5 40.txt
10/07/2016  12:34 PM                 5 41.txt
10/07/2016  12:34 PM                 5 42.txt
10/07/2016  12:34 PM                 5 43.txt
10/07/2016  12:34 PM                 5 44.txt
10/07/2016  12:34 PM                 5 45.txt
10/07/2016  12:34 PM                 5 46.txt
10/07/2016  12:34 PM                 5 47.txt
10/07/2016  12:34 PM                 5 48.txt
10/07/2016  12:34 PM                 5 49.txt
10/07/2016  12:34 PM                 5 5.txt
10/07/2016  12:34 PM                 5 50.txt
10/07/2016  12:34 PM                 5 51.txt
10/07/2016  12:34 PM                 5 52.txt
10/07/2016  12:34 PM                 5 53.txt
10/07/2016  12:34 PM                 5 54.txt
10/07/2016  12:34 PM                 0 55.txt
10/07/2016  12:34 PM                 5 6.txt
10/07/2016  12:34 PM                 5 7.txt
10/07/2016  12:34 PM                 5 8.txt
10/07/2016  12:34 PM                 5 9.txt
10/07/2016  10:53 AM            10,807 SquidBait-DO_NOT_DELETE.docx
10/07/2016  10:53 AM           216,611 SquidBait-DO_NOT_DELETE.pdf
10/07/2016  10:53 AM             8,947 SquidBanking-DO_NOT_DELETE.xlsx
10/07/2016  10:53 AM    <DIR>          top level
              59 File(s)        236,640 bytes
               3 Dir(s)   4,132,155,392 bytes free
C:\stuff\ransomewaredetect>

 

Note that it only takes 2 tenths of a second to cut write access!  Since any ransomware would need time to encrypt the individual files, it is very unlikely that much damage could be done after the bait is triggered.

 

Thanks for building this!

 

 

 

On the placement of bait files - right now there are options for "root only" and "all folders", could we have some options in between?  I'm thinking "top level" and "second level folders" (i.e. one level down from root and two levels down from root).  Similar reasons as excluding appdata, I don't want to cause problems for inotify, considering I also have Dynamix File Integrity, Crashplan, and Plex all looking for changes in files.  Well, plus I don't know how Plex, MediaMonkey, and other apps will react to all these bait files.  And they look messy :)

 

(as an aside, is there anything FCP can do to help make sure /proc/sys/fs/inotify/max_user_watches is set high enough for everything that is going on?)

 

 

Share this post


Link to post

Hi Squid, I installed this on a VM and then deleted one of the bait files.  Everything went read-only pretty quickly, very nice!  Restoring to normal mode was easy too.

 

I decided to see just *how quickly* the server was able to switch to read-only mode.

 

<snip>

 

I ran it multiple times, and on my system, it is able to write around 50 files after deleting the bait:

 

<snip>

 

Note that it only takes 2 tenths of a second to cut write access!  Since any ransomware would need time to encrypt the individual files, it is very unlikely that much damage could be done after the bait is triggered.

 

Thanks for building this!

 

On the placement of bait files - right now there are options for "root only" and "all folders", could we have some options in between?  I'm thinking "top level" and "second level folders" (i.e. one level down from root and two levels down from root).  Similar reasons as excluding appdata, I don't want to cause problems for inotify, considering I also have Dynamix File Integrity, Crashplan, and Plex all looking for changes in files.  Well, plus I don't know how Plex, MediaMonkey, and other apps will react to all these bait files.  And they look messy :)

 

(as an aside, is there anything FCP can do to help make sure /proc/sys/fs/inotify/max_user_watches is set high enough for everything that is going on?)

 

Wow, excellent work! Thanks for doing the testing!

 

I agree, 0.2 seconds isn't very long for a program to do some encryption, however, as fast as CPUs are these days, that still allows for the possibility of some damage, but I'd think not much.

 

As far as the directories where the bait files are written, I certainly get your point. My concern with that, though, is that the research presentation RobJ mentions in this post: https://lime-technology.com/forum/index.php?topic=52462.msg503956#msg503956 they found that there are several different classes of ransomware software, and they don't all do a top-down, or even bottom-up approach to their encryption processing. Actually, the one that seems to be least used is the only one that does go top-down. With that in mind, if you're really worried about getting hit, I'd think the bait files would be best everywhere. Your suggestion, with an option to limit directory depth would probably satisfy everyone.

 

One thing to note, Squid, is that in the more prevalent classes of ransomware, there's a tendency to start with the smallest files first. I note from ljm42's directory listing that your files are pretty large. You may want to make one of the bait files 512 bytes or smaller to increase reaction time to that particular class of scum.

 

Yes, it was a very slow day at the office and I read the whole presentation, why do you ask?

Share this post


Link to post

Note that it only takes 2 tenths of a second to cut write access!  Since any ransomware would need time to encrypt the individual files, it is very unlikely that much damage could be done after the bait is triggered.

Thanks for benchmarking this.  Wanted to get around to it, but never seem to do it.  2/10th of a second.... I can do better than that.  (Although the bulk of the time is probably samba actually doing its thing in stopping the service and out of my control).  (And, your mileage will vary on this depending if unRaid has to spin up additional drives to create the encrypted files, if you're using a cache drive, and the amount of RAM available for write caching. 

 

I already have restricted most of the logging about the attack to after everything is reconfigured, but there is still a log entry prior stating that smb is being restarted into read-only before I do anything.  Can move that after its reconfigured (and change the , and additionally now that I'm thinking about it, I can actually stop smb prior to reconfiguring it and then doing a restart (stop / start) which will cut down some more time.  But, a big time savings I would have to make optional.  That of getting the SMB status prior to stopping everything so that I can log after everything is done the status so that you can have a clue about what triggered the event, and then work on securing the network computer.

 

While only 50 new 2-byte files managed to get written (not a realistic file size when you're dealing with megabyte sized pictures, etc) its still too much in my opinion.  100 bytes plus file overhead isn't where I want this.  I would *love* to see it down to 0-bytes, but realistically, that's probably never going to happen.

 

On the placement of bait files - right now there are options for "root only" and "all folders", could we have some options in between?  I'm thinking "top level" and "second level folders" (i.e. one level down from root and two levels down from root).

That's on the todo list

I don't want to cause problems for inotify, considering I also have Dynamix File Integrity, Crashplan, and Plex all looking for changes in files.  Well, plus I don't know how Plex, MediaMonkey, and other apps will react to all these bait files.  And they look messy :)

Exactly.  I don't know how any program is going to react to a bunch of "foreign" files being tossed into their appdata, and need to limit the possibility of Plex saying "hey, I don't need this file, lets just delete it".  Not to mention that even if there was no possibility of false positives caused by Plex, if I happened to include the Plex folders on my system, I would have 800,000+ watches set up which is definitely going to:

 

#1 - slowdown inotifywait's initialization significantly

#2 - slowdown the detection of any of the watches being changed/deleted significantly

 

But, the upshot is that I know in advance exactly how many watches I'm going to be requiring prior to starting up inotifywait, and it's not too much effort to check if the available watches are available, and if not to then increase them accordingly.

 

As an aside, new folders / shares that get created after the service is started do not get the bait files tossed into them.  That introduces another major level of complexity into the system, and introduces a rather long window of opportunity for ransomware to mess with you, since regenerating the inotify watches means that I first delete all the files, then recreate them (and see if they are able to be recreated), and then toss that back over to inotify.  However, all bait files (mine or your own custom ones) are automatically recreated at every stop and start of the service, or at start of the array.

 

(as an aside, is there anything FCP can do to help make sure /proc/sys/fs/inotify/max_user_watches is set high enough for everything that is going on?)

As noted, I'll include the checks for this in RP itself shortly.  Need to AFP / NFS back into this next (and excluded folders, because depending upon your file structure, something like a /Downloads share may create false positives)

 

 

 

 

Share this post


Link to post

One thing to note, Squid, is that in the more prevalent classes of ransomware, there's a tendency to start with the smallest files first. I note from ljm42's directory listing that your files are pretty large. You may want to make one of the bait files 512 bytes or smaller to increase reaction time to that particular class of scum.

Yes, it was a very slow day at the office and I read the whole presentation, why do you ask?

My rational behind the files was that I also wanted them to be "real", just in case an attack also checked for the validity of the file itself.

 

Additionally, I was basically forced to use docx and xlsx (which take up a larger space) because as noted in the OP, if you open up a doc or xls in MS-Office, when just closing Office down without making any changes the md5 of the file winds up changing (ie: Office is rewriting them slightly differently without permission), and the program interprets that as an attack.  The PDF is the huge one relatively speaking, and is a simple print to pdf of the docx.  Sure, I can guess that I can drop some of the description in the various files, but I still need to have that info in there to prevent accidental deletions / modifications by nosy people, and the outright extraneous link that's in the files is merely a preference that I have as the developer...  ( and for the bulk of files which people have on their media servers at least, those files are pretty much going to be the smallest files of their respective types)

 

But, I did read that paper (and even managed to stay awake for some of it  ;) ), and allowed the user to create their own bait files that are used instead according to their own preference.

 

Ultimately, this plugin takes an "emergency" reaction to the issue of ransomware, but the net result at the end of the day is that if you get hit by it, the ransomware is going to sniff out and encrypt files all across your network.  You still have to properly secure the source, as I can't do anything about it.  (And if you do get hit by it, the 2/10ths of a second (soon to be faster) will secure your files, but in the time that you get the email, go running to your desktop, and have a look to see what's happening, all the files everywhere else are going to be pooched.

 

I guess that I probably should add in a disclaimer into the OP / plugin itself about this...

 

 

 

Share this post


Link to post

Yes, it was a very slow day at the office and I read the whole presentation, why do you ask?

 

LOL :)

 

2/10th of a second.... I can do better than that.

 

You rock ;)

 

getting the SMB status prior to stopping everything so that I can log after everything is done the status so that you can have a clue about what triggered the event, and then work on securing the network computer.

 

I was wondering about that too.  If we can assume the clients will auto-reconnect, then it might work to call smbstatus after restarting smb?  Not sure.

 

 

But, the upshot is that I know in advance exactly how many watches I'm going to be requiring prior to starting up inotifywait, and it's not too much effort to check if the available watches are available, and if not to then increase them accordingly

 

I wonder why CrashPlan didn't think of that?  They make the user update it manually:

  https://support.code42.com/CrashPlan/4/Troubleshooting/Linux_Real-Time_File_Watching_Errors

 

I'd much rather do it your way :)

 

As an aside, new folders / shares that get created after the service is started do not get the bait files tossed into them. 

 

Would it make sense to use cron to restart the service every night?

 

 

I really like the idea to exclude folders too.

 

Thanks again for all of the thought you are putting in to this!

Share this post


Link to post

Yes, it was a very slow day at the office and I read the whole presentation, why do you ask?

 

LOL :)

 

2/10th of a second.... I can do better than that.

 

You rock ;)

My results are 1.5/10th of a second on the published version including smbstatus.  Modified version with smbstatus disabled drops it down to 1/10th.  (and over half of that is simply
time /etc/rc.d/rc.samba stop

  The majority of the rest is going to be inotifywait

getting the SMB status prior to stopping everything so that I can log after everything is done the status so that you can have a clue about what triggered the event, and then work on securing the network computer.

 

I was wondering about that too.  If we can assume the clients will auto-reconnect, then it might work to call smbstatus after restarting smb?  Not sure.

When to check?  Can't really assume that they will reconnect, as if I was going to make something like a ransomware, I wouldn't spend anytime trying to renegotiate a dropped connection.  Renegotiating = less encrypted files.

But, the upshot is that I know in advance exactly how many watches I'm going to be requiring prior to starting up inotifywait, and it's not too much effort to check if the available watches are available, and if not to then increase them accordingly

 

I wonder why CrashPlan didn't think of that?  They make the user update it manually:

  https://support.code42.com/CrashPlan/4/Troubleshooting/Linux_Real-Time_File_Watching_Errors

 

I'd much rather do it your way :)

Don't use crashplan, but I would think because they are backing up a computer that is potentially always in motion with no guarantee that the number of files being backed up will stay constant (or even close).

As an aside, new folders / shares that get created after the service is started do not get the bait files tossed into them. 

 

Would it make sense to use cron to restart the service every night?

Already ahead of you there. 

 

Share this post


Link to post

icon+children.gif

 

- Beta: Stop AFP along with SMB

- Added: Realtime popups of status within Ransomware's Settings/ransomware

- Enhanced: Faster Stopping of SMB

- Fixed: An attack followed by a reboot wouldn't let you restore proper permissions

 

If someone can test out AFP stopping for me, I'd really appreciate it - I think it'll work, but I can't test (no separate setting option right now for it - its just tossed in right now with SMB.... That'll change tomorrow however.)

 

Additionally, can anyone running NFS give post up their /boot/config/shares/shareName.cfg for a share that's setup to be equivalent to SMB's Private (with certain users RW, others RO, and others no access, guests no-access), Secure (certain users RW, others RO, guests read-only) so that I can look at at real example while I'm researching what to put in for the rules

 

Share this post


Link to post

If someone can test out AFP stopping for me, I'd really appreciate it - I think it'll work, but I can't test (no separate setting option right now for it - its just tossed in right now with SMB.... That'll change tomorrow however.)

AFP shares change to "Read Only" as expected. Don't have any way to bench test the AFP, but I would say that all shares change together.

Share this post


Link to post

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

 

 

de5t1d.png

Share this post


Link to post

If someone can test out AFP stopping for me, I'd really appreciate it - I think it'll work, but I can't test (no separate setting option right now for it - its just tossed in right now with SMB.... That'll change tomorrow however.)

AFP shares change to "Read Only" as expected. Don't have any way to bench test the AFP, but I would say that all shares change together.

Can only stop one service at a time, so elected to stop SMB first since most attack vectors would be from Windows due to its prevalence.  Net result is that if both SMB/AFP are set to switch to read-only mode, AFP gets stopped ~ .5/10th of a second after SMB.  If only AFP is set to be read only, it's stopped immediately  (today's rev will have it selectable as to what services to stop)

Share this post


Link to post

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.