Upgrade from CFS 3.0 App Rules Mode to CFS 4.0

03/26/2020 1322 15329

DESCRIPTION:

This article will provide an example to discuss the differences in policy settings between CFS 3.0 and CFS 4.0 and describe upgrading from CFS 3.0 App Rules mode to CFS 4.0.

Note: there are no significant changes for Websense between CFS4.0 and the previous releases, the upgrading process for Websense will not be discussed.

CAUSE:

As there are big changes between the new 4.0 and the old 3.0 CFS (e.g. Users and Zones mode and App Rules mode are handled by CFS policies in CFS4.0), although the firmware will do its best to automatically migrate almost all the polices, the resulting policies may not exactly match the original policies when upgrading from CFS 3.0 to CFS 4.0.  

• The complete objects are configured differently than when they were configured in CFS 3.0
• CFS 3.0 employed some settings that are no longer used and are discarded when migrating to CFS 4.0.

RESOLUTION:

Upgrading CFS 3.0 to 4.0 for App Rules mode

There are two sections which will be discussed here:

• Merging Process for CFS 3.0 (App Rules Mode) to CFS 4.0
• Upgrading Steps for CFS 3.0 (App Rules Mode) to CFS 4.0

For CFS upgrading demonstration, here uses the following example (6 users in 3 groups and configured with 4 different CFS App Rules):

The Result can be tested as below when before and after upgrading.

1. Merging Process for CFS 3.0 (App Rules Mode) to CFS 4.0

For each App Rule whose Policy Type is CFS and Action is CFS Block Page, HTTP Block page or BWM, CFS 4.0, SonicOS executes the following steps to automatically complete the policy merging process. To migrate from App Rules mode:

a. CFS URI List Objects generated from Allow/Excluded and Forbidden/Included lists of current App Rules are assigned to the Profile Object as Allowed URL List and to Forbidden URL List, respectively.

In CFS 3.0, the Allow/Excluded and Forbidden/Included lists are configured at Firewall | Match Objects page.

In CFS 4.0, after Upgrading, the lists will be merged to URI List Objects area at Firewall | Content Filter Objects page.

b. The CFS Action Object is generated according to the following criteria:

• If the action of a current App Rule is a CFS Block Page, the old global CFS blocking page content of CFS 3.0  is the block page content of this Action Object.

In CFS 3.0, the CFS Block page is defined at Security Services | Content Filter page.

In CFS 4.0, after Upgrading the CFS Block Page will be merged to CFS Action Objects area at Firewall | Content Filter Objects page. Click the relevant action in CFS Action Objects area, and select tab Block.

• If the action of a current App Rule is HTTP Block Page, the block page of current App Rule of CFS 3,0 is the block content of this Action Object.

In CFS 3.0, the HTTP Block page is defined at Firewall | Action Objects page.

 In CFS 4.0, after Upgrading the HTTP Block Page will be merged to CFS Action Objects area at Firewall | ContentFilter Objects page but the color setting will be abandoned.  Click the relevant action in CFS Action Objects area, and select tab Block.

• If the action of a current App Rule is BWM, the BWM values are used for this Action Object.

In CFS 3.0, the BWM is defined at Firewall | Action Objects page.

 In CFS 4.0, after Upgrading the BWM action will be merged to CFS Action Objects area at Firewall | ContentFilter Objects page. Click the relevant action in CFS Action Objects area, and select tab BWM.

c. The CFS Profile Object is generated from the CFS Match Objects and  the action defined in CFS App Rule of CFS 3.0 and the above CFS URI List Objects of CFS 4.0 :

In CFS 3.0, the CFS Category List  is defined at Firewall | Match Objects page.  

In CFS 4.0, the CFS Category is merged to CFS Profile Objects at  Firewall | Content Filter Objects page.

NOTES:    Depending on the selected categories in the App Rule’s Match Object, they are set as either Block or BWM in the Profile Object according to the relevant App Rules.

For CFS Forbidden/Included list, if the action using BWM in CFS 3.0, then the Forbidden URI List will be set to None after upgrading.

d. The App Rule name is used as the Policy name. To generate a CFS Policy, the following should take place:

NOTE: After all App Rules have been migrated to CFS Policies, CFS attempts to keep the same priorities, generating a Default CFS Policy at the end of the list.

2. Upgrading Steps for CFS 3.0 (App Rules Mode) to CFS 4.0

When going to upgrade from CFS 3.0 (App Rules Mode) to CFS 4.0, please follow the below steps.

1. Navigate to System | Setting page | Export the original settings for backup. 

2. Upgrade the firmware to CFS 4.0.

3. After upgrading, as some of the generated CFS objects and policies might be duplicated and the priority order of some new policies might be wrong. Administrators should clean and adjust the priorities. When go to Security Services | Content Filter page, automatically generated CFS policies are listed as below.

In this case, after upgrading the policy CFS_Paul_BW is not triggered as policy CFS_Group_2A has higher priority. So administrator should adjust the priority of CFS_Paul_BW higher to ensure the CFS behaviors are the same as before upgrading. Click the priority icon for policy CFS_Paul_BW, and input 2 to make the priority higher than policy CFS_Group_2A.

Notes: 1. Before upgrading, please check your original firmware version, if you are using SonicOS 6.2.5, we recommend you to upgrade to 6.2.5.1 firstly then upgrade to the firmware with CFS 4.0.

             2. If there are amount of CFS policies generated, to adjust the priority of these auto generated policies may take time. We also recommend that you can follow the below steps after upgrading.

• Keep the automatically generated CFS URI List Objects and CFS Action Objects.
• Remove the generated CFS Policies and CFS Profile Objects.
• Create the CFS Profile Objects and CFS Polices from scratch, providing descriptive names for each object. 

             3.  SonicOS does not support downgrade from CFS 4.0 to CFS 3.0 so far.