Using SonicOS 5.8 and App Rules for Granular Control of Access to Facebook

03/26/2020 5 9566

DESCRIPTION:
Using App Rules for Granular Control of Access to Facebook

RESOLUTION:

App Rules for Granular Control of Access to Facebook

This technote covers all of the configuration activities and concepts needed to accomplish this, including:

• Licensing Information
• Enabling of the Global Service and Zone Settings
• How Application Visualization uses the Signatures
• Creation of Match Objects using Categories, Applications, and Signatures
• Creation of App Rules, which use Match Objects, Action Objects and optionally, Schedule Objects
• Creation of Schedule Objects
• Logging of Application Control events
• Miscellaneous Notes
• A complete list of Facebook Signatures in SonicOS

Licensing Information

The Comprehensive Gateway Security Suite (CGSS) is the bundled service that you need for Application Control.  You also receive the Content Filtering Service, Gateway Anti-Virus, Intrusion Prevention Service and Anti-Spyware services with this bundle.  With this combination of features, you can protect against malware and instrusions at the gateway level, even as you are able to control and visualize signatures, applications and signatures.
 
Once the proper licensing is in place, there are three settings which must be enabled globally:

1)    App Control must be enforced on the zones (on the Network | Zones screen; by default it is already on for LAN and WAN zones).  This is done by editing each zone’s properties using the Configure buttons on the right.

Enabling of the Global Service and Zone Settings

2)    The App Rules feature must be enabled (on the Firewall | App Rules screen).  On this page, there is no Accept button, so you must hit the Enter key on your keyboard to submit this change.

3)    The App Control feature must be enabled (on the Firewall | App Control Advanced screen). 

How Application Visualization uses the Signatures

The signatures used in Application Intelligence are organized in a hierarchical manner which allows granular control:  Category | Application | Signature. The hierarchy is easy to see on the Firewall | App Control Advanced screen.  Each Signature has an ID number and is a member of an Application.  Each Application is a member of a Category.  The signature ID numbers are  used in both Applicaton Control and Application Visualization.  Below is a screenshot of the Dashboard – Real-Time Monitor screen from the same firewall we will use for the Facebook example.  The data in the top Applicatons pane is shown with traffic type legends if you choose those options.  Below are two screenshots which show you how to do this.

The legends used in the Dashboard (part of the Application Visualization features) include the type of traffic and in most cases, a signature ID.  For example, MS Terminal Services (signature #436), Gmail (signature #3440) and YouTube (signature #5728) are visible below in the Dashboard | Real-Time Monitor screen.  The display also includes general types of traffic which have no signature (General DNS and General HTTP are commonly seen).

Creation of Match Objects using Categories, Applications, and Signatures

Now we will look at Facebook signatures.  A complete list of them is at the end of this article.  On the Firewall | App Control Advanced screen, scroll down to the middle, and locate the View Style: Category: menu.  Select SOCIAL-NETWORKING.  The screen will then change automatically, and the applications listed will be limited to the ones in this category.

Next, the second part of the View Style settings, to the right of the selected category is an Application menu; select Facebook in it.  The screen will change again.  Finally, go further to the right and select Viewed By:  Signature.  The screen again changes to reflect your choices:  Category SOCIAL-NETWORKING; Application Facebook; View By Signature.

These three steps allow you to filter the thousands of signatures to find the ones we need for this task.  This filtered view of the Facebook signatures in SonicOS can be sorted by clicking on the column headings (Signature ID, Name, etc.). 

You will notice that the signatures have configurations possible for blocking and logging.  By default, all signatures have logging enabled.  We we will not be using the block actions on the signature level in this example.  The granular control we wish to enforce requires us to deploy these signatures inside Application List objects and App Rules.

Match Objects are used for App Rules of all kinds.  There are basic kinds, for customized rules which apply to certain protocols like email and FTP, and there are others which are used in Content Filtering (CFS).  On the Firewall | Match Objects screen, there is a feature which allows administrators to combine App Control Signatures so that they can be applied in policies. 

These are called Application List Objects and the button for creating them is below.  Once we create a few of them, you will see that there are actually three types of objects:  Application Lists, Application Signature Lists and Application Category Lists.  We use all three types in this example.

The user interface for creating Application List Objects is very flexible.  First we will use the interface that allows us to choose individual applications and signatures.  Notice the (turquoise-highlighted) area where you can choose Application or Category.  Application is chosen and is thus in bold. The default state for this screen has all of the categories for Application Control enabled (see yellow highlight). 

Notice that the checkboxes for Category, Threat Level and Technology inside the dark blue bar are global controls which can be used to toggle all of the choices below, checking or unchecking all of them.  In our Facebook example, we will begin by unchecking the global Category checkbox.

Below are screenshots of unchecking the global Category checkbox and then selecting SOCIAL-NETWORKING.  The screen is dynamic, and instead of having a list of applications for all categories like above, only the applications listed under SOCIAL-NETWORKING are visible in the below screenshot.  I’ve scrolled down to where the Facebook Applications are listed.

Each Application has two control elements in the user interface:  a) an Add button (plus sign) and b) an Expand Category arrow.

When you click the add button, it changes to a green checkmark, and the whole application (and its member signatures) is added to the Application List Object being created (see the yellow highlighted area on the right side, where Facebook is under the heading labeled “Application Group”).

When you click the arrow for an application, the arrow turns down and the signatures inside the application are listed with checkboxes, so that you can select multiple items to group together for your granular control needs.

In our example, we will be using both of these techniques.  First, we will need a Facebook Application List so that we can easily block or allow all Facebook access at certain times of the day.  Below is a screenshot showing that by default, there is a checkbox enabled:  Auto-generate match object name.  It generates rather long names which contain long strings of numerals.
 

I wanted a simpler name for my general Facebook match object, so I unchecked that and named it “SOCIAL-NETWORKING - Facebook”

Once saved, the new Application List object appears in the list:

Next, we go back and create another Application List object using the Category part of the User Interface.  This one is more general – two whole categories - it includes all Social Networking and Gaming applications and signatures.  This is a sledgehammer which can be used against hundreds of user activities which get in the way of worker productivity.

Next we create an Application List object containing the Facebook signatures needed for read-only access. There are three signatures which control logins to Facebook on HTTPS (named Facebook SSL Login – Facebook SSL Login 3).  There are four signatures named Facebook -- Browsing Activity 1 – Facebook -- Browsing Activity 4 which control the display of regular news feed pages for a Facebook user. 

The Application List object shown below – named “Facebook SSL Logins + Browsing Activity 1-4 Siglist” – contains only those seven signatures.  This object doesn’t include 40 other Facebook signatures, so any it  doesn’t include common Facebook activities like status updates, uploading photos or videos, posting comments or likes, or sending messages.

Now we have three Application List Objects, with which we can create an example of granular control.

a) SOCIAL-NETWORKING - Facebook Application List
b) SOCIAL-NETWORKING + GAMING Category List
c) Facebook SSL Logins + Browsing Activity 1-4 Siglist

Creation of App Rules, which use Match Objects, Action Objects and optionally, Schedule Objects

With these match objects ready, we now turn to the Firewall | App Rules screen, where we will create app rules that control Facebook access, as well as activities on all Social Networking and Gaming sites.  Our deployment scenario is a company which wants to block any kind of Social Networking and Gaming during business hours.  This will be the first policy we create.  Click on the Add New Policy button on the Firewall | App Rules screen.  In the edit window that appears, you must specify a Policy Name, Policy Type, Match Object and Action Object.  All other parameters are optional.  For this one, we choose the App Control Content type, the Social Networking and Gaming category list as the match object and the Reset/Drop as the action.  Finally, we choose the Work Hours for schedule.

The finished rule looks like this:

Creation of Schedule Objects

Now we go to the System | Schedules screen to inspect the definition for the Work Hours schedule object we used above.  It’s defined as Monday through Friday from 0800 to 1700 hours.  On this screen, I create a custom schedule object named Friday 5:00 – 6:30 PM.  Note:  you must click the add button to add your selection of days and hours into the schedule object.  You can have more than one set of days / hours in your object.

Thus, with this on App Rule in place, Facebook (and all other SOCIAL-NETWORKING and GAMING sites) will be unreachble between 8:00 AM and 5:00 PM on weekdays.  The screenshot below shows what that looks like on a computer which sits behind the firewall.  The Reset/Drop action on the rule doesn’t give any clue to the users why their access failed.  There are other features available on SonicOS (the Content Filtering Service) which serve up block messages when users attempt to go to prohibited sites, but the App Rules behave differently.

I have also created an App Rule which blocks all Facebook signatures during all non-Work Hours periods, which is a pre-defined schedule object called After Hours.  This general blockage will have exceptions in other more granular app rules which use different schedules and different action objects.

Next, we create an App Rule which allows login and read-only access to Facebook during the hours 5:00 – 6:30 PM on Friday. We will use the match object named Facebook SSL Logins + Browsing Activity 1-4 Siglist  and the action we will apply to the rule is BWM – Low.  This means that we are enforcing a low throughput level to the traffic in the Bandwidth Management features of the firewall.  Other traffic will receive higher priority than this traffic to Facebook.  The app rule is named FB Readonly BWM Low - Fri 5:00-6:30 PM and is shown below.

This more specific policy applies only to a 90-minute time window on one day a week, and thus it is seen as an exception to the more general rule which blocks all Facebook activities during the After Hours time schedule.  Below are two screenshots showing a user who is accessing https://www.facebook.com and successfully logging in and seeing a news feed.

While reading Facebook content after login is allowed during this Friday evening time period, no form of writing is allowed.  Below are screenshots of both Facebook comments and Facebook messages failing.  Status Updates also fail, but there is no error message so I didn’t provide a screenshot for it.  The good news is that there is a specific log message proving it works.&