NOD32v4 Server Exclusion List

LOL!

Maybe a translation thing, or something that has carried over from translation (seeing as how Eset has a non-english programming/tech support core), but I don't believe the above information regarding using \* for files and sub-folders, and \*.* for just files is documented ANYWHERE.

Someone correct me if I am wrong.

Seriously, LOL.....

 

Just got off the phone with ESET Tech Support. and was told this is NOT correct...

I also pointed the Tech to this thread, and asked them to please have someone formally respond to this question...

But, what I was told is, the default mask that the Exclusions editor adds - *.* - excludes all files AND folders, AND all subfolders and their contents, from being scanned.

 

Well that makes no sense. It was ESET Tech Support who configured my server with this \* exclusion and gave me a lengthy explanation of why this was the correct syntax.

If there's anyone out there from ESET they need to give us a definitive response on this subject.

(Err on the side of caution and say this is a case of the left hand not knowing what the right hand is doing.)

 

I just tested this out with the eicar test file and found that *.* is recursive. Any subfolders will be excluded along with the files inside.

I do know that from the command line, when creating batch files and the like, *.* is not recursive, so this may be where the confusion is with the other tech. I myself believed this to be the case until I tested it myself with the ESET software.

 

Thank you for the confirmation/clarification, Wayne...

Now, if we can just get you guys to provide pre-defined, enabled by default exclusion lists for Microsoft Workstation and Server OS's, maybe a lot of support calls/threads would go away...

hint, hint, hint...

 

The disadvantage of course with any wildcard is that a virus techie knows where to put his trash to get it excluded, which is why building your list using actual filenames on your machine using the good old fashioned dos command into a file is so easy and of course the right thing to do ...

Jim in Retrospect

 

It completely depends how you busy your exchange/AD/FRS services are and how large the associated databases/datastores are. If they are small and have low I/O load they can go through the real-time scanner without a problem but the transactions are time-sensitive and the filelocking while things are being scanned will cause you a hardlock if too much stuff gets backlogged.

 

I am configuring my server exclusion lists based on the various posting in this thread and on the Microsoft site.

I can't figure out how to exclude a top level subdir from scanning and at the same time, INCLUDE a child directory for scanning.

Per http://technet.microsoft.com/en-us/library/cc780637(WS.10).aspx

We need to exclude %systemroot%\SYSVOL from scanning, but we want to INCLUDE directories like systemroot%\SYSVOL\domain, %systemroot%\SYSVOL\domain\policies, %systemroot%\SYSVOL\domain\scripts

In testing with the Eicar.com test file, if I exclude a directory using %systemroot%\SYSVOL\*.*, it automatically excludes all child directories.

I can't find a way to tell it to exclude all files in a single directory and NOT have it apply to child directories as well.

Do we simply need to exclude the entire %systemroot%\SYSVOL branch from scanning?

Doesn't seem like the best security approach.

Bill

 

Well C:\windows\SYSVOL is not the Shared folder it seems
c:\WINDOWS\SYSVOL\SYSVOL is shared as SYSVOL

so anything in c:\windows\sysvol is not in a key danger area, so exclude the subdirectoy c:\WINDOWS\SYSVOL\SYSVOL only

Actually while this folder is listed by MS, not sure why, belt and braces I suppose


This "*" vs "*.*" nonsense is a puzzle from ESET and needs to be addressed, I think all of us should log support calls citing the evidence if eicar testing. It makes a mockery of security that one cannot finegrain it as ome may wish

 

Thanks. Appreciate the tips.

Agreed. Definitely need finer control over inclusions/exclusions -- and some clear documentation on this issue.

I've opened a case on this if anyone else wants to chime in. Case #350603.

I suspect there is no way to include child directories in scanning once you exclude the parent.

Bill

 

Including a child directory from a directory which is excluded seems to be impossible to do with the current version.

Wildcards are pretty basic and don't allow you to do such things, at least not in a way I know. Both * and *.* will do exactly the same, but this is normal by design. You can for example just exclude .doc files with *.doc.

Another thing is that variables do not work [according to some post] so you cant use %windir% for example, but I never really tested that since I prefer to use a complete path for these kinds of things anyways.

/edit:
Well after thinking about it some more one would expect *.* to only exclude the current dir, but it excludes the subdirs aswell.. There is however a command-line option to disable scanning on subdirs so it might be a easy fix for ESET developers to work as expected since they already using such technique on the command line scanner.

/edit2:
Well! after some more browsing and testing the way wildcards are working, *.* should exclude subdirs as well! from excluding c:\temp\*.* I would expect all files and folders to be excluded in c:\temp, but extensionless files should still be scanned. BUT! this doesn't seem to be the case. So that really is a 'bug' atm according to my knowledge.

Also D:\data\*.doc should exclude all .doc files in D:\data\ (like D:\data\admindocs\test.doc) but currently it only works in the D:\data\ directory. So with this exclusion ESET does not include subdirs.. This topic also has a few examples how it should work but currently does not. He also posted that topic in the suggestion thread so hopefully some ESET dev picked it up .

The only option which makes it all more clear is have a tick-box to uncheck (or check) the exclusion to take affect on child directories, which now seems to be 'randomly' doing so.

 

Hmm.

So, here are the rules as I understand them:

1. Exclude c:\parent\*.* = excludes directory and all child directories under parent. Also excludes any extensionless files.

2. Exclude c:\parent\*.doc = excludes all *.doc files in parent only. Child directories are still scanned.

So, the general rule is that a wildcard matching all files will recurse through all successive subdirectories. If the wildcard has a partial file specification, then it applies to the named directory only.

Would be nice if this were documented.

FWIW, I tried these same rules with v3, and they seem to operate the same way, so at least the behavior is consistent between these two versions.

Edit: Eset tech support has just confirmed that you cannot scan a child directory if the parent directory is excluded with a wildcard.

 

I don't know of this is of any use to anyone but I've just found it while trying to work out what I should exclude

www.sunbeltsoftware.com/alex/gblog/avguidelines.doc

 

Hmm. That's quite a find. If this is accurate, it should allow us to target the specific MS server files that don't need scanning . . . and avoid excluding entire directories as a shotgun approach to fixing things.

 

I've still not got round to putting NOD32 on my servers. It's on all clients and a terminal server and not had any complaints or problems... so far.

I'll get the bottle to do the servers soon

There is one thing I don't like seeing is why does the ESET recommending server setting show them though the GUI and not via the XML config file. I'd like to have it all configured in before I even install it

 

If you are hitting locking issues, fire up process monitor and filter down to file system activity on ekrn.exe. If something is repeatedly getting hit by the scanner (logs flooded with a single file being scanned multiple times), odds are you just found your conflict and can set up your exclusions based on what you found there.

 

This is my second time dealing with such an issue as this.

Back in the version 3 days, I had a customer with 3.0.642. Their SBS 2003 server kept randomly hanging. I spent hours troubleshooting. I left antivirus to the very last because I didn't want to believe that antivirus was the culprit. I figured it was well tested and no way could it be the problem.

Sure enough, I checked the site for updates and 3.0.657 was released, with the remark in the release notes "Fixed problem causing system instability on Microsoft Windows Server platform". I upgraded to the newer release, and sure enough, the machine quit hanging.

Now, I have another customer, running version 4 (4.0.437). They are seeing similar things. Their DC will grind to a hault and has to be reset. It typically runs less than 24 hours before becoming useless. I tried everything I could think of. Finally I uninstalled Nod32 and put Symantec on, and the server has been running fine for two weeks.

Seriously ESET, I've been recommending your products to lots of customers. Do you think you could test your antivirus products on Windows 2003 server??!! Do you think you could make these kinds of "bug" fixes a priority?!? We're not talking about desktops crashing here, affecting one person. We are talking about servers crashing, affecting the entire network!

 

I'm tired of beta testing for Eset as well.They need better QC for the best anti-virus in the world.They need a tech room with a bunch of pc's with different os's and different browsers to test on.They need a test network setup to catch things like this before they release.This makes them look bad, as I'm sure other customers are scratching their heads saying the same things you are.these are not isolated problems, these are problems everyone is having on certain os's / machines.

Now where did I put that blasted resume I'll get to this people.After I work there each release will be flawless, with small bug fix releases for minor " isolated " issues.