Exclusions bug for Network drives v3.0

Discussion in 'ESET NOD32 Antivirus' started by Btom, Dec 22, 2008.

Thread Status:
Not open for further replies.
  1. Btom

    Btom Registered Member

    Joined:
    Dec 22, 2008
    Posts:
    4
    Hello all,
    I have a problem with the Exclusions filter for NOD32 v3.0.684. My exclusions are for 2 folders on the network, but it seems to have no effect.
    There is one particular file I would like to exclude and I have entered it in the Exclusions box in various formats:

    \\xen-dc-1\storage_backup\data\amicos\config\amicos_develop.ini
    L:\amicos\config\amicos_develop.ini (since it is a mapped network drive)
    L:\amicos\config\*.*

    However, I can see using Filemon that ekrn.exe is still scanning this particular file. The path, however, in as listed in Filemon is:
    L:\data\amicos\config\amicos_develop.ini
    So, I entered this path as well. Still no effect.
    What am I doing wrong? Has anyone else experienced this?

    Exclusions seem to work fine locally!

    Thanks in advance,
    Tom
     
  2. Rmuffler

    Rmuffler Former Eset Moderator

    Joined:
    Jun 26, 2008
    Posts:
    995
    Location:
    San Diego, CA USA
    Hello Btom,

    Uncheck the scan Network drives box.

    Uncheck network drives.jpg

    Thank you,
    Richard
     
  3. Btom

    Btom Registered Member

    Joined:
    Dec 22, 2008
    Posts:
    4
    Hello Richard,

    I would rather not have to uncheck the 'Network Drives' checkbox. That opens up other security threats. It would be great if the Exclusions box worked. Eset support says that they can't recreate the problem--that exclusions work fine for them. I don't know what else to try.

    Thanks,
    Tom
     
  4. aieie

    aieie Registered Member

    Joined:
    Apr 13, 2007
    Posts:
    175
    What kind of OS is exporting the network shares? (Linux Samba shares......)

    Could help to recreate the problem.

    Best Regards
     
  5. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
    I've tested network exclusions with v4 in the form of a UNC path (\\computer\share) and it worked. Could you try installing EAV 4 beta to see if it makes a difference?
     
  6. ASpace

    ASpace Guest

    It doesn't pose risk any risk . NOD32 won't scan any network located files however if a file is copied on your machine , it will then be scanned by means of scanning any files locally . If a file is not located on your machine/drive , you won't be at risk . Follow Richard's suggestion (if you want to stay with the commercial v3.0) or try EAV v4.0.68 BETA as suggested by Marcos
     
  7. edwin3333

    edwin3333 Registered Member

    Joined:
    Aug 29, 2007
    Posts:
    244
    What about in the case where you double click on an executable on a network drive and it loads into memory? Wouldn't you be at risk from that if you had network drive scanning turned off? That's just one example. What about if you opened a document with a virus from the LAN? One where the application doesn't copy it to %temp% first.
     
  8. ASpace

    ASpace Guest

    edwin333 , you are right . However , let's assume that all machines on the network have NOD32 installed . So , if NOD32 is installed on the machine in question , there's no way for this .exe to be infected.

    One must be insane to keep a machine in a network without (AV) protection.
     
  9. edwin3333

    edwin3333 Registered Member

    Joined:
    Aug 29, 2007
    Posts:
    244
    Yes, I am insane. I admin it. Unfortunately I'm not in an authoritative position to ban NAS devices which we have which also are incapable of running AV. I'm not in a position to force my AIX and AS/400 guys to figure out how to put Antivirus on their systems which have various network file systems. I can't prevent things like net use p: \\24.10.2.5\c$ which maps network drives over the Internet to computers I have no control over.

    But I can force the scanning of network drives. I really wish I was in your position where I could.

    I guess the thing to learn is that if the case is as you suggest, NOD or some AV is on all machines then you really are better off turning off network drive scanning if you have problems with it. But if you are in a position like mine, you take a (small) risk of infection.

    One of several reasons I switched from CA eTrust was because of the horrible performance with this option turned on and the excellent performance of Nod 2.7 with this feature on.
     
  10. ASpace

    ASpace Guest

    Ah ... OK , ok . :thumb:
     
  11. Btom

    Btom Registered Member

    Joined:
    Dec 22, 2008
    Posts:
    4
    Hello Everybody,
    First, thanks for the help and suggestions.

    I'm with Edwin on this one. I don't have total control over what people map as network drives. Therefore, I'd rather not have to turn off the scanning of network drives.

    I installed the 4.0 Beta version but still have the same problem. I tried using full UNC path--\\server\share\subfolder\subfolder\*.* and \\IP\share\subfolder\subfolder\*.* I even tried to explicitely exclude the file--\\server\share\subfolder\subfolder\myfile.ini --No Luck

    I can copy my path(\\server\share\subfolder\subfolder) into Windows Explorer and it navigates to this folder, no problems.

    The server that is exposing these shares is a Windows2003 sp2 server. This machine is a virtual server(XenServer 5.0), but I can't see why that would make a difference. The PC that has NOD32 installed has WinXP sp3.

    I don't know where to go from here. Have I somehow installed NOD32 incorrectly? Surely not. :oops:
     
  12. edwin3333

    edwin3333 Registered Member

    Joined:
    Aug 29, 2007
    Posts:
    244
    You may not like this idea, but why don't you map these as drive letters and not use UNC?

    UNC has overhead associated with it. Every connection has to do an authentication. Maping drive letters typically results in better performance.

    Using DFS, you can map one drive such as S: to \\domain.com and then have every share show up under s:\ That is what we did.

    Then you could exclude s:\parent\child\subfolder

    Anyway, that is an option.
     
  13. Rmuffler

    Rmuffler Former Eset Moderator

    Joined:
    Jun 26, 2008
    Posts:
    995
    Location:
    San Diego, CA USA
    Hello Btom,

    What program are you using to access that .ini file? Excluding that program will work.

    Thank you,
    Richard
     
  14. Btom

    Btom Registered Member

    Joined:
    Dec 22, 2008
    Posts:
    4
    Hello again,
    OK, back to basics. Now, I'm not using some other program to open my .ini file. I'm simply double-clicking it in Windows explorer.

    I have network drive L: mapped to \\server\share.
    So, in NOD32->Exclusions, I navigate to this mapped drive and drill down 2 levels where my .ini file is, and I add the filter *.* So, my exclusion in NOD32 looks like:
    L:\subfolder\subfolder\*.*

    Next, I go into Windows explorer and navigate to this folder via UNC path:
    \\server\share\subfolder\subfolder. I double-click my .ini file, and voila, it does NOT get scanned by NOD32!! So, Exclusions seem to work. However...if, in Windows explorer, I navigate to my mapped network drive, L:\subfolder\subfolder, and double-click the same file, then it DOES get scanned by NOD32. This is the problem that I've been having all along. NOD32 doesn't seem to evaluate L:\ when I double-click my .ini file from the mapped network drive. Is this the way it's supposed to work?

    Best regards,
    Tom
     
  15. Rmuffler

    Rmuffler Former Eset Moderator

    Joined:
    Jun 26, 2008
    Posts:
    995
    Location:
    San Diego, CA USA
    Hello Btom,

    I have passed this on to our engineers to look at and reproduce. I will post here when they come back to me.

    Thank you,
    Richard
     
  16. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
    Excluding mapped drives won't work, but we'll try to make excluding unc paths possible. It works for me fine, but maybe not for everyone.
     
Thread Status:
Not open for further replies.