Similar to attack detection, application identification is a function of the Sensor. The Sensor can identify applications in SPAN, tap, and inline modes. However, only inline mode is relevant for QoS. By default the application identification feature is enabled for NS-series Sensors. If you use any of the following features, the application identification function is automatically turned on for that Sensor:
A Firewall access rule or any type of QoS rule based on an Application, Application on Custom Port, or an Application Group.
Application identification enabled for the Top Applications (IPS)/(NTBA) monitor.
Important
Identifying applications is a resource-intensive process. If the Sensor performs application identification on the entire traffic, the Sensor throughput could be reduced by about 10%. The amount of actual throughput drop varies based on the type of traffic.
From a Firewall and QoS perspective, you need to understand how rules based on applications can induce a dependency factor between the rules. The dependency factor with respect to Firewall is explained here, but it has a similar effect on QoS policies as well.
Following are the response actions that you can specify in case of Firewall:
Deny — The Sensor blocks the traffic and does a TCP reset. This applies only to inline mode.
Drop — The Sensor drops the traffic. This applies only to inline mode.
Ignore — The Sensor permits the traffic with no further inspection. This applies to SPAN, tap, and inline modes.
Require Authentication — The Sensor permits only those users with valid AD credentials for HTTP traffic only. This applies only to inline mode.
Scan — The Sensor permits the traffic that matches a Firewall access rule, but inspects it for attacks. This applies to SPAN, tap, and inline modes.
Scan with Priority — The Sensor prioritizes critical network traffic. This is available only for advanced firewall policies.
Stateless Drop — The Sensor drops the packets.
Stateless Ignore — This is the same as ignore option. That is, the Sensor permits the packet without inspection for intrusions.
The dependency factor explained below, applies only for those rules for which you set scan or ignore as the Sensor's response action.
Dependency factor — If you create a rule to allow an application, all the dependent applications and services are allowed by default. For example, if you allow Facebook, HTTP is allowed by default. This also allows all unknown HTTP applications, or HTTP applications for which there are no signatures. For example, to allow Facebook but block all other HTTP traffic you need to create access rules for the following conditions and in the same order:
Scan Facebook
Deny HTTP
Consider that a user attempts to access Gmail, which is a known application. So, the Sensor identifies the Gmail traffic and blocks it according to the second rule. Now, consider that a user attempts to access an unknown HTTP application. The Sensor cannot identify this application beyond the HTTP level because there is no signature. Because the first rule implicitly allows HTTP, the Sensor allows this traffic to pass through. In short, all unknown HTTP applications are allowed, and all known HTTP applications except Facebook are blocked.
Suppose if you create Access Rules for the following conditions and in the same order then all HTTP applications, including Facebook, are blocked:
Deny HTTP
Scan Facebook
Similarly, rules involving application capabilities also can induce the dependency factor. That is, allowing an application capability allows the application itself and other capabilities of the application for which there are no signatures.
When you calculate the dependency factor between access rules, factor in all the components of the rules such as source, destination, effective time, application categories, and so on. Consider the sample set of rules below:
Source: x ¦ Destination: y ¦ Application: TwileShare ¦ Response action: Scan (that is, permit with IPS)
Source: x ¦ Destination: y ¦ Application: Twitter ¦ Response action: Drop
Source: a ¦ Destination: b ¦ Application: Twitter ¦ Response action: Drop
When the Sensor detects Twitter traffic from x to y, it allows this traffic with IPS, though it must drop this traffic according to the second rule. This is because, TwileShare is dependent on Twitter. So, by allowing TwileShare in the first rule from x to y, you are allowing Twitter from x to y as well. However, if the Sensor detects Twitter traffic from a to b, it drops the traffic according to the third rule, because the first rule that implicitly allows Twitter applies only from x to y and not from a to b.
Consider the rules below:
Source: x ¦ Destination: y ¦ Application: Twitter ¦ Response action: Drop
Source: x ¦ Destination: y ¦ Application: TwileShare ¦ Response action: Scan (that is, permit with IPS)
In this case, Twitter traffic from x to y is dropped according to rule 1; TwileShare traffic from x to y is allowed with inspection according to rule 2.