7 Replies Latest reply on Dec 18, 2013 9:09 AM by Regis

    Access Protection File/folder rule whitelisting




      We recently got bombarded with pinkslip worms en accompanying droppers. Turns out this class of virusses/vectors live in the

      c:\users\<myname>\appdata\roaming\..... folder.


      We'd like to block all exe execution in the root and subfolders of "...\roaming", but then things like dropbox.exe don't work anymore.


      So we thought that the exclusion field would achieve that, as in the pic below, but it doesn't.



      What should we enter in the above fields to allow dropbox.exe to run, but refrain say 'aefqd.exe' from running ?


      edit: this is a custom Access Protection rule, file/folder based





      Message was edited by: glennrunciter on 11/28/13 4:53:57 AM CST


      Message was edited by: glennrunciter on 11/28/13 4:55:19 AM CST
        • 1. Re: Access Protection File/folder rule whitelisting



          To get the better answer, please raise the above query in the VSE forum.



          • 2. Re: Access Protection File/folder rule whitelisting

            Thx for pointing this out, I'm new here.


            And yes it turns out in VSE forum somebody else recently posted the exact same problem.

            • 3. Re: Access Protection File/folder rule whitelisting


              I too have tried a similar bock and have the same exclusion list issue which i logged  ( mine is **\*AppData*\**\*.exe )

              As some ive seen have ended up in appdata local

              I have even spoken to mcafee on the phone who fobbed me off with some excuse that it need a high and low scanning exception, I tried it anyway but didnt work


              Also noticed in the built in anit spyware max protection, the prevent programs from running from temp have built in exclusions which are also ignored


              Im sure this is a bug, are you running VSE 8.8 ?


              Im yet to find a answer, even tried going back to VSE 8.7 just to check

              The level of protection this offers us is too good to turn off but this is also stopping users getting onto citrix and webex conferences

              • 4. Re: Access Protection File/folder rule whitelisting

                We are on  VSE  |  Agent


                I'm with you, this appears to be a bug. I've tried all iterations of paths, wildcards, exclusions, even tried device path's that I had to look up with Sysinternals winobj.


                That exclusion field is dead.

                • 5. Re: Access Protection File/folder rule whitelisting

                  Hopefully the virus library write-up of this has been corrected by now (haven't checked at time of this posting but I know folks internally were looking into it a couple weeks ago).


                  You can't include paths to process objects, only the process names.

                  If you try to exclude paths your mileage will vary - it's because the product has no guarantee that path information will be available to it at the time of processing the rule. So, sometimes it may work, sometimes not.

                  Our expectation is that it won't work since there's no way for us to guarantee it will work.

                  • 6. Re: Access Protection File/folder rule whitelisting

                    Ive tried the process name down matching down to case and it still doesnt allow it

                    There is a out of the box rule under anti spyware to block exes running from temp areas, this includes exclusions set by mcafee

                    Turning that on also ignores any of the built in exclusions

                    • 7. Re: Access Protection File/folder rule whitelisting

                      I too have run into limitations in the exclusion wildcarding, and it's a shame.    If I had a specific example like this,  I'd raise it with support, get it escalated up through the chain until they give up and engineering accepts it as a bug with a BZ number, or says its working as designed...at which point your would  turn it into a product enhancement request,   harrangue your sales folks to hook you up with the product manager and find out the likelihood of the issue getting fixed.   Make sure also that there's not a newer patch level available on your product as I have vague memories that there were bugs in older patch levels on this issue.


                      McAfee Application Control  (solidcore)  may be where sales will steer you.  It flips the rather broken antivirus model on its head and allows only the apps and publishers you specify to run and does this sort of granularity much better than access control can.  You can whitelist by md5sum, by publisher, by paths with regular expressions that usually work, and things of that nature.   That said, boy is it a pain in the butt to get up and going on workstations and the admin overhead is nothing to take too lightly.  It can be done, I'm told, but it's tough sledding.  I'll let you know when I get there to declare victory.


                      I agree with you, access protection is pretty powerful and not something I like to turn off either.  We do however manage to get webex working fine, but you do have to let it fail through to where webex lets you download a standalone executable to run, and users have to get used to saving such executables out to directories without the name "temp" in them to run them.  


                      My latest hilarity with access protection:   when upgrading 8.7 p3/p4 systems,    guess what it prevents happening if say you're migrating hosts to a new ePO?   Yeah, that whole "prevent modification of McAfee files" thing is unfortunately VERY effective against Agent 4.8 pushes and VSE 8.8 installations (*face palm*).     That's right, it's so effective you can't manage to upgrade the software without first turning off AP.     But luckily agent to server communication is always perfect and it's extraordinarily hard to run into things like duplicate GUID issues should some enterprising help desk person decide to ghost an image with an agent on it, so your agents always communicate policy changes perfectly and it's alsway super easy to turn off access protection. ;-)


                      on 12/18/13 9:09:31 AM CST