Configuring per Policy Category Blocking in CFS 3.0

03/26/2020 2,172 People found this article helpful 490,532 Views

Description

CFS 3.0 integrates Application Firewall infrastructure to implement more granular, flexible and powerful content filter policy control. CFS 3.0 is available on SonicOS 6.2.5.3 and earlier.

With CFS 3.0 you can:

Create per policy CFS Allow/Forbidden lists.
Assign CFS policy per network address objects, as well as per users / groups and network zones.
Allow configuration of bandwidth management policies based on CFS website categories
Add per action bandwidth aggregation method in the application firewall and do the bandwidth management based on "Bandwidth Aggregation Method".
Significantly improve HTTPS Content Filtering by using SSL certificate common name in addition to web server IP address for the HTTPS filtering
Add new CFS categories
Change CFS Categories.

With the introduction of CFS 3.0, users are given two methods to configure CFS to choose from:

1. Via User and Zones Screens ( the legacy method, enabled by default, on fresh installs or upgrades)
2. Via App Rules

When CFS Policy Assignment is set to Via User and Zone Screens, it can be configured in the old way. When Via App Rules is selected, the content filter function is controlled by Application Firewall CFS policies which is defined in the Firewall | App Rules page. In addition to the above, IP based HTTPS Content Filtering has been improved (and changed) to HTTPS Content Filtering wherein HTTPS sites can be defined by host name.

This article illustrates configuring CFS policies per category.

Setting User Authentication in the SonicWall
Enabling CFS via App Rules and enable HTTPS Content Filtering
Creating CFS Category Objects
Creating CFS Allowed / Forbidden Objects
Creating Application Firewall Policies for CFS
How to Test

Resolution

Most Specific / Lease Restrictive is the default evaluation process of CFS policies assigned to different groups/users. Most Specific always has the highest priority (i.e. CFS policy for “All” group is least specific, CFS policy for local/authenticated group is more specific; CFS policy for a user is most specific. When policies are at the same level of specificity, the least restrictive option has the highest precedence.

Example 1:

Alex is part of Engineering and Alex is part of San Jose employees.

Group San Jose is not allowed to access Sports.

Group Engineering is allowed to access Sports.

Result is Alex is allowed to access Sports – consistent with today’s CFS policy evaluation logic where least restrictive option among groups has higher precedence)

Example 2:

Group “All” is allowed to access Sports.

Group “Engineering” is not allowed to access Sports.

Alex (who is part of Engineering) will not be allowed to access Sports, because CFS policy for Engineering group is more specific than CFS policy for “All” group (even though “All” group policy is less restrictive) – this is consistent with current CFS implementation where policy assigned to a specific Group has higher precedence than “Default” policy enabled on a zone.

Group “All” (default) can be used to create ip subnet (address object/group) or zone based CFS policies.

Multiple Policies assigned to same group:

When multiple CFS policies are assigned to the same group, the evaluation logic is additive:

Example:
CFS policy 1: Engineering is not allowed to access porn, gambling, adult content.

CFS policy 2: Apply BWM for Engineering when accessing Sports, Multimedia, Social Networking at 1 Mbps.

The result of the above policies is that Sports access will be bandwidth managed at 1 Mbps when accessed by a member of Engineering group even through “CFS policy 1” implies that Sports should be allowed for Engineering.

In this scenario, three user groups are defined and a CFS policy is created for each user group with allowed/forbidden lists for each.

The following are the User Groups created with their respective CFS allowed/forbidden lists and allowed/blocked CFS categories.

1. Full Access:

Categories Blocked 1 to 12 , 16 & 28. Remaining Categories are Allowed.

Forbidden Domains: Gmail.com, Facebook.com, Orkut.com

2. Restricted Access:

Categories Allowed: 20,27,33,34,41,48,58. Remaining Categories are Blocked.

Forbidden Domains: Gmail.com, Facebook.com, Orkut.com

3. Limited Access:

Categories Allowed 29 & 30. Remaining Categories are Blocked.

Allowed Domains: ESPN.go.com

Setting User Authentication in the SonicWall

The following users groups are created in the Users | Local Groups page. if using LDAP, the user groups can be imported from Active Directory. For more info on configuring LDAP: How to setup CFS policies with LDAP and SSO to restrict Internet access on CFS 3.0

If Single Sign On (SSO) is not used, create the following LAN to WAN rules.

Enabling CFS via App Rules and enable HTTPS Content Filtering.

Login to the SonicWall Management GUI.
Navigate to the Security Services | Content Filter page.
Set CFS Policy Assignment to Via App Rules.
Click on Accept to save the change.
Click on the Configure button under Content Filter Type | SonicWall CFS
Check the box under Enable HTTPS Content Filtering.

Creating CFS Category Objects

Navigate to Firewall | Match Objects
Create the following Objects.

Creating CFS Allowed / Forbidden objects

Create the following objects under Firewall | Match Objects

Creating Application Firewall Policies for CFS.

Navigate to Firewall | App Rules
Check the box under Enable App Rules
Create the following policies.

How to Test:

Test by going online from a PC behind the SonicWall. You will be prompted for a username and password (If not using SSO). Depending on group membership, the user will be either blocked or allowed to the requested site.

The following messages would be logged in Log | View page.

If the option Log using CFS message format is checked on the Application Firewall policy under Firewall | App Rules, blocked messages would be logged in the following format: