Squid

This is what we need to see: http://lime-technology.com/forum/index.php?topic=40937.msg481150#msg481150

Technically, it would be this: http://lime-technology.com/forum/index.php?topic=43430.0 (I think CHBMB just missed his morning coffee ) You can get all the relevant support threads either through CA, or via the Alls Apps Support Thread sticky

http://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.

UTF - I'm using a built-in routine to display everything, and technically, the display format is actually full HTML, so you can rejig everything to display according to that. However, doing that will then make any logs if you run the script in the background look rather strange. And, yeah the editing, etc has been suggested before, but isn't at the top of my priority list.

I'm not understanding what you mean. If you go to settings then click the fcp icon the same page reloads? Sent from my LG-D852 using Tapatalk

Now there's something I never would have thought of doing... Glad you got what you needed

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

Do I ever like any of your ideas? 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)

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 )

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

Hey Squid! Ok, thanks, so if we pretend they are inside domain.img, how do you think we could open the iso and extract the files? Do you think I can pull it to my Windows PC and use a ISO-Mount program like Deamon Tools or something and mount it here and then extract the files? dunno. Rather than just jerking around, I'd just do something like cp /etc/libvirt/qemu/*.xml /boot to copy them to the flash drive (but they probably don't exist there if you've deleted them already) Settings - CA section - Appdata Backup

Squid , i may be need a help on this. i'm not able to run openelec or libreelec headless using the pre-packaged vm . I already post on this and never get answer https://lime-technology.com/forum/index.php?topic=48290.0 I do run Librelec or openelec using passthough GPU perfectly. If I use the pre-packaged version , I get the mount error and if I use the johnodon method with VNC , I get error like "failed to start xorg. is your GPU supported?" Any hint on this ? I get the exact same problem, when trying to passthrough, but always just wrote it off as my P.O.S. server. But, my point in the quote was to NOT passthrough anything, as the pre-packaged versions work 100% perfectly without passthrough and use that as a "headless" install until Kodi gets around to creating their own headless option. my vm passtrough version is for my media room. it works perflecty. but I was running kodi headless docker , now it's broke. I want to run a headless libreelec VM , with prepackaged version (no passthrough) but I always get this error ; <domain type='kvm'> <name>OpenELEC</name> <uuid>a7e5bff4-8888-f13f-3256-d3c9dd92bdba</uuid> <description>OpenELEC Headless</description> <metadata> <vmtemplate xmlns="unraid" name="OpenELEC" icon="openelec.png" openelec="6.0.3_1"/> </metadata> <memory unit='KiB'>524288</memory> <currentMemory unit='KiB'>524288</currentMemory> <memoryBacking> <nosharepages/> </memoryBacking> <vcpu placement='static'>2</vcpu> <cputune> <vcpupin vcpu='0' cpuset='6'/> <vcpupin vcpu='1' cpuset='7'/> </cputune> <os> <type arch='x86_64' machine='pc-q35-2.5'>hvm</type> <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader> <nvram>/etc/libvirt/qemu/nvram/a7e5bff4-8888-f13f-3256-d3c9dd92bdba_VARS-pure-efi.fd</nvram> </os> <features> <acpi/> <apic/> </features> <cpu> <topology sockets='1' cores='2' threads='1'/> </cpu> <clock offset='utc'> <timer name='rtc' tickpolicy='catchup'/> <timer name='pit' tickpolicy='delay'/> <timer name='hpet' present='no'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/local/sbin/qemu</emulator> <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/mnt/disks/CT480BX200SSD1_1542F00E9079/OpenELEC/OpenELEC-unRAID.x86_64-6.0.3_1.img'/> <target dev='hdc' bus='virtio'/> <readonly/> <boot order='1'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x04' function='0x0'/> </disk> <controller type='usb' index='0' model='ich9-ehci1'> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x7'/> </controller> <controller type='usb' index='0' model='ich9-uhci1'> <master startport='0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0' multifunction='on'/> </controller> <controller type='usb' index='0' model='ich9-uhci2'> <master startport='2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x1'/> </controller> <controller type='usb' index='0' model='ich9-uhci3'> <master startport='4'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x2'/> </controller> <controller type='sata' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> </controller> <controller type='pci' index='0' model='pcie-root'/> <controller type='pci' index='1' model='dmi-to-pci-bridge'> <model name='i82801b11-bridge'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x1e' function='0x0'/> </controller> <controller type='pci' index='2' model='pci-bridge'> <model name='pci-bridge'/> <target chassisNr='2'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x01' function='0x0'/> </controller> <controller type='virtio-serial' index='0'> <address type='pci' domain='0x0000' bus='0x02' slot='0x03' function='0x0'/> </controller> <filesystem type='mount' accessmode='passthrough'> <source dir='/mnt/cache/appdata/OpenELEC/'/> <target dir='appconfig'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x01' function='0x0'/> </filesystem> <interface type='bridge'> <mac address='52:54:00:0a:bb:db'/> <source bridge='br0'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x02' function='0x0'/> </interface> <serial type='pty'> <target port='0'/> </serial> <console type='pty'> <target type='serial' port='0'/> </console> <channel type='unix'> <source mode='connect'/> <target type='virtio' name='org.qemu.guest_agent.0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <input type='tablet' bus='usb'/> <input type='mouse' bus='ps2'/> <input type='keyboard' bus='ps2'/> <graphics type='vnc' port='-1' autoport='yes' websocket='-1' listen='0.0.0.0'> <listen type='address' address='0.0.0.0'/> </graphics> <video> <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> </video> <memballoon model='virtio'> <address type='pci' domain='0x0000' bus='0x02' slot='0x05' function='0x0'/> </memballoon> </devices> </domain> nobody never get this issue ? Not sure. Worked out of the box for me, and I'm not the VM guy around here....

Not a real VM guy, but I believe that are actually stored within domain.img (/config/plugins/dynamix.kvm.manager). Probably won't help you now, but your best way of backing up your XML's is to actually set up CA's appdata backup feature, and enable to VM XML backup option (set it to backup to the appdata folder), and use dated backups. Your XMLs will wind up getting saved outside of the domain.img, and with the dated backup feature, you'll have access to them for as long as you choose.

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 Stop the service That's why excluded folders on high on my todo list 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?)

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)

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

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

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.

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.

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

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)

- 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

Only way is Community Applications clicking the will display the changelog for the app. But not all authors always remember to update it.

LOL 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 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. 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). Would it make sense to use cron to restart the service every night? Already ahead of you there.

Squid , i may be need a help on this. i'm not able to run openelec or libreelec headless using the pre-packaged vm . I already post on this and never get answer https://lime-technology.com/forum/index.php?topic=48290.0 I do run Librelec or openelec using passthough GPU perfectly. If I use the pre-packaged version , I get the mount error and if I use the johnodon method with VNC , I get error like "failed to start xorg. is your GPU supported?" Any hint on this ? I get the exact same problem, when trying to passthrough, but always just wrote it off as my P.O.S. server. But, my point in the quote was to NOT passthrough anything, as the pre-packaged versions work 100% perfectly without passthrough and use that as a "headless" install until Kodi gets around to creating their own headless option.