search

SparkyzCodez / FSRM-Anti-ransomware

A suite of PowerShell and Python scripts to help you fight ransomware using both known filespecs and zero-day resistant honey traps.
GNU Affero General Public License v3.0
22 stars 3 forks source link

How to exclude files #9

Open tjjunior opened 4 years ago

tjjunior commented 4 years ago

Great program, thank you! After running EverythingSearchForRansomware.py, I have a list of files that are ok even though they have one of the filtered endings, how do I take that list and whitelist those files? I can add the file names to the most recent json file under exceptions, but it appears to only accept the file name, not the full path. For example, this is a legit file: C:\Program Files\Python38\Lib\test\clinic.test

Can I add an exception for that specific file at that path so that it's not filtered, or do I have to just whitelist "clinic.test" regardless of which directory it's in? I have about 400 matches. Or does the program just ignore existing files once they are already there, and won't allow any new *.test files to be created?

Basically, do I need to do something with the results of EverythingSearchForRansomware if there are legit files found under filters-fsrmMatched?

SparkyzCodez commented 4 years ago

In general, FSRM is more oriented towards matching filter filespecs with files no matter where those files are in a share or drive. I don't know if it can deal with specific paths for exclusion purposes. That's where I'll start my testing.

In the JSON file there are two ways to deal with files that should be allowed. (And since I'm not done with documentation this isn't very clear.) First, if you can make a filter filespec that is more specific, but otherwise matches a filter then you put it in the exceptions. For example there's a filter for "*.potato" and you use an exception to allow "baked.potato". Files named "baked.potato" will not be flagged by FSRM, but "twice-cooked.potato" would still hit. Exceptions go directly into the FSRM file groups exceptions. It's a one-to-one relationship.

In your case you make an exception for "clinic.test" with the side effect that files with that name will ignored everywhere on your file system.

There's also a section in the JSON file called extended-data.excludefromfilters. This filespecs are to find all matching "filters" and remove them from the list before they get put into the FSRM file group. It's almost the inverse of what I described about the exceptions. Since FSRM doesn't handle this at all it has to be done in Python AntiransomwareFiltersMerge.py script.

I've been slacking. I really need to document this stuff more thoroughly.

You may want to reconfigure your script to only apply file screens to shares but not to entire disks. Unless you're actually sharing c:\program files\ (or similar directories) the script won't tell FSRM to look there. Some of my clients use the script this way and only monitor shares. On the other hand, the biggest risk to the network is probably someone with admin privileges mapping to one of the hidden shares like "c$", so watching entire drives isn't a bad idea either.

The script only looks for "normal" file shares right now, and not the special hidden ones. Maybe that should be an option down the road. Maybe I need to add an "also add these locations" option in the script's configuration.

Bottom line, I'll look at what FSRM can do and how I can get the scripts to match what you're after more closely. Thanks again for the feedback.

tjjunior commented 4 years ago

Thanks for the details, I'm not a technical person by trade but trying to secure a server for a small business. I see the script blocks someone trying to write a new file with any of the matching filter attributes (e.g. the clinic.test file due to the .test filetype). But if I have an existing file that matches (such as the python clinic.test file), will the script take any action? If not, then it's probably ok as is (i.e. without creating a filter exception) as it will allow use of the existing files but won't allow a new (probably malicious) file to be created. In other words, there's no real downside to having an existing file match the filters, is that correct?

I currently have it set to monitor everything, nobody else should be writing to the drives only the shares, but again not a lot of downside to having it monitor drives and shares is my thought. Happy to provide any feedback or help write documentation if I can assist.