[轉貼]sonicwall 阻擋ipad facebook app

Article Applies To:

Gen5: NSA E8500, NSA E7500, NSA E6500, NSA E5500, NSA 5000, NSA 4500, NSA 3500, NSA 2400, NSA 240
Gen5 TZ Series: TZ210, TZ210W
Firmware/Software Version: SonicOS Enhanced 5.8.0.0 and above

Gen5 TZ Series: TZ 200, TZ200W, TZ100, TZ100W
Firmware/Software Version: SonicOS Enhanced 5.8.0.2 and above

Services: App Control Advanced 

Feature/Application: 

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

Next-Generation Firewalls need to deliver on the areas of networking that are the biggest concerns to customers.  On the modern internet, that means going beyond the traditional abilities to control access based on port numbers and IP addresses and networks and beyond stateful packet inspection.  These Next-Generation Firewalls must be aware of the difference between traffic types on the application layer.  In 2011, that means Facebook, Youtube, online activities for email, games, music, filesharing, instant messaging and a few thousand other web sites and types of traffic.

For productivity and security reasons, the ability to control users’ access to popular web sites is important.  The goals of organizations include limiting exposure to the most risky user activities and to prevent the hogging of bandwidth by these lower priority traffic types.  SonicWALL firewalls running SonicOS 5.8.0.3 (the latest Early Release firmware as of June 18, 2011) can do this using a very flexible set of features called Application Control.  Below you will see:  “There’s an App Rule for that!”

This technote will show an example in which a SonicWALL NSA 2400 is used to enforce a set of granular application controls which block Facebook or allow different levels of Facebook access at different times of the day.  SonicOS has thousands of signatures for App Control; for Facebook, we have 47 signatures (as of June 2011), which can be used to allow a variety of access types, including read-only, full read / write access and many other variations.  

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 topApplicatons 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 DNSand 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 selectViewed 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 Policybutton 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.  In the log message, the signature name and ID # are visible: Facebook -- News Feed Post Status Update (SID #6533)

2    06/17/2011 18:17:08.880    Alert    Application Control    Application Control Detection Alert: SOCIAL-NETWORKING Facebook -- News Feed Post Status Update , SID: 6533, AppID: 253, CatID: 76    192.168.124.200, 3048, X0    69.171.224.13, 80, X1

Screenshot of Facebook comment failing:

Screenshot of Facebook message send failing: 

After the scheduled App Rule time period ends at 6:30 PM, access to Facebook is no longer allowed.  Below is a screenshot of my test PC after I closed the previous browser tab and opened a new one so that the effects of the new time period were easy to see.  

NOTE:  Browser cache will continue to show you previously downloaded content in your browser window after you enter a time period where you are blocked from Facebook.  The content delivery inside a Facebook web page is full of very advanced content feeds inside invisible HTML frames, and thus it is easy to be fooled by what you see.  If you look carefully, you may see signs of the web page trying and failing to get updates.  Cursors will be animated and the browser’s status bar on the bottom may talk about trying to get content.

Next, we explore another type of App Rule, on which allows full access to Facebook.  The example company may have a marketing team which uses Facebook to publicize new products and services.  Imagine that they do a weekly Saturday morning session on Facebook.  
First, we create another schedule object:  Sat 8:00 am – 2:30 pm

Remember that there is already an App Rule which blocks all Facebook activities After Hours.  A new app rule will be added that will allow the marketing team to do their work.  This new app rule will be more specific.  It will use the above schedule, and a new Application Signature List containing only some of the Facebook signatures.  The marketing team needs to be able to log in, read, post updates, photos, and videos in the newsfeed, create and edit groups, send messages, and post likes and comment on other items.  This new match object is named Facebook for Marketing SigList and is visible below.

Here is another view of the same match object in the edit window

“There’s an App Rule for that!”  So, now we create the App Rule.  This rule shows another granular control feature:  The ability to specify a specific zone.  In our example company, they have a dedicated firewall interface X2, which is assigned to a custom security zone named ‘LAN2.’  This App Rule only works from computers attached to it.  In SonicOS, each interface usually has a dedicated IP subnet associated with it.  In this case, the computers in LAN2 (Marketing) use the IP addresses numbered 192.168.125.x.  This App Rule specifies the Marketing match object, the BWM High action object, the Saturday schedule object, and zone LAN2; its name is ‘FB for Mark’g LAN2 BWM High Saturday.’    

To review the App Rules in place which affect Facebook, we have

a)    one which blocks all SOCIAL-NETWORKING during work hours
b)    a second which blocks Facebook after hours
c)    a third which allows read-only Facebook access on Friday nights
d)    and now the latest one, a more permissive rule for Marketing from the LAN2 zone on Saturdays.

On Saturday morning, only app rules b) and d) are relevant. The App Rule FB for Mark’g LAN2 BWM High Saturday should not allow Facebook access from the X0 LAN.   Below is a view from the computer on the X0 LAN.  Both the HTTP and HTTPS versions of Facebook are recognized and blocked.

While the rest of the company is shut out from Facebook, Marketing’s social networking intiatives are not only allowed, they are being given the highest bandwidth priority.  Below is a screenshot from a marketing laptop which is sitting on the X2 (LAN2 zone) interface.

Even this company, with its Saturday Facebook Marketing campaign, needs to be more flexible than what has been configured so far.  There are always going to be people who need special privileges, and for that, we can create a fifth app rule which uses the Users / Groups feature.  Our example company has a CTO who have access to Facebook for business-related activities at any time.  First we enable the User Login HTTP / HTTPS checkboxes on the X0 LAN interface.  Next, we create a Local User account – CTO Manish and a User Group – Top Tech on the firewall, and add the user as a member of the group.

Now it’s time for our final App Rule, which allows the CTO his Facebook access.  This rule uses the SOCIAL-NETWORKING - Facebook Application List object, the BWM High action object, and specifies that only the user group Top Tech can use it.  I’ve also shown how this app rule can have a differen frequency of logging events by unchecking the global Log Redundancy Filter option and specifying the value of 120 seconds (compared to global of 12).

What are the expected results from the combination of app rules in place?

1)    No unauthenticated users, besides the Marketing people on LAN2, should have Facebook Access of any kind.
2)    Marketing still is limited to their app rule, which doesn’t allow some Facebook activities like IM Chat and Poke
3)    Most importantly, the Top Tech user group can do any Facebook activity after they log into the firewall with a user account

Here is the CTO logging and getting to Facebook, where he can even do Facebook chat and pokes, something the marketing team cannot do.

Finally, the same Facebook chat features and pokes fail from the marketing LAN2 network.

Logging of Application Control events

SonicOS logs the blocked attempts to reach Facebook under the Application Control category.  The log events that include the phrase ‘Application Control Prevention Alert’ are the ones that directly relate to blockages.  Please note that the Detection Alerts will occur even when access is being allowed.  Both the Prevention and Detection types are colored yellow as Alerts.  

Below a screenshot shows a log which is using a filter for the Application Control category and prevention alerts are seen for three of the Browsing Activity signatures.  Each log event shows details including the soruce and destination IP address and port number, the signature name, signature ID, and the ID number of the application and category to which the signature belongs.

Miscellaneous Notes

The Application List user interface allows you to start with a search..  The screenshot shows a search which showed me that Twitter is categorized under IM rather than where I expected it to be (Social Networking).  From the search results, I can create a match object of any type.

A complete list of Facebook Signatures in SonicOS

List of Facebook signatures as of June 18, 2011, sorted alphabetically: