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

Usage of external CA certificates

Charles Creegan — Wed, 01 Apr 2020 00:00:00 GMT

This article applies to:

WebMarshal

Question:

How can I use external CA certificate with WebMarshal?

Information:

Use of publicly trusted CA certificates in proxying end-user communications with internet systems is prohibited by some browser manufacturer rules and regulations. LevelBlue recommends the use of a self signed or enterprise CA for proxying use. If you intend to use a publicly trusted or cross signed CA certificate with this product, consult with the issuing CA to ensure your use is compliant with all current and anticipated regulations.

To import a CA certificate, you can use the Certificate Converter Tool available from the WebMarshal Download page.

Latest MHF/RHF patches for SWG v11.7

Stanislav Michailov — Sat, 12 Aug 2017 23:58:18 GMT

This article applies to:

SWG v11.7

Question:

What are the latest MHF/RHF patches for SWG v11.7.0 ?
What are the latest MHF/RHF patches for SWG v11.7.1 ?

Information:

SWG 11.7.1 Maintenance release is available here for offline installation mode: SWG 11.7.1 FUP

The latest patches for SWG 11.7.1 OS version are:

RHF#01 - Runtime Hotfix #01

The latest patches for SWG 11.7 OS version are:

RHF#02 - Runtime Hotfix #02

RHF#01 - Runtime Hotfix #01

Notes:

These are FTP links, in some web browsers you may need to enter the username and password from the above URLs separately.
General information about MHF/RHF patches for SWG OS is provided in KB article Q16782.
MHF/RHF patches are installed as local updates. Refer to the following KB articles for installation procedure guidelines:
- Q13868: Install local updates on SWG appliances
- Q14452: .fup installation for SWG

Latest MHF/RHF patches for SWG v11.8.0

Stanislav Michailov — Fri, 11 Aug 2017 17:43:10 GMT

This article applies to:

SWG v11.8.0

Question:

What are the latest MHF/RHF patches for SWG v11.8.0 ?

Information:

The latest patches for SWG 11.8 OS version are:

RHF#08 - Runtime Hotfix #08

RHF#06 - Runtime Hotfix #06

RHF#04 - Runtime Hotfix #04

Notes:

These are FTP links, in some web browsers you may need to enter the username and password from the above URLs separately.
General information about MHF/RHF patches for SWG OS is provided in KB article Q16782.
MHF/RHF patches are installed as local updates. Refer to the following KB articles for installation procedure guidelines:
- Q13868: Install local updates on SWG appliances
- Q14452: .fup installation for SWG

Install SWG v11.8 on Hyper-V

Shawn Cook — Wed, 02 Nov 2016 14:54:49 GMT

This article applies to:

SWG v11.8

Question:

What are the VM specifications for installing SWG v11.8 on a Hyper-V system?

Answer:

RAM: 4GB (4000MB)

HDD: 150GB

CPU: 1 Virtual Processor

Notes:

1) Installing SWG on Hyper-V system should be performed with the ISO image

2) On installation using the ISO image, select "vm" to install on the Hyper-V virtual machine.

Latest MHF/RHF patches for SWG v11.7.1

Shawn Cook — Thu, 20 Oct 2016 15:03:55 GMT

This article applies to:

SWG v11.7.1

Question:

What are the latest MHF/RHF patches for SWG v11.7.1 ?

Information:

The latest patches for this version of SWG are:

RHF#02 - Runtime Hotfix #02

MHF#02 - Maintenance Hotfix #01

Notes:

These are FTP links, in some web browsers you may need to enter the username and password from the above URLs separately.
General information about MHF/RHF patches for SWG OS is provided in KB article Q16782.
MHF/RHF patches are installed as local updates. Refer to the following KB articles for installation procedure guidelines:
- Q13868: Install local updates on SWG appliances
- Q14452: .fup installation for SWG

Latest MHF/RHF patches for SWG v11.6

Shawn Cook — Thu, 20 Oct 2016 14:58:33 GMT

This article applies to:

SWG v11.6

Question:

What are the latest MHF/RHF patches for SWG v11.6 ?

Information:

The latest patches for this version of SWG are:

RHF#13 - Runtime Hotfix #13

MHF#03 - Maintenance Hotfix #03

GENERAL03 - GENERAL03 (MSC) patch

Patch delivering MSC 2.3.1.04 version for SWG 11.6 OS, as described in Q20443

Notes:

These are FTP links, in some web browsers you may need to enter the username and password from the above URLs separately.
General information about MHF/RHF patches for SWG OS is provided in KB article Q16782.
MHF/RHF patches are installed as local updates. Refer to the following KB articles for installation procedure guidelines:
- Q13868: Install local updates on SWG appliances
- Q14452: .fup installation for SWG

Web Logs show incorrect time

Shawn Cook — Thu, 20 Oct 2016 11:05:29 GMT

Web Logs show incorrect time

This article applies to:

SWG 11.6
SWG 11.7
SWG 11.8

Symptoms:

Web Logs show a different time then the policy server and the scanners
All time settings on the policy server and scanners have been verified on the backend but Web Logs still show a different time

Resolution:

SSH to the policy server and check the timezone in postgresql:

psql -U finjan logs

logs=> show timezone;

TimeZone

----------

GMT

(1 row)

You will notice that the timezone in the database is different than the timezone configured on the policy server and scanners.

--------------------------------------------------------

To fix this you need to editpostgresql.conf (/opt/swg/configuration/data/postgresql/main/postgresql.conf).

Changed the two ‘GMT’ entries to‘US/Central’ or your desired timezone.

Restart postgresql (/etc/init.d/postgresql-9.3 restart). You should see the change immediately in the web logs. If you do not see an immediate change after restarting postgresql then the time zone format in postgresql.conf is not correct.

Adding SWG HTTPS certificates to Mac/OSX

Shawn Cook — Thu, 09 Jun 2016 16:53:14 GMT

Summary:

This article describes the process of manually adding an SWG HTTPS certificate to an OSX keystore for use with HTTPS inspection.

Export the HTTPS certificate from the SWG by navigating to Administration -> System Settings -> SWG Devices, and expand the left-hand Tree to reveal the Scanning Server HTTPS section

Take the exported certificate, and copy it onto the Mac.
Import the certificate into the OSX Keychain using the Keychain Access program

Once imported, double-click the certificate in the Keychain Access window

Set 'When using this certificate' to 'Always Trust'

After the certificate has been loaded and trusted, navigate to System Preferences -> Network -> Proxies and ensure that the proxy for both HTTP and HTTPS is set.

Close the web browser and reopen it. You should now be able to browse to HTTPS sites through the SWG as expected.

Latest MHF/RHF patches for SWG v11.5

Shawn Cook — Fri, 15 Jan 2016 14:11:07 GMT

This article applies to:

SWG v11.5

Question:

What are the latest MHF/RHF patches for SWG v11.5 ?

Information:

The latest patches for this version of SWG are:

MHF#11 - Maintenance Hotfix #11

RHF#13 - Runtime Hotfix #13

Refer to the links below for previous MHF/RHF patches if needed:

MHF#10 - Maintenance Hotfix #10

MHF#09 - Maintenance Hotfix #09

MHF#08 - Maintenance Hotfix #08

MHF#07 - Maintenance Hotfix #07

MHF#06 - Maintenance Hotfix #06

MHF#05 - Maintenance Hotfix #05

MHF#03 - Maintenance Hotfix #03

MHF#02 - Maintenance Hotfix #02

RHF#12 - Runtime Hotfix #12

RHF#11 - Runtime Hotfix #11

RHF#10 - Runtime Hotfix #10

RHF#08 - Runtime Hotfix #08

RHF#07 - Runtime Hotfix #07

RHF#06 - Runtime Hotfix #06

RHF#03 - Runtime Hotfix #03

RHF#02 - Runtime Hotfix #02

Notes:

These are FTP links, in some web browsers you may need to enter the username and password from the above URLs separately.
General information about MHF/RHF patches for SWG OS is provided in KB article Q16782.
MHF/RHF patches are installed as local updates. Refer to the following KB articles for installation procedure guidelines:
- Q13868: Install local updates on SWG appliances
- Q14452: .fup installation for SWG

Latest MHF/RHF patches for SWG v11.0

Shawn Cook — Fri, 15 Jan 2016 13:30:59 GMT

This article applies to:

SWG v11.0

Question:

What are the latest MHF/RHF patches for SWG v11.0 ?

Information:

The latest patches for this version of SWG are:

MHF#08 - Maintenance Hotfix #08

RHF#09 - Runtime Hotfix #09

Refer to the links below for previous MHF/RHF patches if needed:

MHF#07 - Maintenance Hotfix #07
MHF#06 - Maintenance Hotfix #06
MHF#04 - Maintenance Hotfix #04
MHF#03 - Maintenance Hotfix #03

RHF#08 - Runtime Hotfix #08
RHF#06 - Runtime Hotfix #06
RHF#05 - Runtime Hotfix #05
RHF#04 - Runtime Hotfix #04
RHF#03 - Runtime Hotfix #03
RHF#02 - Runtime Hotfix #02

Notes:

These are FTP links, in some web browsers you may need to enter the username and password from the above links separately.
General information about MHF/RHF patches for SWG OS is provided in KB article Q16782.
MHF/RHF patches are installed as local updates. Refer to the following KB articles for installation procedure guidelines:
- Q13868: Install local updates on SWG appliances
- Q14452: .fup installation for SWG

Latest MHF/RHF patches for SWG v10.2

Shawn Cook — Fri, 15 Jan 2016 13:30:37 GMT

This article applies to:

SWG v10.2

Question:

What are the latest MHF/RHF patches for SWG v10.2?

Information:

The latest patches are:

MHF #04 - Maintenance Hotfix #04

RHF #13 - Runtime Hotfix #13

Refer to the links below for previous MHF/RHF patches if needed:

MHF#03 - Maintenance Hotfix #03
MHF#02 - Maintenance Hotfix #02
MHF#01 - Maintenance Hotfix #01

RHF#11 - Runtime Hotfix #11
RHF#10 - Runtime Hotfix #10
RHF#09 - Runtime Hotfix #09
RHF#08 - Runtime Hotfix #08
RHF#07 - Runtime Hotfix #07
RHF#05 - Runtime Hotfix #05
RHF#04 - Runtime Hotfix #04
RHF#03 - Runtime Hotfix #03
RHF#02 - Runtime Hotfix #02
RHF#01 - Runtime Hotfix #01

Notes:

These are FTP links, and in some web browsers you may need to enter the username and password from the above URLs separately.
General information about MHF/RHF patches for SWG OS is provided in KB article Q16782.
MHF/RHF patches are installed as local updates. Refer to the following KB articles for installation procedure guidelines:
- Q13868: Install local updates on SWG appliances
- Q14452: .fup installation for SWG

Is it possible to enforce Safe Search on the SWG when HTTPS protocol is used by the search engines?

Mariusz Cieślak — Tue, 08 Dec 2015 09:19:23 GMT

This article applies to:

SWG version 11.7 and earlier

Question:

Is it possible to enforce Safe Search on the SWG when HTTPS protocol is used by the search engines?

Reply:

There is currently no way to enforce Safe Search when HTTPS protocol is being used by the search engines (this applies to SWG versions up to 11.7) .

There is however a workaround for this problem which can be implemented by altering the DNS server configuration - please refer to the links below for more details:

https://support.google.com/websearch/answer/186669 (Option 3 on the link)

https://support.opendns.com/entries/57304954-How-to-Enforcing-Google-SafeSearch

Notes:

SafeSearch is a feature of Google and other search engines that acts as an automated filter of pornography and potentially offensive content.

Why the Status Page is not displayed in Chrome browser when using FTP over HTTP?

Mariusz Cieślak — Wed, 16 Sep 2015 09:06:27 GMT

This article applies to:

All SWG versions

Question:

Why the Status Page is not displayed in Chrome browser when using FTP over HTTP protocol? (when setting port 8080 in the proxy settings for FTP transactions on the browser side)

Reply:

The header in the GET request coming from the browser which is mandatory for activating the Status Page is the User-Agent header.

This is visible in the "Administration > System Settings > Scanning > Scanning Options" section of the SWG GUI (part of the configuration) - see the screenshot below:

Chrome browser doesn't include User-Agent header in the GET request when FTP over HTTP protocol is being used.
Please see below the comparison of the GET requests that are sent by the browsers for retrieving the same file when using Chrome and Firefox:

1) Chrome browser - no User-Agent header is included in the GET request:

2) Firefox browser - User-Agent header is included in the GET request:

Notes:

This article is applicable only when FTP over HTTP protocol is used (port 8080 for FTP transactions is set on the browser side in the proxy settings). For other protocols (e.g. HTTP etc.), the behavior is different.

How to change the speed and duplex settings of the eth interace? (SWG 11.6 or higher)

Mariusz Cieślak — Wed, 16 Sep 2015 08:29:07 GMT

This article applies to:

SWG 11.6 or higher

Question:

How to change the speed and duplex settings of the eth interace on SWG version 11.6 or higher? (to correct the errors visible on the interace after executing "ifconfig" command)

Information:

In SWG version 11.6 or higher, the option to change the speed and duplex settings of the eth interace has been added to the "config_network" command in the Interface configuration section.

Please see the example below:

Notes:

Please note that this option was not available in the previous SWG versions and changing the speed and duplex settings of the eth interace was possible with the "ethtool" command (available in the super shell). Sample screenshot of the network settings configuration options from SWG version 11.5 below:

Is it possible to enable Caching Kit on the Cloud scanner?

Mariusz Cieślak — Tue, 01 Sep 2015 09:04:28 GMT

This article applies to:

All SWG versions

Question:

Is it possible to enable Caching Kit using the "config_hardware" command on the Cloud scanner?

Reply:

No, this is not possible (as per the design). On the Cloud Scanner / "SWG Remote Device" type, "config_hardware" command is disabled - see the example below:

The reason for disabling the "config_hardware" command for the Cloud scanner devices is that writing to additional volume (sdb) in the Cloud infrastructure would have to be done over the network, thus causing higher delays in processing requests on the SWG than writing to a physical drive. Drives in Cloud instances are connected over the network and the performance is lower than the performance of physical volumes. Enabling Caching Kit in such scenario doesn't provide expected performance benefits.

How to apply hotfix for Logjam vulnerability on SWG acting as a server and a client.

Mariusz Cieślak — Thu, 25 Jun 2015 03:44:19 GMT

This article applies to:

SWG 11.0

SWG 11.5

SWG 11.6
Question:

How to apply hotfix for Logjam vulnerability on SWG acting as a server and a client.
Procedure:
Logjam vulnerability is related to Diffie-Hellman key exchange which allows Internet protocols such as HTTPS, SSH, IPsec, SMTPS and other that depend on TLS to agree on a shared key and negotiate a secure connection.
Diffie-Hellmankey exchange is a cryptographic algorithm that allows Internet protocols to agree on a shared key and negotiate a secure connection. It is fundamental to many protocols including HTTPS, SSH, and protocols that rely on Transport Layer Security (TLS).
This hotfix addresses weaknesses in how Diffie-Hellman key exchange is deployed,which can result in a Logjam attack against the TLS protocol. The vulnerability is attributable to a flaw in the TLS protocol rather than an implementation vulnerability.
A Logjam attack can affect any server that supports Ephemeral Diffie-Hellman export ciphers, as well as all modern web browsers. The attack allows a man-in-the-middle attacker to downgrade vulnerable TLS connections to 512-bit export-grade cryptography, enabling the attacker to read and modify any data passing over the connection.
SWG in this case can act as Client and as Server. Please see below steps to apply the hotfix:

For SWG acting as a Server:
Auto hotfix (AHF) has been already released for downloading for SWG running software version v11.0,v11.5,v11.6. This patch will cause SSHd to not support Export Diffie Helman key exchange.
Please note that our HTTPS service doesn't support EDH already therefore no change is needed.

For SWG acting as a Client:
After installing this hotfix, SWG will no longer support cipher suites using authenticated ephemeral Diffie-Helman (EDH) key agreements. Some websites will only negotiate TLS with this cipher, and so will no longer work. If the operation of such websites is critical, you can revert the change and allow SWG to use that cipher again.
For this reason we created a separate patch which is not being distributed by any of SWG HotFixes (AHF,RHF,MHF).
This general patch disables EDH support automatically after the installation and puts additional script in case customer want to revert back the changes.

Patch installation on SWG v11.5/11.6/11.7:
To install this Hotfix (if you have already downloaded the Hotfix file, ignore steps 1-4):
1. Download the Hotfix from the FTP site to your local desktop ( hotfix link is also attached to this KB article). Note that you can verify the Hotfix content using the md5 utility against the md5 file from the FTP.
2. In the Management Console, navigate to Settings > Updates > Updates Management.
3. Click Import Updates at the lower right of the screen.
4. In the Local Update Import window that opens, browse to the Hotfix fup file on your desktop; select it and click Upload in the window. The Hotfix will appear in the Available Updates window. If it does not appear right away, click the Refresh button.
5. In the Available Updates window, select the Hotfix from the list and click Install Update. Once the Hotfix has been installed, it will move to the Installed Updates tab.
During patch installation process 2 scripts will be loaded to the system:
a./usr/share/perl5/update_https_module.pl
b ./usr/share/perl5/update_https_module_revert.pl
First script will be run automatically during the patch installation and second one will have to be run by TAC support technician as it requires root access (only when a revert is needed) .
A"dummy" commit after running the patch is needed to apply changes.

Patch installation on SWG v11.0:
First of all we do recommend to upgrade to SWG 11.5 and apply the above hotfix. However if this is not possible please follow below instructions.
This Hotfix must be installed by the SWG administrator on top of SWG 11.0. ManagementHotfix 08-01 for SWG 11.0 must be applied before applying this hotfix. This Hotfix restarts the Scanning Server and will therefore impact user Web access for some minutes.
Any future Management hotfixes applied to the Policy Server will revert this change. This hotfix cannot be reapplied afterwards.
After any future migration to SWG version 11.5, the string affected by this hotfix will not be recognized and the system will downgrade to a WEAK cipher list.For each device, the Allow Weak Ciphersuites check box in Devices> HTTPS > Advanced tab will be updated automatically and should be unchecked to return to usage of strong ciphers only.
Inaddition, Logjam Hotfix CVE-2015-4000 for SWG 11.5 must be applied after the migration to version 11.5.
To install this Hotfix (if you have already downloaded the Hotfix file, ignore steps 1-4):
1. For each device under Devices, select HTTPS and in the Advanced tab,uncheck the Allow Weak Ciphersuites check box.
2. Download the Hotfix from the FTP site to your local desktop ( hotfix is also attached to this KB article). Note that you can verify the Hotfix content using the md5 utility against the md5 file from the FTP.
3. In the Management Console, navigate to Settings > Updates > Updates Management.
4. Click Import Updates at the lower right of the screen.
5. In the Local Update Import window that opens, browse to the Hotfix fup file on your desktop; select it and click Upload in the window. The Hotfix will appear in the Available Updates window. If it does not appear right away, click the Refresh button.
6. In the Available Updates window, select the Hotfix from the list and click Install Update. Once the Hotfix has been installed, it will move to the Installed Updates tab.

Notes:
If the system must be reverted back to support EDH, contact Trustwave Support at tac@trustwave.com.

What are the correct URIs for the ICAP healhchecks for SWG version 11.5 and up?

Mariusz Cieślak — Mon, 11 May 2015 02:24:57 GMT

This article applies to:

SWG version 11.5 and up

Question:

What are the correct URIs for the ICAP healhchecks for SWG version 11.5 and up? (configured on the Bluecoat side when SWG is setup as the ICAP server)

Information:

The correct URIs for the ICAP healhchecks are following:

- for REQMOD:
icap://IP_address_of_the_SWG:1344/Trustwave_REQMOD

- for RESPMOD:
icap://IP_address_of_the_SWG:1344/Trustwave_RESPMOD

Notes:

Please replace the "IP_address_of_the_SWG" in the URIs with the actual IP address of the SWG.

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.*

End of Maintenance for Secure Web Gateway version 10.2

Charles — Mon, 20 Apr 2015 14:57:44 GMT

This article applies to:

Secure Web Gateway (SWG) 10.2

Secure Web Gateway 10.2 End of Life

Dear valued SWG customer,

According to the Trustwave Product Support Policy, we are announcing that the End-of-Maintenance period for Secure Web Gateway version 10.2 will close on October 1, 2014.

To assist you in making the transition to a later, supported version, we will extend the support period for an additional 6 months. During that time, until the version's End-of-Life, you will receive database downloads and security patches.

We will officially stop supporting SWG version 10.2 when this timeframe expires, on April 1, 2015. To keep your Trustwave SWG Appliances up-to-date and supported, please use the remaining period to upgrade to version 11.0, 11.5 or later. (To determine which supported versions can be installed on your existing hardware, see the Supported Versions matrix.)

The latest SWG versions and documentation can be found on the Secure Web Gateway support pages.

Please contact the Technical Assistance Center if you need guidance and information on the upgrade process.

Apply an SWG license key in a High Availability Policy Server environment

Charles — Mon, 15 Dec 2014 18:00:20 GMT

This article applies to:

SWG 11.x High Availability Policy Server environment

Question:

How to apply an SWG license in a High Availability Policy Server environment?

Procedure:

This procedure refers to a HA PS environment that has been licensed in the past and a new license key needs to be applied to it.

1. Log in to the Policy Server and navigate to Administration > Updates and Upgrades > Configuration.

2. Make sure that the Install Policy is set to Do nothing (Manual download and install) and that no exceptions are set, as shown below:

3. Make sure no updates are listed in the Available Updates tab under Administration > Updates and Upgrades > Management.
4. Open Administration > System Settings > License and paste the license key for this Policy Server. Save and Commit if required.
5. A confirmation screen opens if the license initialization is successful. Make sure the license details listed in the Licensed Modules tab matches your SWG license options:

6. Save the details for your records and future reference.
7. Navigate to Administration > Updates and Upgrades > Management and retrieve updates manually.
8. Refresh the view in the Available Updates tab and check that new updates are populated.
If no updates appear, do not proceed as there may be networking issues preventing the Policy Server from getting security updates.
9. Do not install any updates at this point and remove all update entries manually.
10. Promote HA Policy Server using the failover command executed on the limited shell of the Primary Policy Server.
It may take a few minutes for the system to process this request.
11. Log in to the Policy Server (the former HA PS should now be acting as the Primary PS) and wait until all devices are synchronized in the Devices tree.
12. Navigate to Administration > Updates and Upgrades > Configuration.
13. Make sure Install Policy is set to Do nothing (Manual download and install) and that no exceptions are set, as shown in step 2.
14. Open Administration > System Settings > License and paste the same license key for this Policy Server. Save and Commit if required.
15. A confirmation screen opens if the license initialization is successful.
16. Make sure Licensed Modules and all other license details in the confirmation screen match those on the former Primary Policy Server in steps 5-6.
They should be identical.
17. Navigate to Administration > Updates and Upgrades > Management and retrieve updates manually.
18. Refresh the view in the Available Updates tab and check that new updates are populated.
If no updates appear, there may be networking issues preventing the Policy Server from getting security updates.
19. Navigate to Administration > Updates and Upgrades > Configuration and restore Install Policy settings, according to what was set prior to the license change.
20. Save and Commit changes if required.
21. Promote the current HA Policy Server (formerly the Primary Policy Server) using the failover command executed on the limited shell of the current Primary Policy Server.
It may take a few minutes for the system to process this request.
22. Log in to the Policy Server (the former HA Policy Server should now be acting as HA Policy Server again) and wait until all devices are synchronized in the Devices tree.
23. Navigate to Administration > Updates and Upgrades > Configuration and restore Install Policy settings, according to what was set prior to the license change.
24. Save and Commit changes if required.
25. Navigate to Administration > Updates and Upgrades > Management and retrieve updates manually.

The system should now apply security updates according to Install Policy settings.

Set up an SWG scanner to work with ICAP server

Charles — Wed, 19 Nov 2014 15:37:22 GMT

This article applies to:

SWG 11.5 and later

Question:

How to set up an SWG scanner to integrate with ICAP server.

Notes:

There are several global details to be considered before you proceed with the setup:

1) ICAP client functionality should be enabled on the SWG scanner you are setting up to work with ICAP server.

2) Any given content sent to SWG proxy is first processed/scanned through the rules of SWG Security policy, both for HTTP requests and HTTP responses.
If no action is taken by SWG Security policy, this content is then forwarded to the ICAP Server for modification, based on the rules set in ICAP Request/Response Modification policies.

3) This Knowledgebase article does not provide any guidance as to how ICAP Server policy should be set up to process the web traffic forwarded for modification by the SWG scanner.

4) Review KB #16573 for detailed steps to set up Trustwave SWG ICAP Client to integrate with Trustwave SWG ICAP Server.

Procedure:

This Knowledgebase article provides generic instructions on how to set up a Trustwave SWG ICAP Client to integrate with any ICAP Server.

1. Navigate to Administration > System Settings > SWG Devices.

2. Under the Scanning Server, select ICAP Client and make sure the Enable ICAP Client check box is on:

Then define the related configuration settings by following the steps below.

3. Navigate to Policies > Condition Elements > ICAP Service Groups.

Normally, ICAP Client/Server communication is based on a series of ICAP Request modification and ICAP Response modification requests.

4. Set up the ICAP Request modification component:

a. Right-click ICAP Service Groups in the left pane and choose Add Group.

b. Define a name for the group, and in the Method field, select REQMOD, as shown below:

After you save the changes, this new ICAP Service group object should appear in the list in the left pane.

5. Right-click the new object in the left pane and choose Add Service.

6. Define a name for the service and select the Enable ICAP Service check box.

7. Set the Service URI according to the requirements of the ICAP server and save the changes.

For example:

Service URI for ICAP REQMOD of Trustwave SWG ICAP Server is - ICAP://<SERVER-IP>:1344/Trustwave_REQMOD

Service URI for ICAP REQMOD of Trustwave DLP ICAP Server is - ICAP://<SERVER-IP>:1344/reqmod

8. The ICAP Service module allows you to test service settings assuming that the ICAP Server is also set up to work with SWG ICAP client.

Choose a scanner you want to test the service with and click the Test service button:

The screen below opens if both ICAP Server and Client are set correctly to work with this ICAP Reqmod service.

Also, you may see the Max Connections number change as a result of ICAP options negotiation taking place during the service test:

9. Set up the ICAP Response modification component:

a. Right-click the ICAP Service Groups object in the left pane and choose Add Group.

b. Define a name for the group, and in the Method field, select RESPMOD, as shown below:

After you save the changes, this new ICAP Service group object should appear in the list in the left pane.

10. Right-click the new object and choose Add Service.

11. Define a name for the service, and select the Enable ICAP Service check box.

12. Set the Service URI according to requirements of the ICAP server and save the changes.

For example:

Service URI for ICAP RESPMOD of Trustwave SWG ICAP Server is - ICAP://<SERVER-IP>:1344/Trustwave_RESPMOD

Service URI for ICAP RESPMOD of Trustwave DLP ICAP Server is - ICAP://<SERVER-IP>:1344/respmod

13. You may want to test the ICAP RESPMOD service, selecting a specific SWG scanner to test:

The screen below opens if both ICAP Server and Client are set correctly to work with ICAP Respmod service:

Next, define the ICAP policies to control what should be sent to the ICAP server either with ICAP Reqmod or ICAP Respmod service, or both:

14. Navigate to Policies > Device Policies > ICAP Request Modification.

15. Right-click Policies in the left pane and choose Add Policy to create a new ICAP Reqmod policy.

16. Define a name for the policy, save the changes and make sure it appears in the list of policies in the left pane.

17. Right-click the new policy and choose Add Rule.

18. Set the correct ICAP Service Group for the rule in the right pane as shown below and save the changes:

19. Right-click the new rule in the left pane and choose Add Condition.

Then choose from the list of available conditions in the right pane to define new behavior accordingly:

Repeat steps 18-19 to add more rules to your custom ICAP Request Modification policy.

20. Navigate to Policies > Device Policies > ICAP Response Modification.

21. Right-click Policies in the left pane and choose Add Policy to create a new ICAP Respmod policy.

22. Define a name for the policy, save the changes and make sure it appears in the list of policies in the left pane.

23. Right-click the new policy and choose Add Rule.

24. Set the correct ICAP Service Group for the rule in the right pane as shown below and save the changes:

25. Right-click the new rule in the left pane and choose Add Condition.

Then choose from the list of available conditions in the right pane to define new behavior accordingly:

If necessary, repeat steps 24-25 to add more rules to your custom ICAP Response Modification policy.

26. Finally, make sure that the SWG scanner is using the new custom policies defined for ICAP Request/Response modification:

Navigate to Administration > System Settings > SWG Devices. Under the Scanning Server > General, set the ICAP Request/Response modification policies accordingly:

SWG Management Console (GUI) requires IE Compatibility View settings

Charles — Thu, 30 Oct 2014 19:57:10 GMT

This article applies to:

SWG 11.x
Microsoft Internet Explorer 11

Symptoms:

Administrators are not able to log in to SWG Management console (GUI)
The SWG Management console (GUI) does not notify the user about incorrect username or password

In most cases the login page will look slightly different when using the IE browser.

Normally, the login box should be centered on the screen, but in IE it is as shown below:

Causes:

Newer versions of the Internet Explorer browser are designed to better support recent HTML standards. As a result some of the web components in the SWG UI may not work as in the older IE versions.

Resolution:

Open the Internet Explorer browser, click Tools on the menu bar, and then choose Compatibility View Settings.
Add the IP address or hostname of the SWG Server to the list of websites added to Compatibility View:
Close the Compatibility View Settings dialog and reload the SWG management console. Observe the correct positioning of the login box.

Notes:

Compatibility View helps make websites designed for older browsers look better when viewed in Internet Explorer.

If you choose to view a website in Compatibility View, as a convenience to you, Internet Explorer will remember this choice and use Compatibility View the next time you visit the site.

How to disable SSLv3 from SWG HTTPS service

Andrew Davies — Thu, 16 Oct 2014 11:03:50 GMT

This article applies to:

SWG 10.x,
SWG 11.x

Question:

Due to vulnerabilities revealed in SSLv3 how can I disable SSLv3 transactions on the SWG?

Procedure:

To disable SSL v3 on the SWG please use the following procedure:

Access the web interface of the Policy Server
Log in as admin
Navigate to Administration > System Settings > SWG/M86 Devices
Expand the device tree to locate the different services for the scanning server(s)
Click on the HTTPS service
In the main window click on the Advanced tab
Uncheck the 'Allow SSLv3' checkbox
Repeat as necessary for all of the active scanning servers
Commit changes

Notes:

The following image shows the advanced tab of the HTTPS service settings with 'Allow SSLv3' disabled.

Change the IP address for a Policy Server/All-In-One device

Charles — Thu, 09 Oct 2014 11:58:48 GMT

This article applies to:

SWG 10.x - Policy Server / All-In-One
SWG 11.x - Policy Server / All-In-One

Question:

How do I change the IP address for a Policy Server / All-In-One device?

Procedure:

The change is performed in two stages:

1) The IP address is changed on the networking interface, using the relevant Limited Shell commands.

2) The IP address is changed in the SWG database by an update in the SWG GUI.

These stages are detailed in the following steps:

1. Open the SSH connection to the SWG device using its current IP address, and run the config_network command.

2. Type 'Y' to view further options, and then type '2' to view the interfaces currently defined in the system.

3. Choose the option for the interface you want to change; in this case it is interface eth0. Type '1'.

4. Type '1' to change the IP address.

5. Type the new IP address; in this case it is 208.90.236.220/26.

6. Review the new configuration details and type 'Y' to save it:

7. With this change enabled you should expect the SSH connection to fail. Try to open a new SSH connection using the new IP address to make sure that the change worked.

Proceed with the update of the new IP address in the database, using the SWG GUI:

Note: The IP address change has been already performed at the networking level, so you should access the GUI using the new IP address.

8. In the GUI, navigate to the SWG Devices section and highlight the Policy Server device IP.

The left pane should still show the old IP address.

9. Click Edit, and make sure the Device IP in the right pane shows the new IP address.

10. Save and commit the changes.

MHF/RHF patch, what is it and how is it installed ?

Charles — Wed, 23 Apr 2014 15:27:23 GMT

This article applies to:

SWG v10.x
SWG v11.x

Question:

What are the differences between MHF and RHF patches ?
How should these patches be installed ?
Is there any specific order of installation ?

Information:

MHF patch is a Maintenance Hot Fix, mainly addressing issues of the Policy Server role in SWG OS.
RHF patch is a Run-time Hot Fix, addressing issues of the Scanning Server role in SWG OS.

These patches are installed as local updates, refer to below KB article for installation procedure guidelines:
Q13868: Install local updates on SWG appliances
Q14452: .fup installation for SWG

There are no internal dependencies between MHF and RHF patches, no specific order of installation is required.
These patches are cumulative, and newer version of MHF/RHF patch will include the libraries included in the previous version of the MHF/RHF patch, respectively.

Patch usually consists of Debian libraries that are being updated from version to version, as shown below for example:

The patch is always installed first on the Policy Server and then the Policy Server is responsible to update internally the scanner(s) managed by this Policy Server.
The installation order is also similar in the case of HA Policy Server, once the patch is installed on the Active Policy Server, it will also be installed on the Backup Policy Server.

Refer to the below KB articles for the links to the most recent patches for different SWG OS versions:
SWG v10.2 - Q16783
SWG v11.0 - Q16784
SWG v11.5 - Q16785