NOD32v4 Server Exclusion List

[towen]

We have just reasonly bought into NOD32 V4 AntiVirus Business Edition

Installed in on 2 Windows XP Clients all seemed OK - When we installed it on our Windows 2003 Servers it ground them to a halt! >:( - Not Good!

After a short phonecall to the ESET Helpdesk they told me I had to add exclusions. He sent me a document a few links to check out; I have done this -

If I add these will this cure it; Can anyone confirm?

D:\System Files*.* (This contains off our AD Data)
C:\Windows\System32*.* (For DNS, DHCP etc)
C:\Program Files\Microsoft SQL Server (For SQL Server)
C:\Windows\SoftwareDistribution*.*
C:\Windows\Security*.*

Is there any others that I should be aware off and that I should add....?

[WayneP]

Hello towen,

Adding exclusions should solve the problem you described. However, there are many factors that can cause the same type of issue. You should add the exclusions and then if it still does the same thing, you can either let us know here or call the ESET support line again.

[towen]

Thanks Wayne;

I will give it a go tommorrow; hopefully these exclusions will do the trick...

If not I will be back on the phone to ESET Tech Support UK!

Not a very good start for a new customer to NOD32 I might add!

[towen]

Tried to install this first thing this morning added all the exclusions and made some changes in advanced mode - low and behold the same thing happens - the server came to a grinding halt >:(

Righty after another call to ESET Support Helpdesk;

Apprently I need to use the /* to include all sub folders and files...

So this would be:

D:\System Files/* (This contains off our AD Data)
C:\Windows\System32/* (For DNS, DHCP etc)
C:\Program Files\Microsoft SQL Server/* (For SQL Server)
C:\Windows\SoftwareDistribution/*
C:\Windows\Security/*

Can anyone confirm that I have the correct syntax? As I dont want another morning like I had this morning server lockup

Why can't ESET just create a general exceptions for standard Microsoft Components! - Surely this is not to much to ask is it?

[jimwillsher]

If you need the /* then that's the first I've heard about it....and I don't have that on any of my servers. That said, I do have two servers which crash and burn with V4 installed so they have V3 on them.

Jim

[YeOldeStonecat]

Forgetting a few important ones...
Active Directory database files = C:\WINDOWS\NTDS
SYSVOL C:\WINDOWS\SYSVOL
NTFRS Database Files = C:\WINDOWS\ntfrs

The following is a list for Microsoft Small Business Server....but you can easily figure out which ones are related to Windows Server, and Microsoft Exchange
http://www.sbsfaq.com/Lists/FAQs/DispForm.aspx?ID=137

[tanstaafl]

-{ Quote: "Why can't ESET just create a general exceptions for standard Microsoft Components! - Surely this is not to much to ask is it?" }-
In my opinion this is not just a good question, it is absolutely ridiculous that it even needs to be asked.

The fact is, these exclusions should be HARD-CODED into the program, both so that it never scans these files/folders from the very first time it runs after installation, but also so that it doesn't rely on someone finding out the hard way that they are necessary, and then hoping you don't miss one or rely on bad information from someone/where else.

ESET - HARD-CODE these exclusions NOW.

[jimwillsher]

I don't agree that they should be hardcoded, as that's removing control from the user, but I do think it should be a tickbox on the installation screen.

During installation we get asked if we want to enable advanced heuristics and warning of potential nasty apps, so why not ask if we want to exclude everything that should be excluded? Especially on a server...

[trjam]

why not install with default settings. Verify that all is well and move slowly from there.

[jimbo1199]

This includes AD, Exchange and Windows Update for Vista and 2008

I have gleaned this from technet and interpolated it to my install. It includes Exchange, do not use the <guid> - correct it for yours. Use your locations
I can find no referecne in the doco about /* doing Subdirectories, and you DO not want to do that, it provides an exploit, Ideally you dont want any wildcards, but who can do that.. >:(

A clever user can add these lines to the XML settings file and load them in that way (create a single exclusion, export settings, find it and use the XML as a template but be carefull how you go)

These links will help you find other OS information.

http://support.microsoft.com/kb/822158
http://technet.microsoft.com/en-us/library/bb332342.aspx

C:\Program Files\Microsoft\Exchange Server\ExchangeOAB\*.*
C:\Program Files\Microsoft\Exchange Server\ExchangeOAB\<your guid>\*.*
C:\Program Files\Microsoft\Exchange Server\Logging\*.*
C:\Program Files\Microsoft\Exchange Server\Logging\TraceLogs\*.*
C:\Program Files\Microsoft\Exchange Server\Logging\lodctr_backups\*.*
C:\Program Files\Microsoft\Exchange Server\Mailbox\*.*
C:\Program Files\Microsoft\Exchange Server\Mailbox\First Storage Group\
C:\Program Files\Microsoft\Exchange Server\Mailbox\First Storage Group\CatalogData-<guid>\*.*
C:\Program Files\Microsoft\Exchange Server\Mailbox\MDBTEMP\*.*
C:\Program Files\Microsoft\Exchange Server\Mailbox\Second Storage Group\*.*
C:\Program Files\Microsoft\Exchange Server\Mailbox\schema\*.*
C:\Program Files\Microsoft\Exchange Server\TransportRoles\Logs\*.*
C:\Program Files\Microsoft\Exchange Server\TransportRoles\Logs\MessageTracking\*.*
C:\Program Files\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog\*.*
C:\Program Files\Microsoft\Exchange Server\Working\*.*
C:\Program Files\Microsoft\Exchange Server\Working\OleConverter\*.*
C:\ProgramData\ntuser.pol
C:\Windows\NTDS\*.*
C:\Windows\SYSVOL\*.*
C:\Windows\SYSVOL\domain\DO_NOT_REMOVE_NtFrs_PreInstall_Directory\*.*
C:\Windows\SYSVOL\staging areas\*.*
C:\Windows\SYSVOL\staging\*.*
C:\Windows\SYSVOL\staging\domain\*.*
C:\Windows\SYSVOL\sysvol\*.*
C:\Windows\Security\Database\*.sdb
C:\Windows\Security\Database\edb*.jrs
C:\Windows\Security\Database\edb*.log
C:\Windows\Security\Database\edb.chk
C:\Windows\Security\Logs\*.log
C:\Windows\Security\edb.log
C:\Windows\SoftwareDistribution\DataStore\DataStore.edb
C:\Windows\SoftwareDistribution\DataStore\Logs\*.edb
C:\Windows\SoftwareDistribution\DataStore\Logs\edb*.jrs
C:\Windows\SoftwareDistribution\DataStore\Logs\edb*.log
C:\Windows\SoftwareDistribution\DataStore\Logs\edb.chk
C:\Windows\System32\GroupPolicy\*.*
C:\Windows\System32\GroupPolicy\ADMIN$\*.*
C:\Windows\System32\GroupPolicy\Machine\*.*
C:\Windows\System32\GroupPolicy\User\*.*
C:\Windows\System32\inetsrv\*.*
C:\Windows\ntfrs\jet\log\*.log
C:\Windows\ntfrs\jet\log\edbres00001.jrs
C:\Windows\ntfrs\jet\log\edbres00002.jrs
C:\Windows\ntfrs\jet\ntfrs.jdb
C:\Windows\ntfrs\jet\sys\edb.chk

[goldrushtech]

You don't need to stuff around with editing an xml file.

From the remote console. choose configuration then save the config file.

When the config editor opens, find the exclusions eset kernal/setup/exclusions.

select edit, then click on list and you can import the exclusions

[a_kerbouchard]

Dont use version 4 on servers yet. I have all exclusions and it still causes lockups and have to be manually restarted by holding in the power button.

[goldrushtech]

Anyone have any idea when V4 will be OK on servers. My understanding it's just DCs that have the issue. I'm running it on a Terminal Server without issue, but had a clients DC hang every few days. Nearly cost me a client and lots of cash (he threatened to send the server back) until I found out about the issue with V4. I did a search of Wilders looking for server 2003 and found the issue. Be nice to have been notified....

[jimbo1199]

I have got 4.0.437 working with help from ESET AU on windows 2008 X64, Active Directory and Exchange 2007, and I am not having lockups, however, there were
Huge problems with earlier V4 builds
sidebyside problems in the eventlog started by EGUI.exe, solution install all the MS C++ 2005 redistributables - especially on machines with not very much other software installed
Also uninstall V3 first and run the Uninstall utility from ESET

Jim

[towen]

Still having major issues with v4 - System Lockups result in restarting the server by hitting the Power Button >:(

Even after support have looked at it - 3rd Line Support are now on the case... Waiting to hear back

Perhaps if they designed a Server Version which gives the options for the exclusions that might help....!

Incidentally does v3 require all of these exclusions?

[goldrushtech]

V3 doesn't hang without the exclusions, but they are a good idea.

Cut and paste the list from Jimbo1199 into notepad, update the specific folders you need to (GUID).
Use the remote admin to import the list as I stated earlier.

Takes about 5 minutes.

Just go back to V3. V4 is not worth the grief.

[jimbo1199]

There is one typo at least in the list, first storage group is missing it's \*.*

I note also that VISTA workstations need some of these, especially to do with Windows Updates...

Only copy my list - if your data is where this data may be, and note the exact location of some of them is per machine dependent.
remember dir c:\<xyz>\widget.* /b/s > a_file.txt is a good tool - still finds things faster than any index

Jim

[goldrushtech]

Jim,

thanks for that. Did pick up on the typo, but forgot about it.

and yes, use some (no so) common sense..... Check the files before you load it. I did.

Just a question. I had three folders with different GUIDs, so I added all three. I assume that's correct.

[jimbo1199]

M'thinks as I only have one I should not speculate, however, if inside exchange you reference more Mailbox databases than one, and they are mounted booted and spurred, they may have more than one catalog and hence more than one GUID, are the files under that folder current dates?

In security retrospect, would be keener to see
C:\Program Files\Microsoft\Exchange Server\Mailbox\First Storage Group\*.edb
and
C:\Program Files\Microsoft\Exchange Server\Mailbox\First Storage Group\*.log

[goldrushtech]

Duh,,,

OAB is for Offline Address Book... and I have three on the server

Which is a whole other story.

Migrating from SBS 2003, to SBS 2008.

I had three separate organisations on my server, with isolated multiple Global Address Lists.

Migrate to SBS 2008 and everyone sees everyone else....

Search high and low and tweek stuff etc until at 2.30 am this morning I found this..
http://technet.microsoft.com/en-us/library/bb936719.aspx

and I wasn't about to start into 26 pages at that time so off to bed I went... Small job for this weekend.

[peterdevlin]

I had to get a heads up on the use of \* from ESET UK Tech Support. Apparently this is the correct syntax for exclusion of files and subdirs for a target directory. I was informed that \*.* is a file exclusion syntax only.

From my POV this is strange (and crazy) as I was building these exclusion lists using the ESET Configuration Editor. And no, it is not documented anywhere that I could find ::)

[tanstaafl]

-{ Quote: "I had to get a heads up on the use of \* from ESET UK Tech Support. Apparently this is the correct syntax for exclusion of files and subdirs for a target directory. I was informed that \*.* is a file exclusion syntax only.

From my POV this is strange (and crazy) as I was building these exclusion lists using the ESET Configuration Editor. And no, it is not documented anywhere that I could find ::)" }-

?! Are you serious??

AGAIN, we need some CLARIFICATION, please.

Would someone from ESET PLEASE confirm this?

All of my exclusions have \*.*

Is it true that in order to include SUBDIRS, the *.* should be changed to just *?

And one more time... please, please PLEASE either hardcode these, or at least allow them to be enabled/disabled with a single checkbox option (for ALL microsoft recommended exclusions).

I honestly cannot understand why ESET does this - they could probably avoid a LOT of complaints and problems and SUPPORT TICKETS (read: WASTED MONEY) by doing this...

[peterdevlin]

I'm very serious. I had to download the ESET remote support application that allowed the ESET support tech to access my server. Whilst I watched he ran through the NOD32 config section putting everything to \* and, as we were on a phone call at the time, explained what he was doing and why he was doing it.

[Ragefire]

So, if I'm reading this right, you can replace:

C:\Program Files\Microsoft\Exchange Server\ExchangeOAB\*.*
C:\Program Files\Microsoft\Exchange Server\ExchangeOAB\<your guid>\*.*
C:\Program Files\Microsoft\Exchange Server\Logging\*.*
C:\Program Files\Microsoft\Exchange Server\Logging\TraceLogs\*.*
C:\Program Files\Microsoft\Exchange Server\Logging\lodctr_backups\*.*
C:\Program Files\Microsoft\Exchange Server\Mailbox\*.*
C:\Program Files\Microsoft\Exchange Server\Mailbox\First Storage Group\
C:\Program Files\Microsoft\Exchange Server\Mailbox\First Storage Group\CatalogData-<guid>\*.*
C:\Program Files\Microsoft\Exchange Server\Mailbox\MDBTEMP\*.*
C:\Program Files\Microsoft\Exchange Server\Mailbox\Second Storage Group\*.*
C:\Program Files\Microsoft\Exchange Server\Mailbox\schema\*.*
C:\Program Files\Microsoft\Exchange Server\TransportRoles\Logs\*.*
C:\Program Files\Microsoft\Exchange Server\TransportRoles\Logs\MessageTracking\*.*
C:\Program Files\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog\*.*
C:\Program Files\Microsoft\Exchange Server\Working\*.*
C:\Program Files\Microsoft\Exchange Server\Working\OleConverter\*.*

With:

C:\Program Files\Microsoft\Exchange Server\*

[peterdevlin]

That is correct.

[jeremyf]

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

[tanstaafl]

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.

[peterdevlin]

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

[WayneP]

-{ Quote: "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.

[tanstaafl]

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

[jimbo1199]

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:-\

[SmackyTheFrog]

-{ Quote: "V3 doesn't hang without the exclusions, but they are a good idea.

Cut and paste the list from Jimbo1199 into notepad, update the specific folders you need to (GUID).
Use the remote admin to import the list as I stated earlier.

Takes about 5 minutes.

Just go back to V3. V4 is not worth the grief." }-
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.

[k12adm1n]

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%28WS.10%29.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

[jimbo1199]

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

[k12adm1n]

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

[Brambb]

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 (http://www.wilderssecurity.com/showthread.php?t=241118) 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.

[k12adm1n]

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

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.

[crutter]

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

[k12adm1n]

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.

[crutter]

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

[SmackyTheFrog]

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.

[CrashX]

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!

[ccomputertek]

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 :doubt: I'll get to this people.After I work there each release will be flawless, with small bug fix releases for minor " isolated " issues.