You can disable this for servers using this - Malware Exclusions - User Guide for VMware vSphere (veeam.com)

I am still playing to see about exclusions for files, etc.

Right. I found that, but no rules to exclude a specific file type per server.

I hope that this feature gets enhanced over the next few builds as it is an amazing way to see what’s on your servers. 

Not sure about folders, but files/types you can exclude @Scott . It is shown in the Guest Index Scan. I suppose this type of scan and exclusions only applies if you have guest indexing enabled in your Backup jobs. Interestingly, I’ve been reading through the Malware Detection section myself just this morning as I’m getting ready to enable this feature and am not wanting false pos’s.

Otherwise, I don’t see where else you can do exclusions aside from what Chris shared, which just allows VM exclusions. 

Yeah, having exclusions similar to what AV programs do would be great.

I know you can exclude file types and have already added a few. Excluding all the file types in my false positives would be about as useful as totally disabling the feature. Because it is different types on different servers a bit more customization would be the only way. 

I am in a bit of a unique circumstance as I have thousands if not tens of thousands of different file types and many are from video players and viewers. Many of them just create their own file type extensions to work in their software and get flagged. 

I did find this

1. If the malware detection event was false positive, specify the reason, select the Mark restore points affected by corresponding detection events as clean check box, and click Yes. The malware status of the machine will be automatically updated. Previous restore points will be marked as clean. Next restore points will not be marked as suspicious or infected.

I was hoping that this would perhaps keep track of the files so they wouldn’t get re flagged on the next run but it didn’t seem to do that. It marked the backup as clean, but then on the next scan it seemed to flag them again. I’ll keep playing around with it.   

Hi @Scott  This may help

Malware Exclusions - User Guide for VMware vSphere (veeam.com)

it is also possible to create a list of trusted files, but this is a global setting.
Here I have also created an importable xml with many suspicious extensions and commonly used trusted files

cguide] v12.1 Beta: How to Install PostgreSQL 15.4 & VBR 12.1 & EM + Malware Detect Extension to Monitor | Veeam Community Resource Hub
greetings

To me, that seems like a bug then Scott...doesn’t it to you? I interpret that as no more marks as infected for future scans. Maybe reach out to support, or better yet, inquire to PMs on the Forums on the behavior?

That is a great list! 

Maybe I'll work on the trusted files list and use my previous malware log to get the information. I’d like to trigger future events and then modify as necessary.  

That’s possible, but I could be interpreting it wrong too. 

I just checked the box and will see what happens on the next run.   I have hundreds of millions of files so I don’t expect this to be perfect, but If I can get it close, checking that malware detection log isn’t too bad.  

check this @Scott  

How Malware Detection Works - User Guide for VMware vSphere (veeam.com)

Managing Malware Status - User Guide for VMware vSphere (veeam.com)

You can open a ticket to support for clarification

Because this is so new, I’m sure there’s going to be trial and error per organization/environment. But, wording in the Guide is pretty important to help us get our environment where we want it without minimizing/decreasing the value of the malware scans.

I think this marks that run clean and restore points on disk but does not mean it will not detect it again. At least that is what I have seen in testing.

check this @Scott  

How Malware Detection Works - User Guide for VMware vSphere (veeam.com)

 

 

Managing Malware Status - User Guide for VMware vSphere (veeam.com)

You can open a ticket to support for clarification

Using that checkbox is the same as adding it to the global exclusion list.  

Clicking exclude workload will just omit all my file servers which is really what I want to do.

Interesting enough the files are all back though showing the false positives from last nights backups.

I’ll look into this a bit more and see what I can do with the rules. It’s not the end of the world. I did find a bunch of encrypted files from years back when there was an incident so the feature works. 

I suppose I can just look at the logs everyday to see if there is a change in file size, or create a script to extract the current days vs the previous days and show the differences. I could email that to myself to not have to do it manually. 

I assume those ‘old files’ are no longer causing issue?

Hopefully you have a plan moving forward Scott. This has been a good thread since that feature is so new. Have been learning quite a bit through everyone’s comments :)

Not sure if you use VONE but there are some nice reports and alerts there too for the Malware piece.

I believe the logic now is per-server exclusion OR per-file type exclusion.

It doesn’t have the ability to exclude a set of file types on a selection of servers.  

I like the recommendation above by @Link State 

Rick - what do you think of the ability to be able to add folders exclusions, as a future feature enhancement? It appears it would have value. Thoughts?

No. they are still showing as malware

I would be all for this definitely.  It would in a similar fashion to AV exclusions where you can do file, folder, etc.

Thanks for confirming. 

I’ll play around a bit more but I think the reality is I have too many files and file types that will trigger it constantly. Masking out all my servers or almost every file type isn’t helpful. I’ll start by just masking out everything flagged. At least new malicious file types will still trigger alert. 

I’ll create a feature request in R+D to have more granular control on the masking. 

I ‘ll also ask for the ability to not alert on “accepted files”.  It would be nice to just say everything in that log file is safe, and skip them on following scans. (I’d assume that wouldn’t be hard to implement either)

From my point of view, folder exclusions can be dangerous as you no longer have control and they would never be checked again by the inline scan.

You would need a rule of overwriting scan alarms already detected and accepted by the operator previously and only alerting you if new files are detected etc. 
 

Absolutely agree with this depending on the user and use case.  For those that are tech savvy however I don’t see this being an issue especially if the folder you are excluding is say ISO files for installs or something that does not change often.  Overall, it would be better not to have this for security but then there is the case to be made for it.  I guess we will see what happens in the future as this progresses. 

Just you wait on feature requests I have something brewing. 

"Just you wait on feature requests I have something brewing." Ohhhh!