Video Screencast Help

Creating Application Control Exclusions in Symantec Endpoint Protection 12.1

Created: 24 Jun 2013 • Updated: 25 Jun 2013 | 13 comments
Language Translations
Mick2009's picture
+12 12 Votes
Login to vote

Here come the ADC's...

Symantec Endpoint Protection 11 and 12.1 have a fantastic feature called Application and Device Control (ADC).  Administrators can use this optional SEP component to block an unwanted process, whether it is a suspicious/malicious application or just a tool that admins would rather not have their managed endpoints running.  It can also be used to block unauthorized devices (USB thumb drives, smartphones, and so on).  Here is an overview article about ADC:

About application and device control
Article URL http://www.symantec.com/docs/HOWTO27048 
 

SEP 12.1 brought a couple of important ADC enhancements: it can now be used with 64-bit OS's, and there is now the ability to create an exception that will apply only to ADC and leave AntiVirus Auto-Protect functioning.  This article illustrates one instance in which this new Application Control exclusion enabled SEP 12.1 to interact with a legacy software component crucial to an important customer's business.

 

An Important Warning

Please Note! ADC is a powerful security tool.  If misconfigured, it can prevent important Windows processes from executing- potentially turning computers into big, heavy paperweights.  USE APPLICATION AND DEVICE CONTROL WITH CAUTION!

 

Ask Mr. Computer Science Guy

Application Control works by injecting a Symantec library (sysfer.dll) into every process launched on controlled SEP clients. This library monitors key process function calls.  It can allow, deny and/or log process activity, depending on how the administrator has configured it.

Using the excellent Process Monitor tool from Sysinternals, it is possible to see the SYSFER.DLL module in a sample process...

SYSFER_HERE.png

Sysfer usually gets along well with other programs on a computer.  Historically, there have been some instances where there was a conflict.  As there are countless software programs developed every day by coders of mixed ability, there will doubtless be conflicts in the future.  Let me provide an example...
 

CRASH!

A legacy web application had been working for many years.  After SEP 12.1 RU2 was installed onto computers, however, it stopped functioning.  Application and Device Control was one of the SEP components deployed.  Tests confirmed that after this component was removed, the old application could function.

The Windows event logs contained Application Errors like the following:   

[date][time] Application Error Application Error win7.domain.local     1000 
Faulting application name: iexplore.exe, version: 8.0.7601.17514, time stamp: 0x4ce79912
Faulting module name: jvm.dll, version: 0.0.0.0, time stamp: 0x42527311
Exception code: 0xc0000005
Fault offset: 0x00050b58
Faulting process id: 0x6a0
Faulting application start time: 0x01ce4d5a8b411f08
Faulting application path: C:\Program Files\Internet Explorer\iexplore.exe
Faulting module path: C:\PROGRA~1\Oracle\JINITI~1.22\bin\hotspot\jvm.dll

Report Id: d403dc08-b94d-11e2-b198-0019b90b7215
 

This custom web application was built to rely upon Oracle's Jinitiator, a JVM discontinued in January 2008.  In the long term, a new web application would be written to replace it.  In the short term, though, if business was to continue it would be necessary to find a workaround- hopefully one that did not mean removing ADC from the endpoints completely.

 

Solution!

There was no way that Jinitiator could be updated as it was no longer under development.  If there was to be a way around the incompatibility, it would have to come from the SEP side.

The administrator logged into the Symantec Endpoint Protection Manager (SEPM) console and clicked on Policies, Exceptions.  A new Exception was added to the policy that was deployed to all the affected clients.  This new File Exception was created not for the module which was crashing (C:\PROGRA~1\Oracle\JINITI~1.22\bin\hotspot\jvm.dll) but created for the application which launched that module - C:\Program Files\Internet Explorer\iexplore.exe. 
 

 exception_policy_1.jpg

Note that the exception / exclusion was created for Application Control alone.  "Security Risk" and "SONAR" were not checked- meaning that there were still robust protection technologies monitoring IE and protecting it against evilness. 

Once this policy was in place on the SEP clients, the legacy application functioned and ADC was protecting every process on the computer except for Internet Explorer. 

One note: as a general security best practice, it is best not to tick “Also exclude child processes.” Check if the application works with this unticked.  

 

 

Tell Me More!  

Details on ADC and creation of exclusions can be found in the following articles:

Symantec Endpoint Protection Manager 12.1 - Application and Device Control (ADC) - Policies explained
Article URL http://www.symantec.com/docs/TECH188597 
 

Creating Centralized Exceptions Policies in the Symantec Endpoint Protection Manager 12.1
Article URL http://www.symantec.com/docs/TECH183201 
 

Excluding a file or a folder from scans
Article URL http://www.symantec.com/docs/HOWTO80920 
 

Excluding applications from application control
Article URL http://www.symantec.com/docs/HOWTO55212 
 

Best Practices for Deploying Symantec Endpoint Protection's Application and Device Control Policies
Article URL http://www.symantec.com/docs/TECH181679

How to block or allow device's in Symantec Endpoint Protection
https://www-secure.symantec.com/connect/articles/how-block-or-allow-devices-symantec-endpoint-protection
 

 

Many thanks for reading!  Please do leave comments and feedback below.

 

Comments 13 CommentsJump to latest comment

.Brian's picture

Pretty slick, thanks for posting.

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

+1
Login to vote
Ambesh_444's picture

Nice Dude.!!!!

Best of luck for next..!!!!!!!!

 

Thank& Regards,

Ambesh

"Your satisfaction is very important to us. If you find above information helpful or it has resolved your issue. Please don't forget to mark the thread as solved."

+1
Login to vote
Mick2009's picture

Here is another good illustrated KB on the subject:

How to create an Application Control exception or stop sysfer.dll injection into a process with SEP
http://www.symantec.com/docs/HOWTO95454

With thanks and best regards,

Mick

0
Login to vote
steaktornado's picture

Thanks for making your software as invasive as possible so it prevents installation of VirtualBox for developers.  You couldn't come up with something better than injecting DLLs into every process?

Thought you'd like some feedback while our sysadmin figures out how to make exceptions.

0
Login to vote
.Brian's picture

VBox runs fine for me with the full suite installed, what's the issue?

The article shows how to add the exceptions.

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

0
Login to vote
steaktornado's picture

After installing and then opening VirtualBox.  And ADC is off on my machine.

fail.jpg

0
Login to vote
.Brian's picture

What's the exact SEP version? I'm on the latest

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

0
Login to vote
.Brian's picture

You're a few versions behind so I'd have to go thru the fix notes of previous releases to see if this was a bug fix.

I believe even with ADC disabled, the dll is still injected but essentially does nothing with no policy assigned.

If you don't use ADC, you can remove the component I suppose or you can try getting on the latest version, RU4 MP1.

Again, I haven't seen this and I'm running latest vbox and SEP, I assume you're on latest vbox?

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

0
Login to vote
steaktornado's picture

Yeah, I assumed the DLL is still being injected even if the policy is off.  Our sysadmin is creating a client without the ADC component, so that should work in this case.  If not I'll let you know.

VirtualBox is latest.

0
Login to vote
TeamPcConnect's picture

We have this problem with VirtualBox 4.3.14-95030 too an d we find no solution (add exception...) to run it.  Switch back to VirtualBox 4.3.12-93733 and everything is fine...

Tested with: SEP 12.1.4013.4013, up-to-date Win 8.1

0
Login to vote
peterg4000's picture

Me too. Same problem with latest VirtualBox 4.3.14-95030 and SEP 12.1.1101.401, RU1 MP1.

Even with ADC not enabled.

I will take it from you @TeamPcConnect that there is no work-around, and I am hosed for this night.

Unfortunately was moving from VirtBox 4.3.12 to try to get around a problem. Now I have 2 versions that both don't work. Great...

Why, oh why, oh why doesn't disabling (or even exception-ing) ADC stop the dll injection? Wouldn't that be eminently sensible?

P.S. Exact same screen shot for me as @steaktornado.

Given the title of the Window, this would appear to be VirtualBox doing it's own protection against 'bad guys', and unfortunately detecting SEP ADC in 'no-op' mode. (An injected DLL is suspicious no matter which way you look at it...)

EDIT: In fact, confirmed as much at this very active thread at the VirtualBoc forums: (Follow the link therein)

https://forums.virtualbox.org/viewtopic.php?f=25&t=62618

 

0
Login to vote
bghote's picture

Me too, too.

I've attempted installing VirtualBox-4.3.14-95030-Win on separate Win 7 Pro and Windows 8 (8, not 8.1) systems.  Both systems give errors concerning SEP12 Application and Device Protection.  Only "solution" working for me until now is to downgrade to VirtualBox-4.3.12-93733-Win.

 

0
Login to vote