Feature/Application:
Starting with SonicOS 5.8.0.0, SonicWall Content Filtering can also be configured using Application Firewall Infrastructure (App Rules) in addition to the legacy CFS that uses User Groups and Zones (Pre SonicOS 5.8.0.0) Enforcement.
This article describes all aspects of configuring Content Filtering Service 3.0.
Using CFS with Application Firewall infrastructure allows more granular, flexible and powerful CFS policies enforcement. The following are some of the advantages of CFS with Application Firewall Infrastructure:
Note: CFS and App Rules features are license based.
On the Security Services | Content Filter page, users are given a choice to select between Via User and Zone Screens and Via App Rules. After selecting Via App Rules and clicking on the Accept button, the SonicWall Filter Properties window, under Content Filter Type | Configure, would have only 2 tabs.
On this page we create the CFS blocked categories objects and CFS Allowed/Forbidden objects.
-3.0-Overview---SonicOS-5.8-and-above.-kA1VN0000000Kze0AE-0EMVN00000EoKZv.png)
To create an object for blocking categories, select CFS Category List. This list is similar to the URL List of the User/Zone based CFS.
CFS Allow/Forbidden List
To create a custom list of allowed or forbidden domains:
Select CFS Allow/Forbidden List under Match Object Type. You could also load the allow/block list from a file containing the name of the domains. Each entry in the file should be separated by a line. The maximum size of the file is 8192 bytes. If Enable HTTPS Content Filtering is enabled on the Security Services | Content Filter page, the Allowed/Forbidden Match Object entries would be allowed or blocked for either HTTP or HTTPS traffic.
Under Match Type, select any one of following Match Type options:
Example: Given the following content, "Google.com":
App Rules On the App Rules page we configure the policies for CFS. The following options can be set when creating an App Rule:
| Policy Name: | Unique name for the policy |
| Policy Type: | CFS |
| Address: | Address Object/Group containing IP addresses of internal hosts in the LAN, DMZ, WLAN, VPN, SSLVPN or Custom Zone, to be included for this CFS policy. |
| Exclusion Address: | Address Object/Group containing IP addresses of internal hosts in the LAN, DMZ, WLAN, VPN, SSLVPN or Custom Zone, to be excluded from this CFS policy. |
| Match Object: | The CFS object created earlier under Match Objects page. The Match Object must be of type CFS Category List. |
| Action Object: | Actions define how the App Rules policy reacts to matching events. You can choose a customizable action or select one of the following predefined actions:
The following custom action can be used when using App Rule with CFS:
|
| User Groups | Select the User Groups to be Excluded or Included in this policy. |
| Schedule | Select a Schedule created under System | Schedules |
| Enable Logging | When this policy is triggered, the action selected above would be logged in App Firewall format. See here. |
| Log using CFS message format | Checking this box would log the message in CFS format instead of App Firewall format. See here. |
| Log Redundancy | Specifies the minimum number of seconds between log entries for multiple matches to the same policy. For example, a log redundancy setting of 10 will log no more than one message every 10 seconds for each policy match. |
| Zone | Select LAN, WLAN, DMZ, SSLVPN, VPN |
| CFS Allow List | Select a previously created CFS Allow/Forbidden List object. This object must be of Match Object Type CFS Allow/Forbidden List |
| CFS Forbidden List | Select a previously created CFS Allow/Forbidden List object. This object must be of Match Object Type CFS Allow/Forbidden List |
| Enable Safe Search | Allows you to force Web search sites like Google and Yahoo that have content restriction options always to use their strictest settings. |
Different Users/User Groups:
Most Specific / Least 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. In legacy CFS implementation the 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.
CFS Via User and Zone Screens
CFS via user and Zone Screens is the legacy CFS configuration where multiple policies are configured and assigned to User Groups and IP Addresses with CFS enabled on the zones. The Enhancement made to this mode of configuring CFS is the capability to configure custom Allowed/Forbidden list to each CFS policy.
On the Security Services | Content Filter age, select Via User and Zone Screens and click on the Accept button at the top.
Selecting this option would disable any App Rules based CFS policy under the Firewall | App Rules page.
Click on the Configure button to bring up the SonicWall Filter Properties window.
-3.0-Overview---SonicOS-5.8-and-above.-kA1VN0000000Kze0AE-0EMVN00000EoKZn.png)
-3.0-Overview---SonicOS-5.8-and-above.-kA1VN0000000Kze0AE-0EMVN00000EoKa4.png)
In addition to the above, the following enhancements have been made globally - applicable to both CFS Via App Rules and User and Zone-based CFS:
CFS Custom Category
This option enables you to customize CFS categories thus overriding global CFS database ratings. For eg. in the screenshot below, cnn.com, which is rated "News and Media" by the global CFS database, is re-rated as Information Technology/Computers - Category 27.
In the the example above, cnn.com (global CFS category - News and Media) is given a custom category of Information Technology/Computers, which replaces the global category . If the category News and Media is blocked but cnn.com needs to be allowed, re-categorizing it as an allowed category (in this eg. Information Technology/Computers) would allow cnn.com. The entries here are interpreted as "suffix strings" meaning any prefix added to cnn.com, eg. us.cnn.com, will be treated as belonging to the custom category.
The earlier IP based HTTPS filtering filter HTTPS traffic based on server IP addresses. The enhancement described here is to applicable to both IP addresses and hostnames for rating HTTPS websites. HTTPS Content Filtering is applicable for the domains entered in the Custom List and the Match Objects entries in Allowed/Forbidden List under Firewall | Match Objects page.
Hostnames are obtained through two ways:
1. Examine SSL Client Hello messages and if it supports SSL server name extension, it will have hostname included in the SSL Client Hello. This hostname is used to get rating information.
2. Another method is to examine Server Hello messages to get certificate Common Names (CN) from the certificate and use the same to get rating information.
The following CFS categories have been added in the new firmware: