LevelBlue Knowledge Base » Knowledgebase » Legacy Products » Secure Web Gateway » Third Party

How do I test Websense URL categorization

ofer Kalef — Mon, 04 Nov 2013 04:54:23 GMT

This article applies to:

SWG 10.x

Question:

How do I test Websense URL categorization?

Reply:

The Websense categorization used in SWG uses technology from the older brand name SurfControl. You can test URLs using the following link:

http://mtas.surfcontrol.com/mtas/mtas.asp

This page does not require registration.

Notes:

Websense/SurfControl has several database versions. Trustwave cannot guarantee that SWG will return exactly the same result as the test site. The test site provides the best available information.
Trustwave does not have a credential for the testing page on the main Websense.com support website.
The fastest way to ask websense to change URL categorization is just email them to : suggest@websense.com Must state we are using surf control engine + version

No updates for Virtual SWG system

ofer Kalef — Sun, 08 Sep 2013 07:05:56 GMT

This article applies to:

Virtual SWG 10.x
Virtual SWG 11.x

Symptoms:

Updates are not installed, and no new updates are shown as available when attempting to retrieve manually.
System Log shows an error on connecting with the Updates server.

Causes:

This may happen due to the default date/time settings used for a Virtual installation - check the current date/time set on SWG to verify.

Resolution:

Update the date/time settings using the config_time Limited Shell command. The best update method is to specify an NTP server, public or local.

SWG Support Policy Aug 2013

ofer Kalef — Mon, 26 Aug 2013 03:18:54 GMT

This article applies to:

Question:

What is the Trustwave SWG support policy

Information:

See attached File

Install local updates on SWG appliances

ofer Kalef — Fri, 09 Aug 2013 01:53:28 GMT

This article applies to:

SWG 10.x
SWG 11.x

Question:

What is the procedure for installing a local update file on a Secure Web Gateway (SWG) appliance?

Reply:

Patches, fixes and software updates for Secure Web Gateway appliances are released periodically.
Patches typically address specific issues and are initially released as standalone packages before they are included in a general maintenance update. This article describes how to install any .fup patch or update.

Download the update package as instructed by support personnel and save it locally on your desktop.
Navigate to Administration > Updates and Upgrades > Management.
In the Available Updates tab, click Import Updates .
Browse to the update location on the local machine and click the Import button.
Wait for the upload process to complete.
The amount of time will vary depending on the size of the update and the speed of the connection to the Policy Server.
Make sure that the required update package appears in the list of available updates.
It may be necessary to click the Refresh button in order to update the list.
To see more information about the update, click the + icon next to the update row and click the Release Notes link in the detailed description.
Click the required update and choose the Install Now option.

What is the procedure to follow if updates fail to install?

ofer Kalef — Mon, 08 Jul 2013 02:43:50 GMT

This article applies to:

SWG 10.x
SWG 11.x

Question:

What is the procedure to follow if all updates fail to install: Requests to https://mirror.updateng.finjan.com/updates return 500 (Connect failed: connect: Connection timed out; Connection timed out)

Reply:

1. Try to ping mirror.updateng.finjan.com and see if it resolves.

2. Check http://www.whatsmydns.net/#A/mirror.updateng.finjan.com to see if there is a worldwide problem, and try to ping the various IPs of mirror.updateng.finjan.com

3. If you are running Version 11.x and behind a proxy, make sure you have installed MHF01 or higher.

It is probable that your firewall blocks mirror.updateng.finjan.com. Check your firewall and open port 443 to [1] updateng.finjan.com and [2] mirror.updateng.finjan.com

Block page displays an unfamiliar category

ofer Kalef — Mon, 17 Jun 2013 01:33:14 GMT

This article applies to:

SWG 10.x
SWG 11.x

Question:

The User gets a Block page with a block reason that contains an unfamiliar category. The User is using the Websense/IBM filter but the category in the block reason is not a Websense/IBM category.
In the Web Log Transaction Entry Details > Request > Websense (or IBM), the categories seem correct. Why is there an inconsistency?

Reply:

If the block page came from a cloud scanner, the reason is an inconsistency between the category in the block reason and the filter engine categories, which correctly shows in the Web Log Transaction Entry Details > Request > Websense (or IBM).

Kaspersky blocks files with reason "could not be scanned by AV"

ofer Kalef — Mon, 04 Feb 2013 06:15:52 GMT

This article applies to:

SWG 10.x, 11.x

Question:

Kaspersky blocks files with error "could not be scanned by AV" but file seems valid and can be opened with archive software.

Reply:

Check the Response node in the weblog transaction.

Possible reasons:

Scan timeout - try increasing scan timeout in Administration->System Settings->Scanning->Scanning Engines->Anti-Virus (Kaspersky)->Scanning Time Limit

Encrypted file - A file in the archive may be encrypted and Kaspersky fails to open it. This triggers a block of the whole archive with reason password protected.

Corrupt file - A file in the archive is corrupted and that's why the whole archive is marked as corrupted.

Windows 7 end users cannot authenticate with NTLM

Rudolf Kessler — Thu, 24 May 2012 01:45:52 GMT

This article applies to:

SWG 10.x

Symptoms:

Client can connect with an XP workstation, but not with Windows 7
Using 2008 AD server
Client connections return a "STATUS_INVALID_PARAM" error code when you use a "Send NTLMv2 response only" authentication level in Windows Server
2008 or in Windows Vista

Causes:

An issue in AD server

Resolution:

MS Solution to implement on the AD server is in:

http://support.microsoft.com/kb/957441

Authentication failure withMS AD 2008 R2 when using windows 7/vista Client

Rudolf Kessler — Mon, 14 May 2012 02:17:31 GMT

This article applies to:

SWG 10.x
Windows Vista or Windows 7 clients

Symptoms:

Trying to configure authentication against Microsoft AD 2008 R2.
With Windows XP clients, authentication is successful when you disable NTLM V2 enforcement.
However with Windows 7 or Windows Vista clients, you see "Authentication failure" in the weblog viewer.

Causes:

This problem occurs because of an additional security check in Windows Server 2008 and Windows Vista.
This problem is limited to clients that use NTLMv2 authentication without extended security.

Resolution:

To resolve this issue , you can install and configure a Hotfix that Microsoft provides for this issue. See the following Microsoft Knowledge Base article:

http://support.microsoft.com/kb/957441

Bluecoat Proxy SG fails to "Sense Settings" in ICAP mode with version 10

Rudolf Kessler — Fri, 02 Mar 2012 07:08:55 GMT

This article applies to:

SWG 10.x
Bluecoat Proxy SGOS (seen with 5.5.x.x)

Symptoms:

Maximum number of ICAP connections is 16K (16,384) in SWG 10.x.
ICAP client service configuration fails to detect and apply this value in ICAP Response mode (sense Request Mode settings work fine). Value is unchanged, and remains under 16K.

Causes:

In SWG 10.x, the maximum number of possible established connections to the proxy or ICAP port is 16K, and can be divided between all available ICAP clients. The RESP/REQ mode ratio is 70:30 (hard-coded value), but the weighting of connections to each ICAP client can be configured as desired.
- Example: If using two ICAP clients weighted at 50:50, they are each capable of handling 8K (8,192) connections (see ICAP section under Scanner / "Devices"). Therefore, each ICAP client's theoretical maximum connections is 5,734 (70%) in RESP mode and 2,458 (30%) in REQ mode.
It appears that Bluecoat Proxy SG cannot use more than 4K (4,096) connections for one service. If SWG's "Sense Settings" tries to use a value higher than this, the configuration process fails to accept this higher value.

Resolution:

There are two options:

The preferred option is to change the weighting in SWG devices section and limit it to 35% per ICAP client (even if when combined they do not add up to 100%). Now "Sense Settings" should complete successfully.
Although not recommended, the second option is to skip "Sense Settings" and set 4096 manually in RESP mode.

Notes:

SWG's ICAP server responds correctly:

Bluecoat SGOS does not accept the value:

If set manually, Bluecoat SGOS returns an error:

Solution: Limit weighting to 35%, as this will return a valid number and "Sense Settings" will successfully complete.

IE8 running on Windows 7 does not load certain sites

Rudolf Kessler — Mon, 02 May 2011 06:37:47 GMT

This article applies to:

SWG 9.x

Question:

Why do certain HTTP/HTTPS sites not load in Internet Explorer 8 under Windows 7 or Windows 2008 R2, especially when using Identification (Get User Credentials) or Authentication?

Reply:

This behavior seems to be an IE8 limitation – IE8 is sometimes stuck when SWG responds to an HTTP CONNECT request (the start of an HTTPS session) with an HTTP 407 Proxy Authenticate message. If the message body (the HTML code) is smaller than a certain size, IE8 hangs after a number of consequential requests/responses.

Solution:

Secure Web Gateway appliances can be configured to work around this issue. The issue does not occur if the HTTP message “HTTP 407 Proxy Authenticate” has at least a specific length. This can be achieved by adding additional dummy-data to the Authentication error message.

Since this modification requires root access, please contact Trustwave Technical Support, referring to this issue and article number 13928 (public) / 13710 (internal).

ICAP Timeout Error When Browsing Through BlueCoat Proxy

Rudolf Kessler — Fri, 10 Dec 2010 09:07:11 GMT

Description
When browsing through a BlueCoat proxy with a Finjan scanner configured as an ICAP, client timeouts occurs.

Symptoms

The following error is shown when trying to browse to a site:

ICAP Error (icap_error)

An error occurred while performing an ICAP operation: Request timed out: Timed out while waiting for a response from the ICAP server.
There could be a network problem, the ICAP service may be misconfigured, or the ICAP server may have reported an error.

For assistance, contact your network support team.

Cause
This is a result of a misconfigured default connection timeout value in the BlueCoat (That was changed in SGOS ver 5).

Solution

To resolve this please increase the connection timeout for the RESP_MOD service as follows:

Software Version
all SWG versions, but not related to

This article applies to:

SWG 3000

SWG 5000

SWG 7000

This article was previously published as:

Finjan KB 1817

TCP Errors and Broken Sessions in a Proxy Chain with BlueCoat

Rudolf Kessler — Wed, 17 Nov 2010 02:46:43 GMT

Description
In a proxy chain with BlueCoat Proxy SG (downstream proxy) and Finjan Vital Security (upstream proxy) clients get "TCP errors" and see broken sessions.

Symptoms
Clients browsing the internet see "TCP error" pages, and experience overall performance drop.

Cause
This might be related to a specific HTTP setting on the BlueCoat Proxy SG:
"HTTP persistent server" enables support for persistent server requests to web servers.
It is enabled by default and set to 15 minutes.
That means a session is kept open for 15 minutes, even if no data is retrieved, in order to avoid the necessity of a new TCP session setup (if required).

This makes sense if the BlueCoat is the external proxy as the load is distributed over all addressed internet servers.

However, in a proxy chain the upstream proxy has to hold all sessions even if no data is retrieved anymore.
This is a waste of resources with regards to the capacity of established connections, and can lead to the situation that no new sessions can be established.

Solution
Disable session persistency for server connections as follows:

Get SSH or serial access to the BlueCoat Proxy SG.
Change to enable mode ("en").
Change to config mode ("config t").
In HTTP settings: disable persistent server requests ("http no persistent server").
Quit config mode ("exit").

This setting is active now.
You might want to check the settings afterwards:

Type "show http".
The console output should look like this:

Persistent connections:
Client connections: enabled
Server connections: disabled

Software Version
not related to SWG

This article applies to:

NG 5000 / SWG 3000

NG 6000 / SWG 5000

NG 8000 / SWG 7000

This article was previously published as:

Finjan KB 1523

SWG block pages and helpdesk systems

Eric Hanson — Tue, 15 Jun 2010 20:13:00 GMT

Question:
When users receive a full-page block message from a Secure Web Gateway scanner, is it possible for them to click a button on the page that will submit a helpdesk request to allow the page?

Answer:
Full page block messages are comprised of editable HTML code, and it is possible to embed FORM tags within them. This should be done with the Message Templates, rather than in the Block / Warn Messages. Message Templates can be edited at Policies -> End User Messages -> Message Template.

In order to provide the helpdesk with information about the blocked content (for example, Transaction IDs, etc.), it is useful to pass the block / warn message text as part of the form submission. The USER_NOTIF variable is replaced with this text at the time that the block page is generated. This variable can be included as the value of a form INPUT tag. In this scenario, USER_NOTIF must be enclosed in quotes. It is crucial to leave at least one space before or after USER_NOTIF (between USER_NOTIF and the quotes) in order for the SWG appliance to recognize this variable and replace it with the block / warn message.

For questions regarding the proper way to post web form data to a specific helpdesk system, please contact the helpdesk vendor.

Software Versions:
9.x

Microsoft Windows Update Fails If User Authentication/Identification Is Used

support finjan — Wed, 29 Jul 2009 00:00:00 GMT

Description

Microsoft Windows Update (although whitelisted) fails if user authentication/identification is used.

Symptoms

In an environment where authentication or identification is defined and a user attempts to use Microsoft/Windows Update site, after selecting the hotfixes to install, the site's control starts running and then reports the installation attempt failed.

Cause
Windows Update site use an ActiveX control to query and manage downloads from Microsoft.

This ActiveX is not a fully functional browser, and so does not handle authentication mechanisms (such as NTLM) correctly.

The reason that the pages are blocked is because whenever the ActiveX is trying to access the web, the authentication fails and the wrong policy is assigned to the user at hand, in such a case the policy that will be used is the one assigned to Unknown Users.

If the policy that is assigned to Unknown Users is to block all access to the internet, the ActiveX component will fail to download updates from the update site.

Solution

Since authentication will not work for the Microsoft/Windows Update site, the following options are availlable::

Grant access to windows update to all machines by assigning a policy with limited access to the Unknown Users group.
Limit access to Windows Update by a combination of Source IP identification and limited access rules .

Both solutions will require setting up a security policy rule to whitelist the Microsoft/Windows update site.

For the following examples, this Security Policy will be referred as “The Restricted SP”.

This can be an existing Security Policy that will be modified or a new Security Policy that will be created specifically for this solution.

TIP: To identify the URLs to whitelist, you can find the currently blocked URLs in the Web Logs screen of the Policy Server admin web GUI.

For more information on how to perform the actions described above, please consult the User Manuals .

Solution 1

Assign The Restricted SP to the Unknown Users.

Solution 2

Limiting access by client IP:

Since we don’t want to lose the identification by username, we will duplicate and change the current Identification Policy and add a rule at the end to identify by client IP.

Create a new user or user group which will be assigned The Restricted SP, enter the IP ranges for this user group, or add individual users with specific IP addresses.
An example is given below, for more information on how to perform these actions, consult the User Manuals.

Go to Users -> Users/User Groups.
Right click on the Users/User Group root and select Add Group.
Name the new group (for example: Windows Update only)
Assign the Restricted SP as the Security Policy.
Assign the Logging Policy and HTTPS Policy according to your organization's requirements.
If an IP range is appropriate, fill the table with the relevant IP address range.
Save the new user group.
Right-Click the new user group and select Add User.
Enter a user name.
Fill the table with the assigned IP addresses for this user.
Save the user.
Repeat steps 8-11 for each user that will use Windows Update.
Commit changes.

Now when you have the Users and Security Policies setup up you will need to create the appropriate Identification Policy.
Perform the following steps from the policy server web admin GUI:

Go to Administration -> System Settings -> Finjan Devices.
Browse to the Devices -> IP -> Scanning Server -> Authentication.
Note the assign Identification Policy.
Now that you know what is the current Identification Policy, go to Policies -> Identification.
Right-click on the relevant identification policy (from step 3) and select Duplicate Policy.
Enter the name for the new policy (for example: Get User Credentials or IP).
Right click on the new policy and select Add Rule.
Enter the name for the new Rule: Identify Users by Source IP.
Check the checkbox Enable Rule.
Select the Action: Identify by source IP.
Save the policy.
Go to Administration -> System Settings -> Finjan Devices.
Browse to the Devices -> IP -> Scanning Server -> Authentication and click Edit.
Change the Identification Policy to the new policy created in steps 5-11.
Save and Commit the changes.

Now you have an identification process that first try to perform an identification/authentication handshake (will work with supported browsers), and if fails will Identify the client using the Source IP (X-Client-IP HTTP Header).
If the user is browsing from an IP address assigned to the user group using the Restricted SP then the user will have access to the Microsoft/Windows Update site.

All other users will be treated as Unknown Users.

Software Version
9.0
9.2

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

This article was previously published as:: Finjan KB 1833

Websense - 9.0 Technical Brief

Eric Hanson — Mon, 04 May 2009 00:00:00 GMT

This article applies to:
NG 1000
NG 5000
NG 6000
NG 8000
This article was previously published as:
Finjan KB 1726

NG-6000 Firmware update process

support finjan — Fri, 27 Mar 2009 00:00:00 GMT

This article applies to:
NG 6000
This article was previously published as:
Finjan KB 1525

How to Access the NG-8040 L2-7 Switch

support finjan — Fri, 27 Mar 2009 00:00:00 GMT

Description
External management access to the NG-8040 layer 2-7 switch has to be enabled through the Chassis Management Console.

Symptoms
Web GUI, telnet or secure shell connections cannot be established.

Cause
External access is disabled by default and has to be enabled explicitly.

Solution
In the Blade center management console select I/O module tasks -> Configuration
Navigate to the relevant bay (the slot where the L2-7 switch is installed) and select "Advanced Configuration"
Enable "External management over all ports" in the section "Advanced Setup" and save this setting.

Now it is possible to access the switch through web GUI, telnet or SSH, if configured.

Software Version
N/A

This article applies to:
NG 8000
This article was previously published as:
Finjan KB 1551

Read Headers identification method description and usage

Amir Foox — Mon, 23 Mar 2009 00:00:00 GMT

Question
The Vital Security Web Appliance uses four different methods to identify and authenticate network users before allowing any web transaction:
1. Source IP.
2. Read Headers.
3. Get User Credentials.
4. Authentication.
This article describes and demonstrates the Read Headers method.
The "Read Headers" method was meant to be implemented in a topology which includes an additional proxy device that authenticates users on the network, such as a Microsoft ISA server, which is used as an example in the following scenario.

Answer
In the "Read Headers" identification method, the Vital Security Web Appliance relies on the downstream proxy to provide headers information in each transaction.
These headers would be used then to identify the username of the person who originated the transaction and/or the IP of the client machine from which the transaction originated.
The Vital Security Web Appliance can be configured to monitor specific headers, such as X-Authenticated-User for username and/or X-Client-IP for client IP address information. In this scenario, it is assumed that the information forwarded by the downstream proxy is valid.
The Vital Security Web Appliance does not attempt to verify the supplied data.
Please note that the Microsoft ISA server must be properly configured to forward this information to the Vital Security Web Appliance.
Vital Security IP forwarding plugin should be installed on the Micrsoft ISA server for this purpose (please review the below Finjan Vital Knowledge Base article on this topic: http://kb.finjan.com/article.asp?article=1282&p=4 ).
The plugin setup file can be downloaded from the below location:
http://download.finjan.com/products/ng/ipfwd/index.htm
See the below image to confirm that Vital Security ISA connector is configured properly to forward the necessary information through HTTP headers of each transaction:

The Vital Security Web Appliance should be then configured to use "Read Headers" identification policy:
This policy is designed to use one rule "Always Identify Users by Headers" :
This rule is set to "Identify by headers" action based on specific headers information:
The headers to be used by this rule are predefined in the below "Pre Authenticated Headers" list:
As mentioned above, assuming that the information (IP / username) forwarded by the downstream proxy is valid, it then would be properly logged for further usage in reports / log viewer.

Software Version
8.5.0

This article applies to:
NG 1000
NG 5000
NG 6000
NG 8000
This article was previously published as:
Finjan KB 1798

IBM Proventia Web Filter 9.0

Eric Hanson — Mon, 23 Mar 2009 00:00:00 GMT

This article was previously published as:
Finjan KB 1727

Using Transparent Authentication Mechanism with FireFox

support finjan — Mon, 23 Mar 2009 00:00:00 GMT

Question
As a result of the new Transparent Authentication mechanism added in Vital Security software version 8.4.3, the browser allows the end-user to connect to the internet without sending requests for authentication from the end-user.

This authentication request arrives from the browser as a result of the HTTP 401 Unauthorized Response sent from the web-server.

If the authentication domain is resolvable as a hostname inside the orginization, the IE browser will forward authentication details automatically.
However, the FireFox browser will not do it automatically.

How can we enable this automatic option for FireFox so that it does not send repeated requests for authentication to the end-user?

Answer
In order to enable this automatic option for the FireFox browser, please do the following:
Open FireFox browser.
Type about:config in the FireFox address bar.
Select network.automatic-ntlm-auth.trusted-uris in the Filter bar.
Type in the virtual redirection hostname that you have defined for your Finjan appliance (e.g. vhost in the example below):

Virtual Redirection Hostname must be defined exactly as it is set for Finjan appliance:

VSOS
8.4.3

This article applies to:
NG 1000
NG 5000
NG 8000
This article was previously published as:
Finjan KB 1390

Juniper SSL VPN fails to connect with Finjan SSL Appliance

support finjan — Mon, 23 Mar 2009 00:00:00 GMT

Description
When deploying a Finjan Vital Security SSL solution and requiring the tunnelling of Juniper SSL VPN connections through the solution, Finjan cannot scan the traffic going through the Juniper SSL VPN.

Symptoms
The connection fails constantly.

Cause
This is due to the traffic stream of mixed protocols which the scanning engines cannot handle.

Solution
To make a Juniper VPN connection work through an SSL/NG appliance pair, you must add the full domain name to the URL List in the Policies Section of the SSL appliance configuration. If wild cards are used, for example *.capita.co.uk then this can cause a certificate miss-match and again the connection will fail.

Software Version
N/A

This article was previously published as:
Finjan KB 1528

How can I configure SSH access to the Load Balancer switch (NG-8040)?

support finjan — Mon, 23 Mar 2009 00:00:00 GMT

Question
How can I configure SSH access to the Load Balancer switch (NG-8040)?

Answer
The relevant command is only available while using the serial access for configuration (see related article What kind of cable do I need for the 8040 Serial Console? - http://kb.finjan.com/article.asp?article=1472&p=4):

>> Main# /c/sys/access/sshd
------------------------------------------------------------
[SSH Server Menu]
intrval - Set interval for generating the RSA server key
hkeygen - Generate the RSA host key
skeygen - Generate the RSA server key
sshport - Set SSH server port number
scpadm - Set SCP-only admin password
ena - Enable SCP apply and save
dis - Disable SCP apply and save
on - Turn SSH server ON (SSHv1/SSHv2)
off - Turn SSH server OFF
cur - Display current SSH server configuration

>> SSH Server# on

Apply and save.

Telnet access just provides the command for enabling the SCP option:

>> Main# /c/sys/access/sshd
------------------------------------------------------------
[SSH Server Menu]
sshport - Set SSH server port number
ena - Enable SCP apply and save
cur - Display current SSH server configuration

The current settings can be checked with the command "cur" (current)

>> Main# /c/sys/access/sshd/cur
SSH RSA server key autogen disabled
SSH RSA host key currently ready to service
SSH RSA server key currently ready to service
SSH server currently on port 22
SSH SCP-only administrator password not configured
SSH SCP apply and save currently enabled
SSH server currently ON

The config dump then shows
/c/sys/access/sshd/ena (SCP enabled)
/c/sys/access/sshd/on (SSH enabled)

Software Version
N/A

This article applies to:
NG 8000
This article was previously published as:
Finjan KB 1554

Can a Lotus Notes client identify Windows Active Directory users, using Vital Security NG (NTLM authentication)?

support finjan — Mon, 23 Mar 2009 00:00:00 GMT

Question
Can a Lotus Notes client identify Windows Active Directory users using Vital Security NG (NTLM authentication)?

Answer
No, Lotus Notes does not support NTLM authentication.
Therefore it can't authenticate Active Directory users that were imported by the Vital Security NG proxy, using NTLM authentication.

There is an open feature request for IBM to add NTLM support to Lotus Notes.
Please refer to the following link for more information:
http://www-1.ibm.com/support/docview.wss?rs=474&uid=swg21190929

Software Version
8.3.0
8.3.5
8.4.0
8.4.3
8.5.0

This article applies to:
NG 1000
NG 5000
NG 8000
This article was previously published as:
Finjan KB 1260

Forwarding IP Addresses from a Squid Cache to a NG Appliance

Peleg Samson — Mon, 23 Mar 2009 00:00:00 GMT

This article applies to:
NG 1000
NG 5000
NG 6000
NG 8000
This article was previously published as:
Finjan KB 1823