Endpoint Protection

Hello,

Our agency uses SCCM and HPCA / HPSA for application deployment.  Because of a recent virus attack that utilizes autorun.inf, we have created an Application & Device control policy for our SEP clients  following this link: http://www.symantec.com/business/support/index?page=content&id=TECH104909

 

The policy works as expected, however now our deployment software is not able to install software on the clients.  We can make exceptions for setup.exe or install.exe but that beats the purpose of having this policy enabled in the first place.  What would be the suggested way of making sure that autorun.inf is blocked at the same time, we can still use our deployment software to manage installs on the client?

 

Thank you,

Adam.

Did you use the exact policy that is in the link?

Looking at the policy, it only block the autorun.inf file, nothing else.

Does the package your sending to clients include an autirun.inf file? If so, this is likely why the install is failing.

Can you just delete the file from the package?

Thank you. Yes we used the same exact file from the link. we download the .dat file and imported it. Most of the installation packages uses autorun.inf and deleting it from the package is not practical for us I am afraid. I have attached a screenshot for reference.

Under All Application, select the Autorun.inf option

Select *\*\*\Autorun.inf (enable drive types) and hit Edit

Under Only match files on the following drives types, uncheck Network drive and re-test

Just know this now allows autorun.inf across network shares, not sure if this is what you want though or are OK with doing this.

Not sure of another option besides this or deleting the autorun.inf file from the package.

 

 

Thank you. Yes that would be a solution but the main reason we are blocking autorun.inf is because our network shares got infected. Thank you for your suggestion , I will still pursue for another option if it exists.

You can create a custom autorun.inf file and place on the root of the shares as a workaround. See this KB article:

How to prevent Autorun.inf files being copied or written to network file shares

Article:TECH131807

|

Created: 2010-01-19

|

Updated: 2012-03-07

|

Article URL http://www.symantec.com/docs/TECH131807

 

We already have this in place. Still the autorun is blocked for new installs.

No I meant uncheck Network drive in the ADC policy and use this as well.

But since you're using this, you can uncheck the network drive piece in the ADC policy as you will still be protected across the network while allowing application deployment.

That is not a bad idea, however the way I understand deployment software to works is that it copies the executable sometimes even a folder down to the local machine, then extracts the package which has an autorun.ini in it, then installs it. This is where I believe we will run in to the problem.

If you want to protect your systems from an autorun.inf that links to malware than you only need to block explorer.exe from reading autorun.inf.  Only explorer.exe will run processes listed in the autorun.inf.  Your software installers should still function correctly because only explorer.exe is blocked from accessing these files not the installers.

If you want to stop the autorun.inf files from writing to your network drives then you can create a rule to block all programs from writing autorun.inf files to network drives.  This should still allow your installers to run correctly since they should be reading the autorun.inf file from the network, not writing it to the network.

If you want to do both, protect your systems from autorun.inf files that link to malware and stop programs from writing autorun.inf files to your network then you can create two rules.  One rule that blocks explorer.exe from reading autorun.inf and another rule that stops any application from writing autorun,inf to a network drive.  I have attached a sample Application and Device Control policy that does this.  I modified rule [AC9] from the default SEP 12.1 RU2 ruleset.

Thank you Elisha. What you suggested above worked and makes sense. I downloaded your policy and tested it, behaved as described above. Brian, Thank you for all your help as well. Adam.