Content Filter Service (CFS) 4.0 Upgrade Guide

03/26/2020 1,527 People found this article helpful 489,684 Views

Download

Print

Share

• LinkedIn
• Twitter
• Facebook
• Email
• Copy URL The link has been copied to clipboard

Description

This article covers SonicOS 6.2.6 and 6.2.7.7 (for Super Massive 9800) CFS 4.0 upgrade guide.

Topics:

• Differences between CFS 4.0 and previous releases
• Automatic CFS policy migration
• CFS Policy upgrade example

Resolution

Configuring CFS policy

In previous releases, configuring CFS policy involved navigating many steps on several pages: CFS page, Zones page, Users/Groups page, and App Rules page. In particular, CFS 3.0 had two separate modes: Users and Zones, and App Rules. In CFS 4.0, these two modes are merged so that all CFS policies can be configured from a single page.

New CFS objects

CFS 4.0 uses an object based model. This is more consistent with other SonicWall configurations with the same ease of re-usability.

A new Content Filter Objects page has been added inside the Firewall menu. All CFS objects are listed in this page. To apply these objects, you can access the Content Filter page through the link

Security Services | Content Filter in the Content Filter Objects page. In the Content Filter page, a link also jumps back to the Content Filter Objects page.

CFS 4.0 introduces 3 new objects:

• CFS URI List Object. This replaces the Custom Allowed List, Custom Forbidden List, Keywords List, CFS Allowed/Forbidden List in App Rules, and part of Restrict Web Features (per file extensions). Unlike CFS 3.0, CFS URI lists now support wildcard matching. Once defined, a CFS URI List Object can be easily re-used in any CFS Profile Object for whitelisting or blacklisting.
• CFS Profile Object. This is a new concept in CFS 4.0. A Profile Object defines what kind of operation is triggered for each HTTP/HTTPS connection. The user can define the Allowed/Forbidden URI List here, and define the operations for each category (Allowed, Blocked, Confirm, Passphrase, and BWM). The original consent feature has also been moved into CFS Profile Object. This changes the consent feature from a global to per-profile setting. The CFS Profile Object is like an old CFS policy, although it is only a part of a new CFS policy.
• CFS Action Object. Also a new concept in CFS 4.0, the CFS Action Object defines what happens after a packet is filtered by CFS. The administrator can define the detailed configurations for these actions: Block, Confirm, Passphrase and BWM. This action object is also part of a new CFS policy.

New CFS policy

The new CFS policy engine allows administrators to define the following matching conditions for a CFS Policy: Source Zone, Destination Zone, Address Object, Users/Groups, Schedule, Enabled, CFS Profile, and CFS Action.

When a packet is processed, the following conditions are checked: Source Zone, Destination Zone, Address Object, Users, Schedule and Enabled state. If all of these conditions are matched, the packet is filtered by the corresponding CFS Profile. Then the CFS Action is invoked according to the filtering results.

CFS policies now follow a priority defined by the order set in the Content Filter page. CFS 3.0’s least restrictive and most permissive policies follow a new, high-to-low priority model in CFS 4.0. When matching policies, a CFS Policy with higher priority is checked earlier. Priority is determined by position in the policy list, with the highest priority given to the policy at the top. As a general practice, the highest priority should be assigned to specific/granular policies and lower priority to more generic policies that apply to a broader set of users.

Since CFS 4.0 now supports three new actions, Passphrase, BWM, and Confirm, the new priority model enables administrators to more clearly visualize and manage the policy execution order and ultimately better design the overall policy set behavior. Administrators should verify that the upgraded policies follow the intended behavior. If discrepancies in policies are found, administrators should back up all firmware settings and configuration before editing and deleting the applicable policies. With this method, administrators can re-create the corresponding policies manually without having to touch the Match, Action, and Profile CFS Objects.

Comparison to CFS 3.0 to CFS 4.0

The following table compares the user experience for various aspects of the old and new CFS.

NOTE: If Content Filtering Service is not licensed through either Comprehensive Gateway Security Services (CGSS) or a Content Filtering Service Premium license, then all CFS functionalities will not work.

Automatic CFS policy migration

When upgrading to CFS 4.0 for the first time, the firmware does its best to automatically migrate the policies from CFS 3.0. However, as the settings are somewhat different, the resulting policies may not exactly match the original policies.

CFS 3.0 employed some settings that are no longer used and are discarded when migrating to CFS 4.0.

The automatic migration process uses complex logic to try to replicate the originally intended policies. Therefore, the policy migration process takes longer and the complete objects are configured differently than when they were configured in CFS 3.0. Network administrators should not assume that the automatically migrated policies in CFS 4.0 exactly match their original policies configured in the previous version and should instead examine and verify the results.

Topics:

• Migration from Users and Zones mode
• Migration from App Rules mode
• Migration from Websense mode
• Recommended validation process

Migration from Users and Zones mode

Because policies were previously accumulated in CFS 3.0, it is difficult to assign a correct priority/order to these new policies under CFS 4.0. Therefore, you should verify and manually adjust the correct policy priority following the migration.

After these steps take place, a default CFS Policy is automatically generated and appended at the end of the list.

To migrate from Users and Zones mode:

1. For each old CFS policy:

• Generate a new CFS Profile Object
• Migrate old Allowed URI List objects:
  • If the Source of Allowed Domains of old policy is None, the Allowed URI List of the Profile Object is also None.
  • For a global custom allowed list, CFS 4.0 generates a new CFS URI List.
  • If the Source of Allowed Domains of old policy is Per Policy, CFS 4.0 generates a new CFS URI List from the old custom allowed list and then assigns this new CFS URI List to the Allowed URI List of the Profile Object.
• Migrate old Forbidden Domains and Keywords. The logic follows that of Allowed Domains.
• Generate a new CFS Action Object. The old global blocking page is assigned to this new Action Object. Since previous CFS versions do not have Confirm, Passphrase and BWM options, the values inside new Action Object are the default values
• After all the old polices have been migrated, new CFS URI List Objects, CFS Profile Objects and CFS Action Objects are generated and mapped to the old policy ID in order to keep their relationship.

2. If the old CFS uses the CFS Policy per IP Address Range feature, generate a new CFS policy for each row inside the old CFS Policy per IP Address Range Table. For each new CFS policy:

• The Source Zone and Destination Zone are set to All.
• The Source Address is the same value as the CFS 3.0 IP range.
• The Users/Groups are set to All.
• The Schedule keeps same value as in the CFS 3.0 policy.
• The CFS Profile Object is the Profile object generated in Step 1.
• The CFS Action Object is Action object generated in Step 1.

3. For each user group with CFS enabled, a new CFS Policy is generated. For each new CFS Policy:

• The Source Zone and Dest Zone are set to All.
• The Source Address is set to Any.
• The Users/Groups are the same CFS 3.0 user groups.
• The Schedule is same value as in the CFS 3.0 policy.
• The CFS Profile Object is the Profile object generated in Step 1.
• The CFS Action Object is the Action object generated in Step 1.

NOTE: After upgrading, the user groups under the same policy as the group Everyone in CFS 3.0 are merged into one policy with the Everyone group.

4. For each zone with CFS enabled, a new CFS Policy is generated. For each new CFS Policy:

• The Source Zone is set to the CFS 3.0 zone.
• The Destination Zone is set to All.
• The Source Address is set to Any.
• The Users/Groups are set to Any.
• The Schedule is the same value as in the CFS 3.0 policy.
• The CFS Profile Object is the Profile object generated in Step 1.
• The CFS Action Object is the Action object generated in Step 1.

Migration from App Rules mode

For each App Rule whose Policy Type is CFS and Action is CFS Block Page or HTTP Block Page or BWM, CFS 4.0 executes the following steps to complete the policy upgrading process.

To migrate from App Rules mode:

1.  CFS URI List Objects generated from Allow/Excluded and Forbidden/Included lists of current App Rules are assigned to the Profile Object as Allowed URI List and to Forbidden URI List, respectively.
   NOTE: Depending on the selected categories in the current App Rule’s Match Object, they are set as either Block or BWM in the Profile Object.
2. 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 is the block page content of this Action Object.
• If the action of a current App Rule is HTTP Block Page, the block page of current App Rule is the block content of this Action Object.
• If the action of a current App Rule is BWM, the BWM values are used for this Action Object.

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

• The Zone of the CFS 3.0 App Rule is set to Source Zone.
• The Destination Zone is set to All.
• The Source Address is set to the address of the CFS 3.0 App Rule.
• The Users/Groups are set to the included Users/Groups of the CFS 3.0 App Rule.
• The Schedule is set to the Schedule of the CFS 3.0 App Rule.
• The CFS Profile Object generated above is assigned to the CFS Profile.
• The CFS Action Object generated above is set to CFS Action.

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.

Migration from Websense mode

There are no significant changes for Websense between CFS 4.0 and the previous releases, so the upgrading process for Websense is simple and is not discussed in this document.

Recommended validation process

Following the migration process, some of the generated CFS objects and policies might be duplicated and the priority order of some new policies might be wrong. Hence, administrators should clean and adjust the priorities.

The best practice for the migration is to keep the automatically generated CFS URI List Objects, which contain the whitelist and blacklist defined in the firewall, and keep the generated CFS Action Objects, which contain the customized blocking pages. Remove the generated CFS Policies and the generated CFS Profile Objects.

After cleaning, create the CFS Profile Objects and CFS Policies from scratch, providing descriptive names for each object. Normally, this is faster than adjusting the auto generated objects and making them work as expected. Fewer objects are duplicated also.

CFS Policy upgrade example

This section discusses the differences in policy settings between CFS 3.0 and CFS 4.0 via an example situation.

Consider the case of an office with three groups: engineers, sales, HR. Each group has different CFS policies to control access to websites.

In the previous CFS release, the IT administrator created 3 different CFS policies, and assigned each policy to a group from the Users menu. A default CFS policy was also used, which was assigned to the LAN zone.

For each HTTP connection, CFS 3.0 checked which group that current user belonged to, then accumulated the corresponding CFS policy with the default CFS policy to filter the connection. If the user did not belong to any group, then the default CFS policy was applied to the connection.

In the upgraded CFS 4.0, CFS generates three CFS Policies with the correct CFS Profile and CFS Action, and links the new policies with the correct groups. The default policy is auto generated too, which by default is at the end of the policy table.

In the previous CFS, if one employee belonged to multiple groups and each group had a different CFS policy, these policies were accumulated with complicated algorithms, and different algorithms for different settings inside the policy. This policy accumulation introduced many implicit filtering results. Thus, IT admin could not clearly distinguish what the filtering behaviors were after completing the configurations. It was also very difficult to troubleshoot when unexpected filtering behaviors appeared.

In CFS 4.0, the configuration is clear and explicit, without any implicit or hidden logic. Each connection only hits one CFS policy at most. Policy accumulation is no longer allowed. Once the connection hits one policy inside the policy table, that policy is the only one applied to this connection.

This behavior has a trade-off. For example, for the employee belonging to multiple groups, in CFS 4.0, the IT administrator needs to create a special small group for him, then create a CFS Policy for this group, and make sure this policy has higher priority than other bigger groups so that this policy is hit earlier.

Related Articles

• How to Block Google QUIC Protocol on SonicOSX 7.0?
• How to block certain Keywords on SonicOSX 7.0?
• How internal Interfaces can obtain Global IPv6 Addresses using DHCPv6 Prefix Delegation

Categories

• Firewalls > SonicWall SuperMassive E10000 Series > Content Filtering Service
• Firewalls > SonicWall SuperMassive 9000 Series > Content Filtering Service
• Firewalls > SonicWall NSA Series > Content Filtering Service
• Firewalls > TZ Series > Content Filtering Service