3.7. Application Control

Home Prev	cOS Core 15.00.02 Administration Guide	Next

IP policies can be set up so they apply only to traffic related to specific applications. An example of an application that might require this kind of administrator control is traffic related to BitTorrent. Applying IP policies based on the application type is known in cOS Core as Application Control.

The application control subsystem is driven using a database of application signatures. Each signature corresponding to one type of application. The entire current signature database is listed in the separate reference document entitled cOS Core Application Control Signatures.

Application Control is Subscription Based

Application control is a subscription based feature and the current cOS Core license must include a valid subscription date for the feature to work. See Appendix A, Subscription Based Features for more details about this and for details about the behavior when a subscription expires.

The Application Filter in an IP Policy is a Special Usage

Note that a filtering option in an IP Policy object is the Application Filter. This uses the application control subsystem but only the first packet of a new connection is examined to determine the application type. Examination of a single packet means only a limited subset of the application control database can be identified.

This Application Filter property will not be discussed further in this section but more explanation of its use can be found in Section 3.6.2, Creating IP Policies and Section 4.10, Application-based Routing.

Enabling Application Control

Application Control can be enabled by Associating an Application Rule Set with an IP Policy object.

An Application Rule Set is first created which defines how an application is to be handled, then one or more Application Rule objects are added to it. The entire rule set is then associated with an IP Policy object.

Example 3.49. Configuring a Basic Application Control Policy

This example creates an IP Policy to allow connections originating from the LAN network which match the *_groups signature filter. These will include access to sites such as yahoo_groups and google_groups . Note: Default action is Deny, meaning that all other applications matching the IP Policy will be denied.

Command-Line Interface

First, the appcontrol command must be used to create a list of the applications we are interested in.

Device:/> appcontrol -filter -name=*_groups -save_list

This creates a list with an index number of "1".

Next, create an ApplicationRuleSet called my_ac_ruleset:

Device:/> add Policy ApplicationRuleSet my_ac_ruleset

Then, change the CLI context to be my_ac_ruleset:

Device:/> cc Policy ApplicationRuleSet my_ac_ruleset

Device:/my_ac_ruleset>

Now, add the ApplicationRule object:

Device:/my_ac_ruleset> add ApplicationRule
			AppFilter=1(filter)
			name=my_ac_rule

Then, return to the default context:

Device:/my_ac_ruleset> cc
Device:/>

Finally, the created application rule is used in an IP Policy:

Device:/> add IPPolicy Name=allow_ac_group
			SourceInterface=LAN
			SourceNetwork=LAN_net
			DestinationInterface=WAN
			DestinationNetwork=all-nets
			Service=all_services
			Action=Allow
			AppControl=Yes
			AC_RuleSet=my_ac_ruleset
			SourceAddressTranslation=NAT

InControl

Follow similar steps to those used for the Web Interface below.

Web Interface

First, define the Application Rule Set:

Go to: Policies > Firewalling > Application Rule Sets > Add > Application Rule Set
Specify a suitable name for the list, in this case my_ac_ruleset
Set the Default Action to Deny
Click OK

Next, define an Application Rule as a child in the previously created Application Rule Set.

Go to: Policies > Firewalling > Application Rule Sets > my_ac_ruleset > Add > Application Rule
Specify a suitable name for the rule, in this case my_ac_rule
Select Allow for the Action
Click Select Filter and enter, in the search filter, *_group
Click Select
Click OK

Finally, the created application rule is used in an IP Policy:

Next, go to: Policies > Firewalling > Main IP Rules > Add > IP Policy
Now enter:
- Name: allow_ac_group
- Action: Allow
Under Filter enter:
- Source Interface: LAN
- Source Network: LAN_net
- Destination Interface: WAN
- Destination Network: all-nets
- Service: all_services
Under Protocol Options:
- Application Control: ON
- RuleSet Selection: my_ac_ruleset
Under Address Translation:
- Source Translation: NAT
Click OK

Note that logging is enabled by default.

Additional Information About Application Rule Set

An Application Rule Set object will contain one or more Application Rule objects as children and these define an application and what actions are to be taken when the application is recognized by cOS Core.

An application rule set has a Default Action property which has a value of either Allow or Deny. If the action is set to Allow, everything is allowed unless it is specifically denied by a rule. If set to Deny, everything is denied unless it is specifically allowed by a rule.

Using application rule sets allows not only data for a certain application to be allowed or denied but also the following additional control:

Traffic Shaping Settings

Predefined cOS Core Pipe objects can be associated with the rule so the bandwidth limit specified by pipe objects can be placed on either direction of data flow or both.

This feature therefore allows bandwidth limits to be placed on a given application and, if used in conjunction with the authentication setting, on particular users or user groups using that application.

Traffic shaping is only relevant if the Application Control Rule has an action of Allow.

Applying Application Control to Specific Groups or Usernames

Sometimes, application control will need to be applied to a specific group of users or specific individual users. This can be achieved by doing the following:

Specify a list of the specific groups and/or usernames in a User Group object.
The Source or Destination User Group property of the associated IP Policy must be set to either use the previously created User Group object or the default group Anyone. The latter means that as long as the user is logged in to cOS Core, regardless of username or group membership, it fulfills the authentication criteria. For more information see Section 10.4, IP Policies Requiring Authentication.

Authentication Can Decide if an Application Is Allowed or Denied

Applying a User Group object to an IP Policy that also have an Application Filter enabled can be used to allow or deny specific applications based on the user or group that is authenticated to cOS Core.

Allowing a Connection Can Still Deny Applications

An Application Control Rule Set can be configured to either Allow or Deny applications, which means that depending on how the IP Policy and Application Rule Set is configured, it can behave different depending on chosen actions on both the IP Policy and Application Control Rule Set.
- IP Policy Action is Deny Or Reject
  
  In this scenario, regardless if Application Control is enabled or not, the connection will be denied based on the configured filter criteria for the IP Policy once the user is authenticated.
- IP Policy Action is Allow, Application Rule Set Default Action is Allow
  
  In this scenario the Application Rule Set is configured to Allow all applications by default. This can be useful for audit purposes but it can also be used to add specific applications to Deny action. Meaning once authenticated, specific applications can be denied.
  
  Any new application detected will be allowed by default.
- IP Policy Action is Allow, Application Rule Set Default Action is Deny
  
  In this scenario the Application Rule Set is configured to Deny all applications by default. Without adding any any additional Application Control Rules with action Allow , this would deny any application once the user is authenticated.
  
  By adding rule filters with action Allow for specific applications means that after authentication, only a select few applications can be configured to be allowed through the firewall.
  
  Any new application detected will be denied by default.
Authentication may be performed using any of the methods available in cOS Core Authentication Rule objects, including Identity Awareness.

Example 3.50. Configuring a More Complex Application Control Policy

This example will limit the usage by the user group called rogue_users to 0.25 Megabit of bandwidth for both uploading and downloading of data using BitTorrent. The example utilizes both traffic shaping using pipes and user authentication. Assume the following:

Membership of a user in a group called rogue_users is established by the authentication process. This might be done by using a RADIUS server or using other means such as authenticating against an LDAP server. The means of authentication is not discussed further.
A Pipe object called narrow_025_pipe has already been defined in cOS Core that permits this data flow.
An IP Policy object called lan_to_wan_policy has already been defined that allows connections from a protected internal network to the Internet.

It is assumed that all clients on the local network that access the Internet must be authenticated.

Command-Line Interface

First, the appcontrol command is used to create a filter for BitTorrent. This should also include the uTP protocol:

Device:/> appcontrol -filter -application=bittorrent,utp -save_list

Assume that this filter list is the third filter list created and is therefore assigned the list number 3. All filters can be displayed with the command:

Device:/> appcontrol -show_lists

Next, create an ApplicationRuleSet called my_ac_ruleset:

Device:/> add Policy ApplicationRuleSet my_ac_ruleset
			DefaultAction=Allow

Then, change the CLI context to be my_ac_ruleset:

Device:/> cc Policy ApplicationRuleSet my_ac_ruleset

Device:/my_ac_ruleset>

Now, add the ApplicationRule object:

Device:/my_ac_ruleset> add ApplicationRule
			Action=Allow
			AppFilter=3
			ForwardChain=narrow_025_pipe
			ReturnChain=narrow_025_pipe

Then, return to the default context:

Device:/my_ac_ruleset> cc
Device:/>

Associate this ApplicationRuleSet with the IP Policy:

Device:/> set IPPolicy lan_to_wan_policy
			AppControl=Yes
			AC_RuleSet=my_ac_ruleset

Next, create an User Group object containing the rogue_users group:

Device:/> add UserGroup Rogue_User_Group Members=rogue_users

Associate this User Group with the IP Policy:

Device:/> set IPPolicy lan_to_wan_policy SourceUserGroup=Rogue_User_Group

Note that the following pre-defined User Group would also allow application control to function:

Device:/> set IPPolicy lan_to_wan_policy SourceUserGroup=Anyone

InControl

Follow similar steps to those used for the Web Interface below.

Web Interface

First, define the Application Rule Set:

Go to: Policies > Firewalling > Application Rule Sets > Add > Application Rule Set
Specify a suitable name for the list, in this case my_ac_ruleset
Set the Default Action to Allow
Click OK

Next, define an Application Rule as a child.

Go to: Policies > Firewalling > Application Rule Sets > my_ac_ruleset > Add > Application Rule
Select Allow for the Action
Enable Application Control and add the signatures bittorrent and utp (both are required for BitTorrent).
Select Traffic Shaping Settings and move the pipe narrow_025_pipe into the Selected list for both the Forward chain and Return chain
Click OK

Finally, associate the User Group and Application Rule Set with the IP Policy:

Go to: Policies > Firewalling > Main IP Rules > lan_to_wan_policy
Under Advanced Filters:
- Set the Source User Group to Rogue_User_Group
Under Protocol Options:
- Set Application Control to On and select my_ac_ruleset
Click OK

Note that using the pre-defined User Group Anyone in the lan_to_wan_policy would also allow application control to function.

	Tip: BitTorrent signatures should include uTP
	As seen in the above example, when application control is configured to target BitTorrent, the two signatures bittorrent and utp should both be selected.

Note that using Application Control to filter P2P traffic such as BitTorrent is also discussed in an article in the Clavister Knowledge Base at the following link:

https://kb.clavister.com/324735846

The Strict HTTP Setting

Many protocols that application control examines are built on top of the HTTP protocol. In some cases where HTTP itself is being blocked by application control, a protocol built on HTTP may be erroneously blocked as well. To try to resolve this problem, the Strict HTTP setting can be disabled for the relevant Application Rule Set object. This will force application control to evaluate the entire protocol structure before making a decision on the protocol type.

Changing the Maximum Unclassified Packets

The cOS Core application control subsystem processes a connection's data flow until it decides if a connection is unclassifiable or not. The maximum amount of data processed to make this decision is specified in cOS Core as both a number of packets and a number of bytes. By default, these two values are:

Maximum Unclassifiable Packets: 5
Maximum Unclassifiable Bytes: 7500

When either of these values is reached, the unclassifiable decision is made. If the administrator needs to increase the maximum amount of data processed because some protocols are being incorrectly flagged as unclassifiable, then the values can be changed in one of two ways:

They can be changed globally in the cOS Core Advanced Settings.
The current global settings can be overridden for all rules in a rule set by selecting the Use Custom Limits option for an Application Rule Set object.

Application Content Control

So far, application control has been described in terms of targeting specific applications such as BitTorrent or Facebook™. However, cOS Core allows a further level of filtering within application control where the content of targeted applications decide if the traffic will be allowed, blocked or just logged. This feature is called Application Content Control.

	Note: Application Content Control is not CLI configurable
	The ability to configure application content control is not available in the CLI. Only the Web Interface or InControl can be used to configure this feature.

Application content control is configured on application rule objects within an application rule set. Application content control can be used to target specific content within a targeted application. Facebook™ provides a good example of how this can be applied. The rule can target Facebook and then application content can be used to target types of Facebook content such as specific games, applications, chat or messages.

If there are multiple IP policies in a rule set that are using deep content control, then all policies may need to perform the same filtering since a higher policy in the rule set might trigger before a lower one. For example, if only the Chrome browser is being allowed, all IP policies using application content control should test if the HTTP user-agent is Chrome.

Example 3.51. Application Content Control

This example shows how only the Chrome and Firefox browsers only will be allowed by an application rule using application content control.

Associating the application rule set created together with an IP Policy will not be included in the example but follows the same steps shown in the previous example.

InControl

Follow similar steps to those used for the Web Interface below.

Web Interface

First, define the Application Rule Set:

Go to: Policies > Firewalling > Application Rule Sets > Add > Application Rule Set
Specify a suitable name for the list, in this case browser_list
Set the Default Action to Allow
Click OK

Next, define an Application Rule in this rule set:

Go to: Policies > Firewalling > Application Rule Sets > browser_list > Add > Application Rule
Select Allow for the Action
Under Application Filter press Select filter.
In the Search field enter http
Select Matches specific applications
Open the Web node and select http from the list of matching applications
Press the Select button to close the filter dialog

Define an Application Content filter:

Select the Content Control tab
Set User Agent to Allow Selected
In the blank text field type firefox followed by enter and then chrome followed by enter.
Click OK

Lastly, associate this Application Rule Set with the appropriate IP Policy that triggers on the relevant traffic as shown in an earlier example.

As explained previously, the policy and therefore this rule set will only trigger if no previous rule has triggered for the same traffic.

	Note: String matches are a subset and case insensitive
	When specifying string matches for application content control, the matching function is case insensitive and always a subset function. In the example above, the string firefox is specified for the User Agent property and this will trigger on any version of Firefox since the agent field always contains this string.

Extended Logging

When using application content control, it is possible to enable logging for different content. This means that special log messages will be generated by cOS Core when the rule triggers on a configured piece of content.

For example, if the User Agent in application control has logging enabled and the Allow Selected string is set to firefox, this will allow the Firefox browser to be used and also generate a log message to indicate that Firefox caused the rule to trigger. The string firefox will be included in the log message.

The log messages generated by extended logging in application control will always be one of the following events:

application_content_allowed
application_content_denied
application_content
(The action was Ignore but logging is Yes.)

Example 3.52. Application Content Control with Logging

This example shows how access to Facebook™ can be allowed but the Facebook chat function disallowed using application content control. A log event will also be generated every time a user tries to use the chat function.

Associating the application rule set created together with an IP Policy will not be included in the example but follows the same steps shown in the previous example.

InControl

Follow similar steps to those used for the Web Interface below.

Web Interface

First, define the Application Rule Set:

Go to: Policies > Firewalling > Application Rule Sets > Add > Application Rule Set
Specify a suitable name for the list, in this case facebook_list
Set the Default Action to Allow
Click OK

Next, define an Application Rule in this rule set:

Go to: Policies > Firewalling > Application Rule Sets > facebook_list > Add > Application Rule
Select Allow for the Action
Under Application Filter press Select filter to open the filter dialog
Under Tag select Social Networking
Choose Matches specific applications
Open the Web node and choose Facebook
Press the Select button to close the filter dialog

Define an Application Content filter:

Select the Content Control tab
For Chat set Action to be Deny and Log to be Log
Click OK

Lastly, associate this Application Rule Set with the appropriate IP Policy that triggers on the relevant traffic as shown in an earlier example.

Data Leakage Can Occur

Application control functions by analyzing sequential streams of packets and a certain number of packets must be processed using signatures before a determination can be made as to which application it is.

This means that it is inevitable that not all the packets belonging to a targeted application can be caught and some data leakage will occur where some blocked traffic will arrive at its destination. However, when using IP rules or IP policies only, every packet of the triggering connection will be blocked and there is no data leakage.

Browsing the Application Control Database

In the Web Interface it is possible to browse the application control signature database of application definitions by going to Status > Tools > Application Library. This page provides an intuitive interface for searching the database and displaying groups of signatures as well as individual signature information.

In the CLI, the command appcontrol can be used to browse the signature database. Without any parameters, this command shows the database size. For example:

Device:/> appcontrol
		
Application library contents:
  842 application definitions.
  34 families.
  4 tags.

If tab completion is used after the command, all the definition families are displayed. For example:

Device:/> appcontrol <tab>
		
 antivirus/           file_transfer/     network_management/ thin_client/
 application_service/ forum/             network_service/    tunneling/
 audio_video/         game/              peer_to_peer/       unclassified/
 authentication/      instant_messaging/ printer/            wap/
 compression/         mail/              qosmos/             web/
 database/            messenger/         routing/            webmail/
 encrypted/           microsoft_office/  security_service/
 erp/                 middleware/        telephony/
 file_server/         music_player/      terminal/

These families consist of the individual definitions. For example, to view the two definitions in the compression family, use the command:

Device:/> appcontrol compression

compression - Compression:

  ccp
  comp

2 application(s)

To view a single definition, the individual name can be used without the family. For example, to display the comp definition within the compression family:

Device:/> appcontrol comp
		
comp - Compression

COMP protocol is used for data compression over PPP.

Family:      Compression
Risk Level:  1 - Very low risk
Tags:
Revision:    0
Enabled:     Yes

The Tags and Risk Level add further information to each definition but are not part of the definition híerarchy. The Risk Level indicates the degree of threat that this particular application poses. The Tags provide more information about the data traffic related to the application, for example High Bandwidth might be a typical tag.

It is possible to search the definition database by using any of the filter parameters:

name
family
risk
tag

The name parameter must always be the first in a search but the asterisk "*" character can be used as a wildcard. For example:

Device:/> appcontrol -name=* -family=mail -risk=HIGH

As demonstrated earlier, the -save_list option is used to save a filter list so it can be used with IP rules and IP policies.

Managing Filters

As shown in the application example above for controlling BitTorrent, the appcontrol CLI command is also used to create saved filters which are then used with the CLI in ApplicationRule objects. For example, the following will create a saved filter for BitTorrent:

Device:/> appcontrol -filter -application=bittorrent,utp -save_list

The -application parameter specifies the individual signatures by name. An alternative is to use the -name parameter which allows wildcarding and searches the signatures names looking for character pattern matches. For example, we could have specified:

Device:/> appcontrol -filter -name=bit* -save_list

All the signatures with names that begin with the prefix bit would have been selected. It would not have been possible to select bittorrent and utp using the -name parameter.

All the saved filters can be displayed with the command:

Device:/> appcontrol -filter -show_lists

To delete all saved filters, use the command: All the saved filters can be deleted with the command:

Device:/> appcontrol -delete_lists=all

Individual saved filters can be deleted by specifying the number of the filter after -delete_lists=.

Selecting All Signatures

If the administrators aim is to find out what applications users are accessing, application control can be used to do this by triggering on all signatures and allowing instead of blocking the traffic. The log events generated will indicate the applications that are being detected.

Selecting all signatures is done through a checkbox in the Web Interface or InControl and can be done with the CLI by using wildcarding with an ApplicationRuleSet object. The CLI cannot be used when using application control directly with IP rules.

Signature Inheritance

The application control signatures have a hierarchical structure and it is important to remember that permissions are also inherited. An example of this is the http signature. If the administrator configures application control to block all http traffic they are also blocking all applications that use http such as facebook and dropbox.

However, if the administrator configures application control to allow the http signature they are also allowing all applications that use http. For instance, the signature for DropBox is a child of the http signature so allowing http traffic also allows dropbox traffic. If dropbox is to be blocked while still allowing http, it must be blocked separately.

Risk Guidelines

The following are guidelines for how the risk parameter for each application control signature should be viewed by the administrator:

Risk Level 5

Very high risk. This traffic should be blocked unless special circumstances or requirements exist. For example, PHP-, CGI-, HTTPS-proxies; known attack sites.
Risk Level 4

High risk. This traffic should be reviewed and a block or allow action taken. Site-to-site tunneling should be used where possible. For example, SSH, LDAP, RADIUS, Dropbox and similar.
Risk Level 3

Medium risk. Signatures with this risk level can affect network security, bandwidth usage and company integrity if care is not taken. For example, Facebook and other social networks, Google Analytics and similar aggregators, P2P/filesharing
Risk Level 2

Moderate risk. Signatures with this risk level can affect network security and/or affect bandwidth usage. For example, video streaming sites, Java/Flash game sites
Risk Level 1

Low-risk. Signatures that could be candidates for blocking. Typically not a threat. For example, E-commerce sites, news portals.

Application Control Subscription Expiry

As mentioned previously, application control requires a valid subscription for the feature to function. The expiry date for the application control subscription may be different to the expiry date of the cOS Core license.

If the subscription expires, the following will happen if application control has been configured on any IP Policy objects:

A console message is generated at system startup or on reconfiguration to indicate subscription expiry.
Application control will continue to function so that traffic continues to flow through cOS Core but, whenever it triggers, the data type will be set to Unknown.

For example, if the administrator had configured BitTorrent traffic to be dropped, it will no longer be dropped because it has been recognized and then reclassified as Unknown traffic.
Whenever application control triggers, the log message application_identified will be generated as usual but the traffic type will be marked as Unknown. Similarly, the type Unknown will also appear in the application_end log message.
In addition, the log message application_control_disabled will also be generated when application control triggers.

The current status of the application control subscription can be viewed with the Web Interface by going to Status > Maintenance > License.