LevelBlue Knowledge Base » Knowledgebase » Legacy Products » Secure Web Gateway » Security Policies

How to bypass Authentication by header

Charles — Mon, 27 Apr 2015 15:17:40 GMT

This article applies to:

SWG 9.x
SWG 10.x

Question:

Some sites or programs require you to bypass Authentication in order for it to be accessed through the SWG appliance. For Example, Google Earth’s update mechanism will not allow the program to run if it cannot contact its host site, and the host site cannot be reached when using Authentication through the SWG.

Procedure:

To bypass authentication for our Google Earth example, we will bypass using the User-Agent header that Google Earth uses to access its host site.

-Navigate to Polices -> Condition Settings -> Header Fields

-Under Exclude by Headers click edit and enter the following information.

Header Name:

Condition:

Header Value:

- Save and Commit changes.

*note: in VSOS 9.0.0 you cannot add more than one user agent header name to the same Headers Field list. If you need to add more than one user agent you will need to create a separate list for each user agent entry.

-Other programs and hardware have been known to need to have authentication bypassed in order to be used. Here is the program and the Header name used to allow access.

Application	Header	Value	Expression
Google Earth	User-Agent	Regular Expression	^GoogleEarth.*
iPhone	User-Agent	Regular Expression	Apple iPhone.*
iPad	User-Agent	Regular Expression	Apple iPad.*
iTunes	User-Agent	Regular Expression	iTunes/.*
-	-	-	AppleCoreMedia/.*
Microsoft Updates	User-Agent	Equals	Windows-Update-Agent
-	-	Regular Expression	^MicrosoftBITS/.*
Adobe Flash	User-Agent	Regular Expression	^Adobe Flash Update.*

How to make sure that JAR Files are scanned for threats

ofer Kalef — Tue, 11 Feb 2014 01:26:15 GMT

This article applies to:

SWG 10.x
SWG 11.x

Question:

How to make sure that JAR Files are scanned for threats

Information:

If your security policy requires the scanning of JAR files, make sure that these rules are applied:

Block Known Viruses (Kaspersky / Mcafee / Sophos)
Block Spoofed Content
Block Known Malicious Content

Notes:

Make sure that these rules appear before others that may allow files without scanning.

Allow (bypass) Audio Streaming through SWG

ofer Kalef — Tue, 24 Sep 2013 08:21:13 GMT

This article applies to:

SWG 10.x
SWG 11.x

Question:

Audio streams (e.g. Web Radio) do not work through the SWG, and there are no log entries.
I have an "Allow Streaming" rule, but audio streaming does not work and the logs don't show anything being Blocked.

Procedure:

Audio streaming formats are not included in "Allow streaming" rule by default.

In order to allow (actually, to bypass) these formats, modify the rule conditions by selecting 'Audio File' as shown below:

Malware Entrapment Profile levels as shown in the weblogs

ofer Kalef — Sun, 15 Sep 2013 01:17:30 GMT

This article applies to:

SWG v10.1 and above

Question:

Malware Entrapment Profile level is set to Strict, however, transaction shows Basic, Medium and Strict levels. Why?
Malware Entrapment Profile is blocking too much/little content. Can I adjust it?

Information:

As of SWG 10.1, the User Interface allows adjustment of Malware Entrapment Profile (MEP) security level. To do this, highlight the Malware Entrapment Profile condition in the "Block Malicious Content (Malware Entrapment Engine)" Rule and set its level as desired in the right pane, as shown below:

Web content will be blocked by MEP up to and including the specified threshold, e.g. if set to Medium, content is blocked if it breaks Basic or Medium. The transaction log will show what MEP level was reached, so if MEP is set to Strict the transaction logs will show Basic, Medium and Strict entries.

Note that if the Logging Policy is set to log more than Blocked/Corrective actions (e.g. "Log everything except images"), then the logs will show MEP levels for traffic that was not blocked, indicating that the Entrapper engine was called but allowed the traffic, as shown in green below:

Notes:

None.

Incorrect Policy enforcement for Windows 7 / Windows Vista users due to the NCSI feature

ofer Kalef — Mon, 19 Aug 2013 06:35:52 GMT

This article applies to:

SWG 10.x
SWG 11.x
Users running Microsoft Windows Vista or Microsoft Windows 7

Symptoms:

Symptoms may vary depending on SWG identification implementation.

In some cases, when the user first boots into the Windows OS they get a message from Microsoft Networking with a yellow exclamation icon in the system tray.

The error message that opens is "No Internet Access".

The yellow exclamation icon goes away as soon as the user opens Internet Explorer.

Another variation is that the users are identified as Unknown Users, and as a result the incorrect security policy is enforced for such users.

This can be verified in the Web Logs view showing Authenticated User Names containing '$' signs:

Causes:

This behavior is unique to Window Vista and Windows 7 OS versions after the Network Connectivity Status Indicator (NCSI) feature was introduced in Windows Vista.
NCSI is designed to be responsive to network conditions, so it examines the connectivity of a network in a variety of ways. Once a test fails, NCSI may report an error, even if the network can actually be fully accessed.
For example, NCSI tests connectivity by trying to connect to http://www.msftncsi.com, a simple website that exists only to support the functionality of NCSI.

Try to manually visit the website http://www.msftncsi.com/ncsi.txt. You should see “Microsoft NCSI”:

A proxy server requiring user authentication won't allow it to access the Internet.

Resolution:

There are two ways to resolve this issue:

1. By bypassing *.msftncsi.com/* for Authentication purposes.

2. By modifying registry settings to disable the NCSI functionality:

- Run regedit (administrative permission is required)

- Navigate to the following key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\NlaSvc\Parameters\Internet\

- Locate EnableActiveProbing parameter

- Allowed values: 1 - Enable NCSI, 0 - Disable NCSI

These registry settings can be distributed globally as part of the Group Policy push from the Domain Controller.

What is the longest URL that could be added to the URL list?

ofer Kalef — Fri, 19 Jul 2013 01:31:38 GMT

This article applies to:

SWG 10.x

Question:

URL list entry - what is the limit on the URL length ?

Information:

The following error message could show up when adding a very long URL:

When adding a URL from the logs section, the error message would be different:

Every URL list entry is a name stored in the DB being the same as the URL itself
This name field in the DB is limited to 192 chars.

If needed there are ways to extend this field manually, however, these changes are not recommended.

Our recommendation for such URLs is to use a RegEx entry with a wildcard: domain_name*file_name .

Signing CSR request and importing certificate for the scanner

ofer Kalef — Tue, 29 Jan 2013 23:59:01 GMT

This article applies to:

SWG v10.0
SWG v10.1

Question:

This article describes detailed instructions on how to:

Generate CSR request for Scanning Server using Trustwave SWG Web interface
Submit CSR request data using MS PKI Web interface
Import certificate information into Trustwave SWG Scanning Server

Procedure:

1. Navigate to the Devices section in Trustwave SWG GUI, right-click the HTTPS module on the scanner and choose Generate Certificate option:

2. Choose CSR Certificate Type in the right pane and fill in all relevant details:

3. System responds with "Operation Succeeded" message, with the CSR request data in the background. Click OK and copy CSR data as simple text data.

4. Commit the changes. Do not create new CSR requests for other devices managed under same Policy Server.

5. Navigate to the MS-PKI Web GUI and select "Request a certificate" task:

6. Submit advanced certificate request:

7. Choose the option to submit CSR by using a base-64-encoded CMC or PKCS#10 file:

8. Paste CSR data that was copied in step 3 above.

Before submitting a request make sure Certificate Template is set to use Subordinate Certification Authority and "CA:TRUE" is set as Additional Attribute.

9. Select Base 64 encoded option and download certificate:

10. Save the certificate on your system:

11. Open this certificate using text editor and copy the data as simple text data:

12. Navigate to the Devices section in Trustwave SWG GUI, right-click the HTTPS module on the scanner and choose Import Certificate option:

13. Choose CSR Certificate Type in the right pane and paste in certificate data that was copied in step 10 above:

14. Commit changes. Certificate can now be exported from the device.

If required to sign CSR certificate for more than one scanning server, it is important to perform above steps as separate procedure for every device.

How To Exclude Web Applications From the Authentication Mechanism

Rudolf Kessler — Fri, 31 Aug 2012 07:06:10 GMT

Description
Some web applications (such as Citrix Webmeeting) get stuck due to authentication requests which can not be handled by such applications.
This article describes how to exclude them from authentication mechanism.

Symptoms
Example:
Citrix Webmeeting gets stuck, or the connection setup wizard does not succeed.

Cause
An authentication request is sent to the client in a later session stage, but the application cannot handle it correctly.

Solution
The solution is to exclude this application / site from authentication mechanism.

Drawback: The client is not authenticated or identified anymore and the policy for unknown users is applied.

1. Step: Create a list of URLs you want to exclude (It might be necessary to do a packet trace and analyze the destination URLs)

2. Step: add a condition to your authentication policy (it might be different from this example):

Note: This condition is based on URLs, basically other conditions such as header fields are also possible - it depends on the needs.

Step 3: Commit your changes

Note: This option applies also to other identification policies (IP, Basic)

Software Version
9.x

This article applies to:: NG 1000; NG 5000; NG 6000; NG 8000

This article was previously published as:

Finjan KB 1810

How can I block java

Rudolf Kessler — Thu, 30 Aug 2012 02:01:54 GMT

This article applies to:

SWG 10.x, 11.x

Question:

How can I block java traffic?

Reply:

SWG blocks requests/content based on its properties. Thus it cannot block java as a whole but perhaps based on its behavior.

Since java uses .class files you can add a rule to block File Extension .class files and you can also add a rule to block Content Type "Java Class".

SFG data mechanism and the use of 'Bypassed Context Scanning List' in SWG 10.x

Rudolf Kessler — Wed, 29 Aug 2012 01:47:01 GMT

This article applies to:

SWG 10.x

Question:

SWG 10.1 comes with a new Scan Engine (Entrapper). Is the SFG Data Mechanism and the "Bypassed Context Scanning List" still in use?

Reply:

Inserting SFG Data tags to the page code was necessary in order to track and analyze a site in full context. If any problems occured with this, the solution was to add a site to the "Bypassed Context Scanning List".

SFG data is still being used in the product but in less scenarios than before. For example java scripts are no longer marked with SFG since Entrapper (the new scan engine) now does pre-fetching, however, will still add SFG tags to java applets.

Due to the above, the need for this list has dramatically decreased but we still want to keep this functionality for other scenarios in case it creates a problem in the page.

Notes:

INFO: Changes to Dynamic Web Repair

Rudolf Kessler — Wed, 20 Jun 2012 05:45:55 GMT

This article applies to:

Secure Web Gateway

Question:

What are the changes in SWG Dynamic Web Repair in versions 10.2 and above?

Reply:

· Prior to the launch of the Malware Entrapment Engine (before 10.1) some of the MCRC rules had a fix up which was applied once the page was identified as malicious or suspected as malicious. Nevertheless, there are still some rules in the Malware Entrapment Engine that have such a fix up today for versions 10.1 and onwards, but in a much limited scope.

We do still maintain those rules for the 9.2 and 10.0 installations, and the fix ups are being distributed through security updates.
As the Malware Entrapment engine is so much more accurate the need to repair significantly decreased.

The way the system scans IFRAMEs on a single page as a separate component and blocks them did not change.

How to allow iTunes radio stations streaming contents

Rudolf Kessler — Thu, 24 May 2012 01:42:48 GMT

This article applies to:

SWG 10.x

Question:

iTunes radio stations do not function properly with default security policy. With few changes listed below you could allow these contents through SWG proxy.

Procedure:

First, it is possible that current security policy blocks initial requests for iTunes radio stations. All iTunes radio stations are being launched as PLS file, with further connection to a remote server.

This file extension is listed among M86 Recommended Forbidden File Extensions.

Review SWG web logs to validate if there are any blocks of Block Forbidden Extensions rule.

If there are no blocks of this kind, continue with below article to modify the settings to allow iTunes radio station contents.
If there are blocks of PLS file extension, make sure your security policy is set to allow PLS files.

iTunes radio stations are streaming audio contents over the web, and it have to be allowed to stream contents in the same fashion that SWG allows video streaming.

Refer to the Allow Streaming rule in your security policy and make sure that Audio File True Content Type is checked as shown below:

It is also possible that some audio streaming would be using a custom Content-Type that would have to be allowed in a different way.

1. First, find out what these Content-Types are. This could be found in a network capture collected when a proxy was requested to deliver these streams.

Refer to Notes section below to find a KB on how to collect tcpdump network captures on a SWG device:

Below example shows typical responses from the web server:

Note that SWG identifies above Content-Types as Audio File True Content Types, here it is only being used for demonstration purposes.

2. Navigate to the GUI section: Policy -> Condition Settings -> Header Fields, and create new Header Fields list, Audio Streaming, as shown below:

3. Edit this Header Fields list to include the following two entries for above Content-Types:

4. Navigate to the GUI section: Policy -> Security -> Advanced and review current security policy.

Create new rule to Allow Streaming Contents based on Content-Types, and refer to the Header Fields list created in step 3:

Just as with default Allow Streaming rule in M86 Security policies, make sure that this new rule is set with Advanced Action to Bypass Scanning and is located on top of the policy:

Save and commit the changes.

Notes:

KB - How to run tcpdump trace on SWG device - https://support.levelblue.com/kb/KnowledgebaseArticle14333.aspx

How to block Remote Access clients

Rudolf Kessler — Mon, 14 May 2012 02:03:57 GMT

This article applies to:

SWG 9.x
SWG 10.0

Question:

I want to block remote access clients, like TeamviewerQS (Quick Support), but the URL Category "Remote Access" is not available with all URL Cat filters. Remote support web sites should not be blocked in general.
It is not practical to block these requests based on destination URLs or IP addresses.
These clients often use tunneled connections (such as TCP 443) which cannot be blocked in general.
HTTP methods (e.g. CONNECT) are not available as conditions in SWG versions below 10.1.

Procedure:

Remote access clients often don't use a browser, but do use HTTP as a protocol. To block or control these connections, it is necessary to identify a specific criterion based on the content of the connection.

Example: TeamviewerQS

Step 1: Trace a successful connection

Identify a unique feature of the connection. In this case you can use the User Agent string: "User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; DynGate)".

Step 2: Create a Condition and a rule to block

In the SWG interface, navigate to Policies > Condition Settings > Header Fields, and add a new component, e.g. "Blocked User Agents":

Create a Blocking Rule using this condition:

Step 3: Test the connection request

The requests should now fail, and the reason can be seen by tracing the network stream:

Notes:

This procedure can be used to block many proprietary clients in a flexible and granular way. It is not limited to Remote Access clients.

What is the policy assignment order?

Rudolf Kessler — Fri, 27 Apr 2012 00:41:00 GMT

Question
What is the policy assignment order for a User Group/User in Trustwave Secure Web Gateway appliance?

Answer

The policy assignment in Trustwave Secure Web Gateway appliance is as follows:

The Local Users are being evaluated according to their respective username IP address. Please note that the Local Users are referred to as Independent Users in version 9.x/10.x.
The Local Groups are being evaluated according to their set IP range.
The imported LDAP users, which are associated with their relevant LDAP groups are then evaluated.
The Unknown LDAP Users is then used, which may result due to unknown user which was imported to the SWG appliance as part of the LDAP objects, but is currently not associated with an LDAP group.
Lastly, if all the above are not relevant, the Unknown Users group is then used, which means users that are completely unrecognized by the system.

Software Version
9.x.x
10.x

This article applies to:: SWG 3000; SWG 5000; SWG 7000
This article was previously published as:: Finjan KB 1521

PDF files blocked due to "Container violation : Invalid format"

Rudolf Kessler — Mon, 27 Feb 2012 05:21:46 GMT

This article applies to:

SWG 10.1.2

Symptoms:

Some PDF files are being blocked with the following error: Container violation: Invalid format

Causes:

The PDF file is being blocked by the Rule "Block Illegitimate Archives (Including Password-Protected Archives)"

Resolution:

Add a "True Content Type" Condition to the "Block Illegitimate Archives (Including Password-Protected Archives)" Rule, negate it by selecting the "Everything except for the items selected below" Applies To radio button, select "PDF File" as file type, and then Commit the change.

Allow Content and Scan Containers Explanation

Rudolf Kessler — Fri, 17 Feb 2012 06:02:56 GMT

This article applies to:

SWG Versions 8.5.0,9.0, 9.2.0, 9.2.5, and 10.0

Question:

What is meant by the Advanced Action "Allow content and Scan containers" when used in conjunction with “Allow” when creating a new rule in a policy?

Information:

When creating a rule in any policy there is the ability to "Allow" but this can have different methods attached it using “Advanced Action”. One method specifically is "Allow Content and Scan Containers".

The first part to clarify is that a "Container" in SWG jargon stands for a Super-set of compressed archives such as ZIP, RAR, TAR, CAB, BZIP2, GZIP and others which are not archives specifically such as MIME containers (used in email format and used for HTML forms files. As well as 'whole page save' when using IE - using .MHT as the file to save to) or CHM container (compressed HTML help files, used by MS products).

What happens when using the "Allow content and Scan containers" Advanced Action:

When content reaches a rule using the "Action" "Allow content and Scan Containers" it will stop the Policy evaluation on this rule (meaning no more rules will be used to evaluate that page after the current rule), but if the content is a container the system will extract all the items held in the container. The scanner will then evaluate every file in the container using the Policy that has been assigned to that user until the evaluation is complete.

Where the content is not an archive or container (as would be the case with most web content) the action is simply equivalent to “Allow” without any further scanning.

Skype Blocking - 9.0 Technical Brief

Rudolf Kessler — Tue, 19 Jul 2011 05:52:19 GMT

This article applies to:: NG 1000; NG 5000; NG 6000; NG 8000

This article was previously published as:

Finjan KB 1740

How do I prevent my URL blacklist from being bypassed by browsing to the site IP address

Rudolf Kessler — Mon, 18 Jul 2011 08:48:33 GMT

This article applies to:

SWG 10.0 and above

Question:

When we block a site (e.g. www.acme.com) the user can browse to the site IP (e.g. 1.1.1.1) and bypass our custom defined block list, how do I prevent this ?

Procedure:

Make sure you have SWG 10.0 or above
The Device IP Advanced tab allows administrators to enable the Reverse DNS lookup option, to determine the domain name that is associated with

a given IP address (using DNS).
Click Edit and check the Enable Reverse DNS box.
Click Save, then Commit changes.

How to download files larger than 1 GB through the Finjan

Rudolf Kessler — Tue, 25 Jan 2011 07:41:54 GMT

Description

There is a hard coded limitation of 1 GB filesize.

Symptoms

If a file that is larger than 1 GB is requested by the client through the Finjan, the proxy will return an error:

Error Occurred
HTTP Error Status: 403 Forbidden
Error Reason: Response body too large Please contact your system administrator

Without a reason being given in the web log.

Cause

The largest file-size that is limited to traverse through the Finjan is 1 GB. This limit is hard coded and can not be increased through the GUI.

Solution

In order to circumvent this issue, please follow the steps below:

1. Create a header fields list (please note the correct header name "Content-Length"):

Define a header value of ~ 1 GB (in Bytes, e.g. "1048576000"):

2. Create a rule using the header list as a condition:

NOTE: This will not work if the server does not reply with correct headers, such as in the example below:

Software Version
9.0
9.2

This article applies to:

NG 1000

NG 5000

NG 6000

NG 8000

This article was previously published as:

Finjan KB 1815

Blocking Insecure Library Loading with SWG

Eric Hanson — Thu, 23 Sep 2010 16:22:19 GMT

This article applies to:

Secure Web Gateway 9.x

Question:

Does Trustwave SWG protect against the insecure library loading vulnerability?
- SA 2269637

Answer:

The vulnerability described in Microsoft Security Advisory 2269637, involves using a legitimate application to preload malicious library files from remote sources, including SMB shares and WebDAV. For example, an audio/video player application might be tricked into loading malware that poses as a codec DLL. This technique is sometimes called “DLL hijacking”.

Although SMB falls outside of the scope of secure web gateway solutions, SWG appliances can prevent client applications from using WebDAV to retrieve malicious libraries from the Internet. By default, SWG appliances include a rule named Block Binary Objects without a Digital Certificate. Since malware authors do not sign their code, this rule by itself blocks exploits based on this vulnerability.

In some environments, it is preferable to permit downloading of unsigned binaries, so the Block Binary Objects without a Digital Certificate rule is sometimes disabled or placed in X-Ray mode. In this situation, it is still possible to define a policy that prevents attempts to exploit this vulnerability via WebDAV. Doing so involves preventing WebDAV downloads of .dll and .ocx files. The procedure for creating the appropriate lists and rule is detailed below.

Log in to the SWG web interface.
Navigate to Policies -> Condition Settings -> File Extensions.
Right-click the File Extensions folder and select Add Component.
Define a name for the new list.
Click the green + to add an entry. The value for the entry should be: dll
Click the green + to add an entry. The value for the entry should be: ocx
Click the Save button. The screenshot below illustrates the new entry.
Navigate to Policies -> Condition Settings -> Header Fields.
Right-click the Header Fields folder and select Add Component.
Define a name for the new list, and click the green + to add an entry. The values for the entry should be:
Header Name: User-Agent
Condition: Regular Expression
Header Value: .*Microsoft-WebDAV.*
Click the Save button. The screenshot below illustrates the new entry.
Navigate to Polices -> Security -> Advanced and expand the tree so that the rules under the active security policy are visible.
Right-click the rule above which the new rule will be inserted. For policies based on the Finjan Medium Security Policy, the new rule will typically be inserted above Allow Whitelisted ActiveX, Java Applets and Executables.
Choose the Insert New Rule option.
Define a name for the rule, make sure that the Action is set to Block and an appropriate End-User message is selected.
Click Save.
Right-click the new rule and click Add Condition.
In the Condition Name picklist, select File Extensions. Select the checkbox for the new File Extensions list that you created, and click Save.
Right-click the new rule and click Add Condition again.
In the Condition Name picklist, select Header Fields. Select the checkbox for the new Header Fields list that you created, and click Save.
If you click on the new rule name in the left pane, it should appear similar to the screenshot below. If this is the case, please commit the changes.

Notes:

If more than one policy is in use, it will be necessary to repeat Steps 13 – 20 for each policy that should include this rule. Please commit when all of the modifications are finished.
Some sites might have legitimate reasons for accessing DLL and OCX files via WebDAV. Exceptions can be implemented on a case-by-case basis by using other policy elements, such as URL Lists.

SWG continues to block applet after white listing

Eric Hanson — Tue, 14 Sep 2010 17:39:32 GMT

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.

Allowing logins to Yahoo Mail via SWG

Eric Hanson — Fri, 18 Jun 2010 16:40:00 GMT

Description:
In some environments, it is necessary to reconfigure the Secure Web Gateway (SWG) Download Status Page so that users can access Yahoo Mail.

Symptoms:
When a user tries to access Yahoo Mail while proxying through a SWG appliance, the following text could appear in the user’s browser:

Ooops. Yahoo! Mail can't load.
Loading Yahoo! Mail failed due to a client side error.

When the administrator reviews the Web Logs on the appliance, they will not see any blocks that are related to the Yahoo Mail session.

Cause:
These symptoms occur when a script that is downloaded from the Yahoo Mail site is not received by the browser. Yahoo Mail uses a JavaScript file that is over 800 KB in size, which is atypically large for a web-based script. In order to inform users that a file is downloading and being scanned, SWG appliances usually send a Download Status Page to the browser when retrieving files that are over 512 KB in size. In the case of Yahoo Mail, the browser displays an error because it is expecting to receive a script but it receives the HTML-based Download Status Page instead.

Solution:
There are two ways to address this without disabling any scanning functionality for the Yahoo Mail site. Both involve adjusting the status page’s configuration. Either option is sufficient by itself. There is no need to do both, although it is certainly possible to do both.

Option 1
Increase the status page’s “Size Threshold for Immediate Activation”. Below are the locations that this setting can be found in different VSOS versions.

VSOS 8.x setting location: Settings -> Miscellaneous -> Status Page

VSOS 9.x setting location: Administration -> System Settings -> Scanning Options -> General Settings

Note - In order for this change to be effective the threshold must be increased beyond the size of the script file. For example, 1024 KB has tested successfully with Yahoo Mail. This will disable the status page for all downloads under 1 MB. With most high speed Internet connections, this should be fine. This might only cause some consternation amongst users if they are downloading a file that is almost 1 MB from a very slow site. In any case, there is a second status page configuration option that activates the status page if a download takes over 5 seconds, so users will not have to wait long for a response.

Option 2
Disable the status page for JavaScript files.

VSOS 8.x configuration: Append “, x-javascript” (without the quotes) to the contents of the “Don't Activate if Content Type includes following Substrings” field at Settings -> Miscellaneous -> Status Page.

VSOS 9.x configuration: Navigate to Administration -> System Settings -> Scanning Options -> Activate, click Edit, click the green + in the Unless box, choose “Mime Type Contains”, and enter “x-javascript” (without the quotes).

Notes - When the status page is disabled for JavaScript downloads, a user who tries to manually download a large, individual JavaScript file (instead of the browser retrieving it as part of a web page) may experience a delay if they are communicating with a slow server. However, it is very unusual for a user to download individual JavaScript files manually.

Please be sure to Apply/Save and Commit any changes before retesting access to Yahoo Mail. Please wait for the commit to finish completely. It is also important to close any open browser windows and clear the browser’s cache.

Software Versions:
8.x
9.x

Streaming MP4 files via SWG

Eric Hanson — Mon, 14 Jun 2010 18:15:00 GMT

Description:
In order to play certain videos, MP4 files must be allowed to stream through Secure Web Gateway (SWG) appliances running system version 9.2 and below.

Symptoms:
When trying to play a video, the content will not load. The video player might indicate that it is still trying to load the video, or it could display an error. The logs on the SWG appliance will not indicate that any content was blocked.

Cause:
Symptoms like those described above are usually the result of the video being in a format that doesn’t stream by default on the SWG system. In particular, MP4 files are becoming more common, and YouTube has started using this file format for their high definition videos. Although SWG system version 9.2.5 streams MP4 files by default, earlier versions do not do this.

Solution:
In order to allow content to stream to the client, that content must bypass SWG appliance’s scanning mechanisms. If the administrator only wants to allow the content from a particular site, this is typically accomplished by adding the video’s address to the Trusted Sites URL List. Please note that the video might be hosted on a different site than the one that appears in the browser’s address bar while the video is playing. If the administrator would prefer to allow all MP4 files from all web sites, this can be accomplished by following the steps below.

In the Vital Security web interface, navigate to Policies -> Condition Settings -> Header Fields.
Right-click on the Header Fields folder in the left pane and left-click on Add Component.
In the Name field, enter a name to describe this list. Since the list will be used for MP4 files, a simple name like “MP4 Files” is recommended.
Click the green + icon to add an entry to the list. Define the entry as indicated below (please match the capitalization exactly):

Header Name: Content-Type
Condition: Equal
Header Value: video/mp4
Click the Save button.
Navigate to the security policy (Policies -> Security -> Advanced) that will be configured to allow MP4 files. Please note that this must be a custom security policy, since the built-in security policies are not editable. It is possible to duplicate a built-in security policy and use it as the basis for a custom security policy by right-clicking the policy to be duplicated and choosing the Duplicate Policy option.
Right-click the Allow Streaming rule and choose the Insert New Rule option.
Define a name for the rule in the Rule Name field. An example rule name would be “Allow MP4 Files”.
Select "Allow" in the Action field and select "Bypass scanning" in the Advanced Action field.
Click the Save button.
Right-click the new rule and select the Add Condition option.
In the Condition Name field, select Header Fields
In the list of checkboxes, select the new header fields list that was created in Step 3 above.
Click the Save button.
Right-click the new rule and select the Add Condition option.
In the Condition Name field, select True Content Type.
In the list of checkboxes, select Video Image.
Click the Save button.
If this policy is already assigned to users, commit the change. Otherwise, it might be necessary to assign the policy to users before committing.

Software Versions:
9.0
9.2

Why a Security Policy Might Appear to Be Ineffective - Caching and Multiple Hosts - Internal

Peleg Samson — Wed, 03 Feb 2010 06:10:00 GMT

Description
In some cases, the security policy on a Finjan system might appear to be ineffective. This can be noticed after a recent policy change or after first deploying a Finjan solution.

Symptoms
Common symptoms include:

Content that should be blocked is downloadable by a browser.
Images or text content might be missing from an allowed page.
A script error might be indicated in the lower left corner of the browser on an allowed page.
Some menus on an allowed page might not function.

Cause
There are two common causes for this behavior:

Caching
Content received from multiple web hosts

Solution
Caching - Caching is often the reason why a security policy change might appear to be ineffective.
For example, if the default policy blocks an applet, the substitute applet might be cached.
If the administrator changes the policy to allow the applet, the user might continue to receive the cached substitute applet. Therefore, it appears as though the security policy change did not work.

Using logs, it is possible to determine if cached content is provided to the user.
If an object is served from a cache, there will be no record of the request in the logs.
In order to see all transactions, it may be necessary to temporarily change the logging settings.
Please note that increased logging can reduce performance, so it is important to change the logging settings back to their previous values when troubleshooting is complete.

The systems administrator should be aware of all caches that might prevent requests from reaching the scanner.
The administrator should also know how to manage these caches.
Common caches include:

A network caching solution, such as ISA or Blue Coat, that is located between the Finjan system and the browsers.
The browser's own cache - In order to completely clear this cache, it may be necessary to first exit all browser instances.
The JVM's cache - Sun's Java Virtual Machine maintains its own applet cache that is separate from the browser's cache. This cache can be managed by double-clicking the Java Plug-in icon in Windows' Control Panel and selecting the Cache tab.
Vital Security NG's built-in Security Caching - To disable this, navigate in the Management Console to Settings -> Content Processors -> Security Caching and unselect the Enable Caching checkbox.

When the Finjan system is implemented in proxy mode, one way to determine if a policy change took effect is to configure a browser to proxy directly through the Finjan proxy.
This will eliminate the possiblility of interference from any network caching solutions.
If a browser having a clear cache and configured to proxy directly to the Finjan system continues to receive the wrong policy, then the policy should be inspected once more.
In environments that utilize different user policies, please verify that the correct policy is assigned to the test browser.

Content received from Multiple Web Hosts
Even if the URL list entry matches the website shown in the browser's address bar, it is important to note that many web pages are built from content that comes from several websites.
For example, on a news site, the initial links on the page might come from one server, while the dynamic content (links to new articles) might come from a different server in a completely different domain.
Again, the logs should reveal which sites are involved in the transaction.
As with caching, it may be necessary to temporarily increase the logging level to track the transactions associated with the web page.
Once the all of the involved sites have been identified, the logs can be returned to their former settings and the policy can be modified appropriately to allow the desired page.

VSOS
8.3.x
8.4.x
8.5.0

This article applies to:: NG 1000; NG 5000; NG 8000

This article was previously published as:: Finjan KB 1299

CVE vulnerability - general information

support finjan — Thu, 24 Dec 2009 00:00:00 GMT

Question
How can I determine if my Finjan solution provides protection against a specific vulnerability or attack?

Answer
Finjan Vital Security Web Appliances provide both reactive (signature-based) and proactive (behavior-based) protection though their Vulnerability Anti.dote™ and Application Level Behavior Blocking engines, respectively. These security engines help to mitigate new exploits based on known vulnerabilities. In many cases, they also stop new threats based on unknown vulnerabilities.

From time to time vendors publish official statements, revealing details about new vulnerabilities or exposures that are related to their products. For example, Microsoft typically releases security bulletins on the second Tuesday of every month. The Common Vulnerabilities and Exposures (CVE) system provides a global, cross-vendor reference method for publicly known information security vulnerabilities and exposures. Each vendor alert is typically related to one or more CVE numbers. The CVE web page linked below inlcudes a search mechanism that can be used to look up vulnerabilities by CVE numbers or vendor identifiers.

http://cve.mitre.org/cve/cve.html

When researching a particular vulnerability, open a Finjan support case to receive information regarding the level of protection provided by a Finjan solution. To identify the vulnerability under investigation, please provide its CVE number in the support case. If there is any other information that could prove helpful, please provide it as well. Such information can include:
vendor identifiers
links to web pages that discuss the vulnerability
e-mails that discuss the vulnerability

Software Version
all

This article was previously published as:
Finjan KB 12677