3.7. Application Control

Home Prev	cOS Core 14.00.15 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 in two ways:

Specifying applications directly with an IP Policy object.

This is the basic way of either allowing or denying the data flows associated with a given application. This is often used when testing application control since it is simple but does not provide much flexibility.
Associating an Application Rule Set with an IP Policy object.

This is the recommended method of using application control and provides more flexible ways to handle the data flows associated with applications. 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.

These two methods of configuring application control are examined next.

Associating Directly with an IP Policy

Using application control directly is configured with the following steps:

Create an IP Policy with a set of filter parameters to target specific connections.
Use an Action of Allow and optionally specify NAT source address translation.
Enable application control in the policy, select the option to use manual configuration and add the applications that are to be allowed or denied.

If the Deny option is selected but no applications are selected then everything is allowed. If the Allow option is selected but no applications are selected then nothing will be allowed.

Example 3.46. Specifying an Application Control Policy

This example creates an IP Policy to deny 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 that the default source translation of Auto will be used in the IP policy created. This means that connections will automatically be subject to NAT translation when they are from a private IP address to a public address.

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, the created list is used in an IP policy:

Device:/> add IPPolicy Name=allow_comp
			SourceInterface=lan
			SourceNetwork=lan_net
			DestinationInterface=wan
			DestinationNetwork=all-nets
			Service=all_services
			Action=Allow
			AppControl=Yes
			AC_AppAction=Deny
			AC_Applications=1

An alternative to creating a list is to set the applications directly:

		AC_Applications=yahoo_groups,google_groups

InControl

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

Web Interface

Go to: Policies > Firewalling > Main IP Rules > Add > IP Policy
Now enter:
- Name: allow_comp
- Action: Allow
Under Filter enter:
- Source Interface: lan
- Source Network: lan_net
- Destination Interface: all
- Destination Network: all-nets
- Service: all_services
Under the Application Control tab enter:
- Application Control: Enable
- Application Control Mode: Use Manual Configuration
- Application Action: Deny
- Press Add to display the selection dialog.
- Select yahoo_groups and google_groups.
Click OK

Note that logging is enabled by default.

Using an Application Rule Set

As described previously, another, recommended way of controlling applications is to create an Application Rule Set object and associate this with an IP Rule or IP Policy object.

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 controls:

Authentication Settings

For an Allow application rule, the requesting client is only permitted the connection if they have already been authenticated by cOS Core and are also one of any usernames specified in that application rule or belong to one of the groups specified in the rule. In addition, the specified group or username should also be specified for the source network address object used with the associated IP rule or policy and this is explained further later in this section.

For a Deny rule, the requesting client is denied the connection if they are authenticated and are one of the usernames specified or belong to one of the specified groups.

Authentication may have performed using any of the methods available in cOS Core Authentication Rule objects, including Identity Awareness.

If no groups or usernames are specified in an Application Rule object, authentication is ignored.

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 for the Authentication Settings property of the relevant Application Rule object.
The Source Network property of the associated IP Rule or IP Policy must be set to an address book IP object for which either of the following is true:
1. The address object has the property No defined credentials enabled.
2. The address object has the same groups and/or usernames as the Application Rule defined for its User Auth Groups property.

Example 3.47. Using an Application Control Rule Set

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. 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.
The Source Network property for the lan_to_wan_policy IP policy is already set to an IPv4 address book object called lan_users_net.

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 bt_app_list:

Device:/> add Policy ApplicationRuleSet bt_app_list
			DefaultAction=Allow

Then, change the CLI context to be bt_app_list:

Device:/> cc Policy ApplicationRuleSet bt_app_list

Device:/bt_app_list>

Now, add the ApplicationRule object:

Device:/bt_app_list> add ApplicationRule
			Action=Allow
			AppFilter=3
			UserAuthGroups=rogue_users
			ForwardChain=narrow_025_pipe
			ReturnChain=narrow_025_pipe

Then, return to the default context:

Device:/bt_app_list> cc
Device:/>

Associate this ApplicationRuleSet with the IPPolicy:

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

Finally, set the source network address object of lan_to_wan_policy so it has the same group name as the application rule:

Device:/> set Address IP4Address lan_users_net UserAuthGroups=rogue_users

Note that the following would also allow application control to function:

Device:/> set Address IP4Address lan_users_net NoDefinedCredentials=Yes

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 bt_app_list
Set the Default Action to Allow
Click OK

Next, define an Application Rule as a child.

Go to: Policies > Firewalling > Application Rule Sets > bt_app_list > Add > Application Rule
Select Allow for the Action
Enable Application Control and add the signatures bittorrent and utp (both are required for BitTorrent).
Select Authentication Settings and enter the group name rogue_users
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

Associate the Application Rule Set with the IP Policy:

Go to: Policies > Firewalling > Main IP Rules > lan_to_wan_policy
Under the Application Control tab enter:
- Enable Application Control: Enable
- Application Control Mode: Use Rule Set
- Application Rule: bt_app_list
Click OK

Finally, set the source network address object of lan_to_wan_policy so it has the same authentication group name as the application rule.

Go to: Objects > Address Book > Add > IP4 Address
Select lan_to_wan_policy
In User Auth Groups enter rogue_users
Click OK

Note that enabling No defined credentials in 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.48. 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.49. 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.