FAQ on Content Filtering Service (CFS) 3.0 when upgrading to SonicOS 5.8 and above

10/28/2024 971 People found this article helpful 485,322 Views

Download

Print

Share

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

Description

This article covers the improvements in the Content Filtering Service 3.0, part of our new Early Release SonicOS 5.8 firmware. With SonicOS 5.8 firmware, the Content Filtering Service (CFS) can be configured in two different modes:

1) via User and Zone Screens (legacy mode) and
2) via App Rules (which uses what used to be called the Application Firewall Engine).

This article explains how these two modes are different and how they work. This article also highlights the many new CFS features, and will also address concerns about the preservation of the existing CFS configurations during upgrades from earlier versions of SonicOS.

Resolution

CFS Policy Assignment (CFS modes)

Below is the SonicOS 5.8 Security Services | Content Filter screen, where you choose the mode (type of CFS Policy Assignment):

The CFS configurations done in these two modes are independent and are preserved when you switch between them. You can configure settings for one mode while actively using the other. Some settings are in common in the two modes: a) HTTPS Content Filtering; b) CFS Server Failover; c) conditional settings for allowing or blocking web traffic when the CFS servers are temporarily unavailable or unreachable; d) checkboxes for blocking and / or logging the web sites caught by the policy.

Below is the Configure screen for the CFS via User and Zone Screens mode. It has tabs for Policy and Custom List. 

Below is the Configure screen for the CFS via App Rules mode. It doesn’t need tabs for Policy and Custom List, since those items are configured in the Firewall section, when using this CFS mode. 

Network | Zones screen and the two CFS modes

The Network | Zones screen looks different, depending on which of these modes is used.  When using the legacy CFS mode, each zone’s Content Filtering checkboxes are visible.  The Content Filtering checkbox must be enabled on LAN or other internal zones when CFS is used in Users and Zones mode.  The screenshot below shows the mouseovers which indicate the names of the CFS Policies used.  Setting the zone enforcement of Content Filtering is required in all previous SonicOS Enhanced versions.  As you can see below, in SonicOS 5.8, if CFS is used in App Rules mode, this is not necessary.

When using CFS via App Rules mode, there is no Content Filtering column displayed on the Zones screen.  The App Control column seen below applies both to CFS using App Rules, and to App Rules for other protocols, including FTP, SMTP, and HTTP, and to the new features on the Firewall | App Rules Advanced screen.  The App Control checkbox must be enabled on LAN or other internal zones when CFS is used in App Rules mode.

CFS via App Rules - Match Objects and Keywords

The App Rules mode of CFS uses Match Objects of two types (CFS Category Lists and CFS Allowed / Forbidden Lists). Below is a screenshot of the Firewall | Match Objects screen. Each CFS App Rule must have a CFS Category List Match Object specified, but the Allowed / Forbidden List Match Objects are always optional. 

The text strings for the Allowed / Forbidden list items can ONLY be for hostnames (e.g., facebook.com) or IP addresses; it CAN include web server port numbers like www2.myurl.com:8000.

The text strings for the Allowed / Forbidden list items CANNOT include any content after the first slash in a URL (like directory or filenames). These points are true for both modes of CFS, and have been true in all versions of SonicOS and even in the oldest SonicWall firewalls since 1997.

Examples of prohibited content for Allowed / Forbidden Lists would include:

a)    ‘facebook.com/album.php’ in the hope of blocking certain pages within Facebook like http://www.facebook.com/album.php?aid=3456789&id=9999999999 

b)    ‘cnn.com/swimsuit/?‘ in the hope of blocking http://sportsillustrated.cnn.com/swimsuit/?eref=sinav

At this time, the keyword feature (which allows blocking of websites if a keyword string shows up anywhere in the URL), is not possible using the CFS App Rules version of the Allowed / Forbidden Lists.  There is another type of HTTP Client App Rules, in which a keyword string can be partially matched in the URI, to achieve the same purpose.  That is the reason for the object #4 in the example above.  Its type is HTTP URI Content and the two strings it contains (fortinet and watchguard) will be blocked even if they show up in URLS of google searches like this:

http://www.google.com/search?sclient=psy&hl=en&q=fortinets

Below is a screenshot of the Firewall | App Rules screen.  Notice that it has a global allow checkbox (which must be enabled for any of the rules to work), and it contains both CFS Rules and a HTTP Client rule which uses the HTTP URI Content object mentioned above. Each App Rule can be disabled or enabled independently.

CFS via App Rules - Benefits

There are many benefits of using CFS via App Rules.  One of the newest is being able to apply Bandwidth Management to CFS App Rules (both Categories and / or Allowed and Forbidden Domains Lists can be used in this way).  The legacy mode of CFS only allows you to either block, allow or log access to web sites.  The Bandwidth Management options are available in the Action Object menu near the top.

One of the main benefits is more granular control of content filtering.  This is possible in many ways:

The first example: Enforcing CFS App Rules only for specific users, user groups, network address objects and groups, and/or exempting certain users objects and groups from them. Below is a new CFS App Rule screen where these options are clearly visible.

Another benefit: Having multiple CFS App Rules apply to the same user, user group or network address objects and groups. A great example of this is to be able to have different CFS actions for different CFS Categories, like this example of three CFS App Rules:

1) Block “gambling” during work hours
2) Block “malware” and “porn” all the time
3) Apply bandwidth limits on “sports” Monday through Frdiay, but not on weekends, all for the same user group.  

Such a combination (different CFS actions and schedules for different CFS categories) is not possible using CFS in legacy mode.  

CFS via App Rules – Prioritization Logic and Examples

Generally speaking, the CFS App Rules use a most specific logical basis, when dealing with multiple rules with different users or user groups.  If one App Rule applies to everyone, and a second App Rule applies to a user group, the CFS behavior for a user in that group will be dictated by the second policy only.

One of the concepts you must be aware of when deploying multiple CFS App Rules is the effects of redundancy.  You want to avoid having overlaps in the categories that the App Rules block.  The reason for this is how the CFS Allowed / Excluded List and the Forbidden / Included List objects work in each CFS App Rule.

Below is a CFS App Rule which uses a Match Object named CFS block 44 sports; allow SI .   At the bottom, its Allowed List is set to the Match Object named sportsillustrated + cnn.com + si.com.  The multiple entries are needed because the various domains all do redirects to http://sportsillustrated.cnn.com/

This forbidden list will only apply to this CFS App Rule.  That means that if you have another CFS App Rule which blocks the sports category #44 and it also applies to your user, it would need its own allowed list entry using that same object.  Another way of saying this is that the additive logic which applies multiple CFS category blockages to users from multiple policies doesn’t apply to the Allowed / Forbidden customizations.

CFS via Users and Zones - Keywords, Allowed and Forbidden Domains per CFS Policy

One of the new features in SonicOS 5.8 is specific to using CFS via Users and Zone Screens: Now, you can have Keywords, Allowed and Forbidden Domains per CFS Policy. Each policy can be configured to use its own values (Per Policy), or to use global values, for these three types of customizations to the content filtering policy.

Below is a custom CFS Policy edit screen, where the Settings tab is shown; this is where these parameters are set to either the policy or global options.

CFS via Users and Zones - Prioritization Logic and Examples

The legacy mode of content filtering (via User and Zone Screens) uses CFS Policies, which are assigned to Zones and/or Users and User Groups. Each CFS Policy contains choices for blocked categories and customizations (allowed and forbidden domains and keywords). Like CFS via App Rules, the legacy mode of CFS offers a moderate amount of granular control for content filtering policies.

If there is no ULA / Single-Sign On configured on the firewall, the CFS Policies applied to computers are based on the settings for each zone, and based on IP Address Range settings. The zone settings, being more general, are trumped by the IP Address Range settings. 

Here is an example of that logic: 

An NSA 2400 appliance is running SonicOS 5.8.0.2-37o and has two LAN networks:  X0 (192.168.124.0 /24) and X2 (192.168.125.0 /24).
There are two CFS Policies: Default and ‘allow job and dating.’

The Default CFS policy in my example blocks categories 1-12 and the job search and dating categories. It is applied to the CFS properties of the LAN zone.

The custom CFS policy in my example blocks categories 1-12 but it allows the job search and dating categories. It is used in the CFS Policy per IP Address Range area, applied only to the X2 LAN Subnet (192.168.125.0 /24). 

The results are confirmed: porn is blocked and job search and dating sites are allowed.

When you have multiple CFS policies integrated with ULA (User Level Authentication) or SSO (Single-Sign On), the prioritization logic is most permissive / least restrictive.  Below we will see examples of both.

With ULA, the Default CFS Policy must be the most restrictive policy; custom CFS policies will grant additional privileges for certain users, user groups or zones. With SonicOS 5.8, the Default CFS Policy must have as many blocked categories as any custom policy.  This is because, by design, all users are subject to the Default CFS Policy. We have two detailed examples to illustrate these concepts.

Related Articles

• CFS Category 100
• GVC 4.9.14 and above are not connecting - Phase 1 Proposal does not match
• Initial and Advanced Firewall Setup for high security environments

Categories

• Firewalls > TZ Series
• Firewalls > SonicWall NSA Series