Skip to main content

LevelBlue Completes Acquisition of Cybereason.  Learn More

LevelBlue Completes Acquisition of Cybereason.  Learn More

Services
Cyber Advisory
Managed Cloud Security
Data Security
Managed Detection & Response
Email Security
Managed Network Infrastructure Security
Exposure Management
Security Operations Platforms
Incident Readiness & Response
SpiderLabs Threat Intelligence
Solutions
BY TOPIC
Offensive Security
Solutions to maximize your security ROI
Operational Technology
End-to-end OT security
Microsoft Security
Unlock the full power of Microsoft Security
Securing the IoT Landscape
Test, monitor and secure network objects
Why LevelBlue
About Us
Awards and Accolades
LevelBlue SpiderLabs
LevelBlue Security Operations Platforms
Security Colony
Partners
Microsoft Security
Unlock the full power of Microsoft Security
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Loading...
Loading...

PRB: SWG continues to block applet after white listing

Expand / Collapse


This article applies to:

  • SWG - all versions

Description:

Secure Web Gateway (SWG) appliances are designed to scan inbound/outbound traffic and to take specific actions (allow or block) on various contents as prescribed by the security policy.

Several conditions may be used in the policy rule to trigger the action. Exceptions for general blocking rules may also be created in order to allow specific content.

The most simple and common way to create an exception is to use a URL White List, where a list of domains is maintained by the administrator.

Once content has been blocked, other actions that do not directly involve the SWG system might be required in order to allow the content to load normally on client machines.

Symptoms:

  • Users continue to see block messages from SWG after content has been white listed.

This can occur even if the white list additions have completely finished committing all all devices.   This is typically the result of additional components involved in the regular traffic flow:

Browser -> Proxy -> Server -> Proxy -> Browser

Causes:

Web content that executes in a client machine's Java Runtime Environment (JRE) adds another layer to the well-known traffic flow that was mentioned above:

Browser -> Java VM -> Proxy -> Server ….

As a result, a request made from the client machine may sometimes use the Java Virtual Machine to fetch the content from the web.

The Java Virtual Machine maintains its own cache system that is designed to enhance and to optimize web requests by serving previously stored applets from local resources, similar to a browser's cache. Therefore, a change made on the proxy layer might not be apparent at the client until the Java VM's cache is cleared.

Resolution:

To review the Java VM's caching options, open the Java item in the Control Panel.  The exact options and window design vary depending on the JRE version(s) installed on the client machine.

Click the View button to view cached objects. It is possible to delete individual objects instead of clearing all cached content by right clicking an applet, as shown below:

 

To clear the whole cache or disable Java caching altogether, click the Settings button on the main Java Control Panel window and perform the appropriate task below:

  • To remove all cached applets completely, click the Delete Files… button.
  • If there is no need to cache Java applets on this client machine – uncheck the Keep temporary files on my computer option.


To contact LevelBlue about this article or to request support:


Rate this Article:
     

Add Your Comments


Comment submission is disabled for anonymous users.
Please send feedback to Trustwave Technical Support or the Webmaster
.