Squid

I understood. Just royally messed up my quote from jonathanm which made it look like I didn't

Then its not a backup... Decent idea, but I don't want to get into changing the files on the backup set for various reasons. FCP can flag it and then leave it to the user to deal with it.

I would say that no, LT's support for their containers has NOT ended (their last update to Plex was 9/13 (although BTSync lists the latest change as 7/2) But, if you absolutely want to run the absolute latest and greatest version of Plex (instead of something that just plain works), then the LT docker is not for you. Switch to Linuxserver's or Binhex's who concentrate on supporting those apps instead of LT where they have multiple areas to concentrate on (and their docker containers are not their priority - nor should it be)

Agree ... as I noted above, this is absolutely the "... SAFEST approach " to ensuring you never have any key transfer issues like jonathanm outlined earlier. New test for FCP maybe

On array start, that still works. unRaid will keep checking until it finds the appropriate key. But on a registration transfer, none of the keys are going to match, so it has no choice but to pick one out of the hat. ergo: only put a single key on the flash drive and you'll have no problems

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...

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. That's on the todo list 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 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)

Whenever a key is transferred, the original GUID gets blacklisted. (Rightfully so in LT's POV)

IIRC jonp stated in the forums that in the case of multiple keys on a stick during the replacement the automatic system would pick the first one it found to transfer the registration on which isn't necessarily what you want. After he announced that I separated my keys and only keep what's tied to the stick on that stick Sent from my LG-D852 using Tapatalk

No. You will wind up formatting that disk and losing the data on them. You have to spend the time and move the files around Sent from my LG-D852 using Tapatalk

A 404 error? Sent from my LG-D852 using Tapatalk

- 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)

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

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

10.2 is the latest public release. Hopefully tonight or tomorrow at the latest Sent from my LG-D852 using Tapatalk

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

Never tried that. I just reverted yesterday so I could develop Sent from my LG-D852 using Tapatalk

Just a little status update here, - SMB read-only mode works bang on. Keeps everything running (but any active streams at the time of an attack will get dropped while SMB is reconfigured) - Also added in a button to manually pop the server over to read-only mode quickly - SMB status in logs looks like it'll give sufficient info on where an attack is coming from (or put another way, you'll at least know where an attack is NOT coming from) - 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. (But in the case of a stop array settings, it will still stop those services to break any extremely unlikely attacks coming through those vectors -> (We all use Windows and SMB don't we?) - Since unRaid insists on restarting all services whenever they get stopped, on a stop Array setting, SMB is switched over to read-only mode because to completely stop the attack from continuing if unRaid restarts SMB on us before the unRaid gets to the stopping services part of stopping the array. - Numerous little bug fixes. Was trying to get this out tonight, but just plain ran out of time on the QC before I've got to go to bed...

3 Entries in the docker FAQ about this:

If this is still the case under 6.2+, you need to report it to Tom

I feel your pain Your sacrifice is duly appreciated

I still use it too. I just have it run a generation on a weekly schedule just in case inotify missed anything. But, dmacias is on it anyways...

ok... First time I've had an issue with NerdPack, so treat me like a noob on my questions In the meantime, I have no choice but to downgrade unRaid (wife is actually watching TV for a change, so I have a small window to develop some things )

I'll have to add support for 6.3 version. Maybe should have based it on slackware 14.1 vs 14.2 instead of 6.1 & 6.2 Fair enough. But why does it sit forever on Retrieving Plugin Information?

Defect Report 6.3.0-RC1 When entering in to NerdPack settings (with the array stopped), the plugin just sits there forever on retrieving plugin information Additionally, the syslog shows that inotify tools has been installed, but inotifywait does not exist within /usr/bin/ (and inotifywait doesn't work from the command line either) Oct 5 17:56:46 Server_A nerdpack: Installing inotify-tools-3.14 package... Oct 5 17:56:46 Server_A root: Oct 5 17:56:46 Server_A root: Installing inotify-tools-3.14 package...