1 2 Previous Next 10 Replies Latest reply on Dec 29, 2009 1:21 PM by dmeier

    Access Protection Policy...Remote creation/modification

      We recently needed to enable the "Prevent remote creation/modification of executable and configuration files" rule to stop a spreading virus.  I would like to keep this rule on but it is causing a lot of problems with legitamte .ini files being able to be written.  It provides the ini file in the Access Protection log.  In the Policy it has system:remote in the include field and nothing in the exclude field.  Since the exclude field is looking for a process, how can I get it to allow certain .ini files to be written without knowing the process? or can I add .ini files to his field.


      Here is an example of the access protection log.


      12/23/2009 10:58:12 AM Blocked by Access Protection rule  domain\username System:Remote E:\DFS Shares\Home\username\Application Data\Fujitsu\Fjtwain\FJTW0402.INI Anti-virus Standard Protection:Prevent remote creation/modification of executable and configuration files Action blocked : Write


      We are using ePo 4.0 and VS8.5i.



        • 1. Re: Access Protection Policy...Remote creation/modification

          I do not believe this is possible; however, this query belongs in the VSE community.

          • 2. Re: Access Protection Policy...Remote creation/modification

            I did move this to Virusscan per your recommendation.  I find it hard to believe that McAfee would bundle the prevention of executable and configuration files into one policy without the ability to exclude certain configuration files.  If that was the case it should be two separate entries.  Has anyone else had any experience in this area?

            • 3. Re: Access Protection Policy...Remote creation/modification

              Well thats why I indicated the query should be moved to VSE someone in this community can provide you with a better answer. If it is a file you want to exclude (as opposed to a process) you could try adding the exclusion to the VSE On-access default process policy. I believe that access protection rules obey the OAS exclusions but I could be wrong. I know if the OAS is disabled access protection rules stop working so that is what I'm basing this assumption on.

              • 4. Re: Access Protection Policy...Remote creation/modification

                Good point.  I performed a quick test by excluding .ini files in the on access scanner and found that the Access Protection is still blocking the modification of ini files.  Unfortunately, it seems the On Access policy does not carry over into the Access Protection policy.

                • 5. Re: Access Protection Policy...Remote creation/modification

                  Exactly right, OAS configurations, are completely separate from Access Protection configurations.

                  • 6. Re: Access Protection Policy...Remote creation/modification

                    When McShield  (OAS) is stopped, it stops all of our VSE processes.  That is why you saw AP disable as well.  However, an OAS exclusion, is separate from AP exclusions.


                    Hope it helps.

                    • 7. Re: Access Protection Policy...Remote creation/modification

                      So the original question still exists, is there a way to exclude certian configuration files like .ini files from the AP policy?  This specific option in the policy I need to for the executable protection but it causes a lot of other issues with config files like dll and ini files.  Roaming users is broken because ntuser.ini can not be written for example.

                      • 8. Re: Access Protection Policy...Remote creation/modification

                        Sorry to work up this thread from the bottom


                        So the process would pretty much always be something like svchost, or lsass, or something, since we are talking about remote connections coming into this system.


                        While you can prevent modification of the ini, exclusions would probably just circumvent that rule, since it's likely one particular process everytime.


                        Does that even make sense?


                        This situation depends on what your legitimate apps are going to do, versus potential malware....


                        So if you have local apps that need to modify the ini files, you could place those processes in the exclusion field, and still block "remote" changes.  (what we would expect malware to do).   However, if your app needs to make changes over the network, then it will always show up as "System:Remote", just the same as malware, and there would be no way to decern malware from the legit application.  In which case, the AP rule might not be usable in your environment.


                        We should probably get more information about what your legit apps will need to do, and see if there is a way to allow the expected "good" apps, and block all others. It's not always possible though.


                        Let us know if we need to go further.



                        • 9. Re: Access Protection Policy...Remote creation/modification

                          Many of our users have redirected Application Data that resides in thier home directories on a server.  The applications that are installed on the workstations sometimes keep data in the Application data folder on the server.  One example is in the first post.  This is caused by scanner software installed on the workstation that keeps ini files in Application data.  Another example is RUP (Roaming User Profiles).  The RUP folder is also kept in thier home directories and ntuser.ini cannot be modified.  Our solution thus far has been to stop redirecting Application Data and recreate the profiles locally on the workstations.  This is a slow and painful process as not all users only use one machine so we need to remove all local profiles from every machine they have used in the past.  So in short, all of our problems are caused from applications on the PC trying to write files to a server and therefore seen as Remote:System.  It is sounding like there is not a soluion but any suggestions would be appreciated.

                          1 2 Previous Next