Anti-virus scanning exclusions

Published: 2012-04-13
Last Updated: 2012-04-13 17:59:40 UTC
by Daniel Wesemann (Version: 1)
11 comment(s)

Reader Josh writes in with a good question: How does everyone deal with software whose vendor requires that the application and its install directories be excluded completely from Anti-Virus (AV) scanning ? Microsoft has some recommendations for AV exclusions of their own, as do the anti-virus companies themselves (example: McAfee), and googling a bit quickly shows that pretty much every software vendor has knowledge base articles that deal with making their particular tool invisible to AV.

- How do you keep track of the various "approved" exclusions across servers in your company ?
- How do you make sure no malware is hiding or setting up shop in those excluded portions ?
- Any other comments you might have ..

If you have a couple of minutes before starting your weekend, please share in the comments below!

Keywords: anti virus
11 comment(s)


Software vendors are stupid to require folder exclusions to antivirus scanning if the folders can be used by malware.

Most small organizations and home users are not tracking these excluded folders and do not have any way of making sure malware is not hding there if antivirus cannot do it. And that raises the risks of attack even for organizations that do have the resources.
I understand why some vendors require exclusions from AV software. Sometimes they need to perform various actions that may look like malware activity (i.e. hooking SDT and so on) but one thing I would like to see in home user versions of AV is the option to scan the directory but just log instead of deleting or quarantining the files. Symantec Endpoint Protection 12.1 allows this option in the default Exceptions policy. It will just log instead of performing any action against any threat found in those folders. From there you can create a report and keep a log if you wish.
We set a default policy that adds all the recommended Microsoft exclusions for standard workstations and servers, and then manually add exclusions for database and log files. I agree with KBR that software vendors are EXTREMELY overzealous with their recommended exclusions and I am in the habit of ignoring them until a problem is encountered, at which point additional exclusions are made to accommodate them. All of that should be caught during the testing phase, anyhow.
I agree that excluding folders is a risk. The fact is that even if scanned, a good 10 percent or more (lots more probably) of infections go totally undetected for months or even perpetually, leaving the end-user with a false sense of security. Imagine how the Apple fans are feeling now, knowing that their boxes could have been infected with known malware for 6 weeks and Apple didn't bother to tell them. Windows is no different. You think you are safe. In reality, no one is. Your best defense is to accept that you may be infected and to use your computer wisely. Check your accounts and your firewall logs (if you have them) often. Don't use someone else's computer to do something like access your bank account either. You have no idea what may be lurking there. Understanding the threat is at least half the battle here.
I was particularly enthralled with the Websense v7.6 DLP Endpoint Agent installation recommendation to exclude the %TEMP% folders. Because no one tries to hide malicious code in TEMP folders. <sigh>
Any exclusions we have typically get noted and our central service keeps them in place (i.e. any manual changes get reverted within 30 mins).

Any excluded directories are scanned once a night by a scheduled manual scan. This should cover us.
I did a short writeup about this topic a while ago:

The summary is that there needs to be a balance between what's acceptable to exclude, what you have the ability to manage, and what problem you're trying to solve (performance vs functionality)
My "pet-peeve" is those "flashy" (hint! hint!) software companies that tell you to temporarily disable your anti-virus software, while installing their software. What are they trying to hide?
"I agree that excluding folders is a risk."
Possibly. I suppose the question will be... what is your intended purpose of Antivirus software installed on a server.

If it is to prevent accidental infection, by an admin downloading software onto the server, it should still work correctly.

Assuming you don't configure your browser to download to C:\ProgramData\Blah\Example Excluded Directory

Your exclusion has no effect on that; the software is still effective, and you have the benefit of the Antivirus product not causing unexpected downtime of your mission critical server application.

If your intended purpose is to "detect" malicious executable that has already been run on the server, and had a chance to save hidden copies of itself.

There's not an antivirus program invented yet that can be sure of doing that reliably.

Exclusions are a greater risk on workstations.

For servers, implement your vendors' recommendations so you can properly blame them when it breaks.

Implement security hardening practices on your servers.

Implement a policy against any user opening a web browser on a server, or running "just any old program".

If you're as paranoid as me, use group policy to disable Internet Explorer on Windows servers, and implement software restriction policies, with only your known server applications allowed to run, and make sure they apply to any user logging into a server.
@Melvin: We do that with one of our products because we get tired of support calls when they don't do that and the software upgrades go haywire. Don't know why, and frankly don't care.

Yes, the instructions read turn off antivirus, apply upgrade, turn it back on. When people have a big $$$$ per year support contract they tend to understand that we are not trying to actively attack them.

The only exclusion we recommend is excluding the database directory for performance reasons. There's not supposed to be any executables there so well if there's any, blast them!

There's a recommendation that comes and goes about not having antivirus at all on the database server. With proper hardening it should not be necessary. (Incidentally, the recommendation is currently in the not present state because we currently recommend combined application and database server).

We have had serious antivirus problems in the past. The general consensus with both our engineers and support reps is if your antivirus causes our application to break, replace the antivirus. The build machine doesn't have antivirus anymore. We got tired of it screwing up builds with heuristics (no excluding the build directory is not an option for the obvious reason). We now test against only two antivirus: Symantec and Eset. Symantec because the managers run it on their laptops, and Eset because it causes the least performance problems on the servers (not willing to run internet facing production app server without antivirus). Since hosted customers get upgrades first, almost all released builds are scanned by antivirus for that reason alone.

@Mysid: If you have that policy and buy from us, we will tell you to remove the software restrictions on the server. For customers who don't read the hardware requirements (which include us having VPN to the server and internet access from the server), we are debating doubling the support contract because it costs us double to support them.

I'm _quite_ sure you're horrified about VPN for support contract. Believe me, it's worth it. Customers who have worked with us have seen that we an often provide a diagnosis and sometimes a solution to their problem before their own IT staff can even get to the server.

I'm just glad that antivirus companies have learned to turn down their heuristics a bit. As an engineer, I use some pretty potent stuff that could be abused and has tripped heuristics in the past (CreateRemoteThread anybody?). To software that isn't a rapidly moving target (curse you Adobe! You cause us more support calls than Microsoft.), if it has a bug I can fix I just might fix it for them to cut down on our support calls.

Diary Archives