Blocking Facebook by Schedule using FQDN Address Objects and Access Rules

10/14/2021 29 17745

DESCRIPTION:

RESOLUTION:

Resolution for SonicOS 6.5

This release includes significant user interface changes and many new features that are different from the SonicOS 6.2 and earlier firmware. The below resolution is for customers using SonicOS 6.5 firmware.

Feature/Application:

When filtering Facebook by App Rule or App Control Advanced and using a schedule. A user who establishes a connection prior to the schedule activating is still able to update content from Facebook when any new connection from another client would be blocked by the enforced schedule. This occurs for two reasons:

1. Because the session is already established and the SonicWall cannot decrypt the HTTPS content without the use of DPI-SSL.
2. Facebook also delivers content using a different domain. "fbstatic-a.akamaihd.net"

This article describes how to block Facebook by using FQDNs and Access Rules on a Schedule.  

Note: The IP addresses shown here are subject to change by Facebook Inc.

Procedure:

Step 1.

1. Click Manage in the Top navigation Menu
2. Create 2 FQDN address objects under Objects | Address Objects:
3. Click on Add and create 2 FQDN as below

Step 2. Create an Address Group

1. Click Manage in the Top navigation Menu
2. Click Objects | Address Objects
3. Click on Address Group Tab
4. Click on Add
5. Add the objects from step 1
6. Click on OK
   

Step 3. You need 1 schedule under System>Schedules. This schedule will be for when Facebook is going to be blocked:

1. Click Manage in the Top navigation Menu
2. Click Appliance | System Schedules
3. Click on Add
4. Create Your schedule time List
   
5. Click on OK

Step 4. Create Deny Access rule

1. Click Manage in the Top navigation Menu
2. Click Rules | Access Rule
3. Click on Add
4. Add a Deny Rule as follows, using the schedule created in Step 3

Step 5. Now add the following Allow Rule:

Notes: If you have routed subnets behind the LAN that need filtering, you will need to create an Address Group that contains LAN Subnets and the Address Objects for those routed subnets and specify that group in the source of the Allow Rule.

If you also have other configured Zones that need filtering, such as a WLAN, you will need to add Rules from those specific Zones to WAN as well. You will also need to choose the appropriate source object on the Allow Rule. For example, in a WLAN to WAN filter, you would choose WLAN Subnets as the source.

Step 6. When the rules are first added, they will be out of order from what we need them to be so we will need to reorder them:

Before:

Hit the Up/Down Arrow of the Deny Rule and change the priority. In this example I set the priority of the Deny Rule to the Allow Rules priority of 2. Click OK to update.

The Rules should look like this after adjusting the priority:


Conclusion:
This effectively denies access to *.facebook.com and fbstatic-a.akamaihd.net when the schedule is active and then allows access when the schedule is not active. The FQDN objects will update automatically in the firewall using the DNS servers specified in the firewall.

Unlike App Control Advanced or App Rules that attempt to match content with matching signatures. This configuration prevents access to these sites at the initial SYN packet from the client.

Troubleshooting:

Verify that your firewall is able to resolve DNS. You can do this by using the DNS Name Lookup tool in System>Diagnostics. Lookup *.facebook.com and fbstatic-a.akamaihd.net and verify that they do resolve. You can also mouse over the 2 FQDNs in Network>Address Objects and it will show the resolved addresses. If DNS does not resolve to addresses, verify DNS settings under Network>DNS.

Resolution for SonicOS 6.2 and Below

The below resolution is for customers using SonicOS 6.2 and earlier firmware. For firewalls that are generation 6 and newer we suggest to upgrade to the latest general release of SonicOS 6.5 firmware.

When filtering Facebook by App Rule or App Control Advanced and using a schedule. A user who establishes a connection prior to the schedule activating is still able to update content from Facebook when any new connection from another client would be blocked by the enforced schedule. This occurs for two reasons:

1. Because the session is already established and the SonicWall cannot decrypt the HTTPS content without the use of DPI-SSL.
2. Facebook also delivers content using a different domain. "fbstatic-a.akamaihd.net"

This article describes how to block Facebook by using FQDNs and Access Rules on a Schedule.  

Note: The IP addresses shown here are subject to change by Facebook Inc.

Procedure:

Step 1. Create 2 FQDN address objects under Network>Address Objects:

Step 2. Create an Address Group and add the objects from step 1.


Step 3. You need 1 schedule under System>Schedules. This schedule will be for when Facebook is going to be blocked:

Step 4. Go to Firewall>Access Rules and choose LAN to WAN. Add a Deny Rule as follows, using the schedule created in Step 3:

Step 5. Now add the following Allow Rule:

Notes: If you have routed subnets behind the LAN that need filtering, you will need to create an Address Group that contains LAN Subnets and the Address Objects for those routed subnets and specify that group in the source of the Allow Rule.

If you also have other configured Zones that need filtering, such as a WLAN, you will need to add Rules from those specific Zones to WAN as well. You will also need to choose the appropriate source object on the Allow Rule. For example, in a WLAN to WAN filter, you would choose WLAN Subnets as the source.




Step 6. When the rules are first added, they will be out of order from what we need them to be so we will need to reorder them:

Before:



Hit the Up/Down Arrow of the Deny Rule and change the priority. In this example I set the priority of the Deny Rule to the Allow Rules priority of 2. Click OK to update.


The Rules should look like this after adjusting the priority:







Conclusion:
This effectively denies access to *.facebook.com and fbstatic-a.akamaihd.net when the schedule is active and then allows access when the schedule is not active. The FQDN objects will update automatically in the firewall using the DNS servers specified in the firewall.

Unlike App Control Advanced or App Rules that attempt to match content with matching signatures. This configuration prevents access to these sites at the initial SYN packet from the client.

 


Troubleshooting:

Verify that your firewall is able to resolve DNS. You can do this by using the DNS Name Lookup tool in System>Diagnostics. Lookup *.facebook.com and fbstatic-a.akamaihd.net and verify that they do resolve. You can also mouse over the 2 FQDNs in Network>Address Objects and it will show the resolved addresses. If DNS does not resolve to addresses, verify DNS settings under Network>DNS.