Next Generation Firewall (NGFW) How To: Application Detection

Version 1

     

    Introduction

     

    Applications are elements that can be used to dynamically detect traffic patterns related to the use of a particular application instead of just detecting the service and protocol used with a regular Service element. Matching is done by inspecting the payload of the traffic, so matching is not port-dependent and applications can be detected even on non-standard ports. Application detection first identifies the protocol, and then compares the traffic to a protocol-specific pattern matching context to identify the applications. There are several predefined Application elements available, covering the most commonly used applications. Applications are imported and updated through Dynamic Updates.

     

    Illustration 1: Elements Used in Application Elements.

    AppDetection 1.JPG

     

    Several elements make up an Application element:

    AppDetection 2.JPG

     

    Packet Inspection with Application Detection

     

    Illustration 2: Application Identification Process

    AppDetection 3.JPG

     

    When a new connection arrives at the engine, the Access rules are checked first. If the connection matches an Access rule that has an Application defined in the Service field, application detection is triggered. Since the engine does not yet know which Application will be detected, the Access rule match is just a possible match and the engine also checks all preceding Access rules for possible matches. After this, the engine inspects the data payload of the connection and compares it to the Application traffic patterns. For most Applications to be detected, the server response must also pass through the engine. This means that part of the traffic must be allowed through the engine. Most applications can be detected from the server’s first reply, but at the maximum 4096 bytes can be allowed through for each connection to allow the Application to be detected. If the Application defined in one of the matching Access rules is detected from the data payload of the connection, the engine acts according to the Action defined in the matching rule. If no Application is detected, the engine checks all other possible matches done before Application detection, matches the correct rule, and acts accordingly.

     

    Applications with HTTPS traffic

     

    Illustration 3: Application Identification Process with Deep Inspection.

    AppDetection 4.JPG

     

    TLS Match elements define matching criteria for the use of the TLS protocol in traffic. TLS Matches used in Application elements allow you to detect application use in HTTPS traffic. When a connection that uses the TLS protocol is detected, the server certificate for the connection is compared to the TLS Match in the Application element. TLS connections are allowed only to sites that have trusted certificates that meet the following criteria:

          • The certificate domain name must match the domain name in the TLS Match element
          • The certificate must be signed by a valid certificate authority
          • The certificate must be valid (not expired or revoked)

     

    TLS Matches also specify whether certain domains are excluded from TLS decryption and inspection. These types of TLS Matches are applied globally, regardless of whether the TLS Match is used in any Application element or in the Access rules. All TLS Matches are transferred to the engine during policy installation. TLS connections that match a TLS Match that has the “Deny decrypting” option set are never decrypted.

     

    If an application is not detectable by the TLS Match only, TLS inspection for server and/or client protection can be configured on the engine. Once the TLS Inspection configuration is applied to the engine, HTTPS connections are decrypted for application detection automatically when needed. TLS decryption for Application detection does not require activation in the Access rules in the same way that TLS decryption for HTTPS connections does.

     

    Applications with Deep Inspection

     

    Application detection can be used together with Deep Inspection. When both Deep Inspection and application detection are enabled for the same connection, both operations are done simultaneously: application detection is done as defined in the Access rules and Deep Inspection is done as defined in the Inspection Policy. If the Deep Inspection detects harmful traffic patterns in the connection before any application is detected, the connection is terminated by the inspection process. Since application detection must allow a certain amount of data payload through before the application is detected, Deep Inspection ensures that this part of the traffic does not contain any harmful traffic patterns.

     

    Deep inspection is also activated when there is a matching Access rule that activates Deep Inspection later in the policy. When a connection matches an Access rule that contains Application element, the engine does not yet know whether the connection matches the defined Application. For this reason, the engine must also check the connection against later Access rules. If one of those rules has Deep Inspection enabled, the connection is also forwarded for Deep Inspection. If the inspection finds harmful traffic patterns from the data payload before the Application can be detected, the connection is terminated by the inspection process.

     

    Applications with Protocol Agents

     

    Application detection and Protocol Agents also work simultaneously. Service definitions can be used in the policy editing view to combine different Service elements.

     

    Note: When combining Application elements and Service elements, the Service element is a simple protocol and port match, even if a Service with Protocol Agent settings is used. For this reason, Application and Service elements with a Protocol Agent cannot be used together in a single Access rule. Instead, one of the elements must be used in a Continue rule.

     

    Some Application elements (such as FTP) include Protocol Agent functionalities. To use these functionalities (such as related connection handling) Application elements must be used in explicit Access rules. Simply logging Application information does not enable the functionalities. If you need to modify the default Protocol Parameters, you can create a duplicate Application element and then modify the settings accordingly.

     

    Applications and Logging

     

    Information about Application use can be added to the log entries created by the matching Access rules. This must be enabled manually in the Logging options for the Access rule.

     

    To enable Application logging, select Override Recording Settings Inherited from "Continue" Rule(s) and select one of the following options for Log Application Information:

    AppDetection 5.JPG

     

    To fully utilize the application logging feature, the “Enforced” option is recommended.

     

    Depending on how you want the Applications to be logged, you may need to modify the “Connection Closing” setting:

    AppDetection 6.JPG

     

    Configuration

     

    There are several pre-defined Application elements available. The pre-defined Application elements are not editable. If there is a need to modify an existing Application element, you can duplicate the pre-defined Application element and modify the duplicated element. It is also possible create custom Application elements, for example, for company-specific Applications.

     

    Application elements do not require any additional configuration to be able to use them in the Access rules. To activate Application detection, you must create an Access rule that contains an Application element in the Service cell. Application elements can be used directly in the Service cell or as a part of the Service definition. Any other criteria added to the service definition, such as Service or TLS Match, override the Application properties.

     

    Alternatively, Application Types and Tags can be used directly in the Service cell to match any of the Applications that belong to the defined Application Type or Tag group.

     

    Application Use Cases

     

    Examples listed in this article illustrate common uses for Applications and the general steps on how each scenario is configured.

     

    Application Logging

     

    Use case: The administrator wants to enable Application logging to detect which types of applications are used in the network.

     

    In this example applications are logged and the “Log Accounting Information” option is enabled to be able to see more details about the Application use in Overviews and Reports.

          1. Open the engine’s policy for editing.
          2. Create an Access rule with the Continue action at the beginning of the policy.
          3. Edit the Logging Options for the rule and select the following options:
            • Log Level: Stored
            • Log Application Information: Enforced
            • Connection Closing: Log Accounting Information

    The Access rule should look like the illustration below.

    AppDetection 7.JPG

       4. Save and install the policy on the engine.

     

    Blocking Application Use

     

    Use case: The administrator wants to block the use of a certain Application in the local network.

    1. Open the engine’s policy for editing.

    2. Add a rule with the Discard action and set the Source and Destination to ANY.

    3. Add the Application element that represents the Application to be blocked to the Service cell.

     

    Note: Application detection is done for traffic that matches the ports defined in the Application element.

     

    The Access rule should look like the illustration below.

    AppDetection 8.JPG

    4. Save and install the policy on the engine.

     

     

    Allowing Application Use Only on a Certain Port

     

    Use case: The administrator wants to allow a certain Application only when it is used with HTTPS.

     

    Application elements usually have by default both HTTP and HTTPS ports defined for matching criteria. These settings can be overridden by combining the application element with a Service element in the Service definition. In the example below, the Salesforce Application is allowed only when using TLS.

     

    1.  Open the engine’s policy for editing.

    2.  Add an Access rule with the Allow action and set the Source and Destination to ANY.

    3.  Edit the Service definition. Add the Application element to the Application cell and add the HTTPS Service to the Service (Port) cell.

    4.  Add an Access rule with the Discard action after the previous rule and add the Application element directly to the Service cell.

     

    The Access rules should look like the illustration below.

    AppDetection 9.JPG

    5.  Save and install the policy on the engine.

     

    Allowing Only Certain Applications

     

    Use case: The administrator wants to allow the use of only a certain Application, regardless of the port used. All other traffic is discarded.

     

    In this example only the TeamViewer Application is allowed. The detection is done for all traffic that passes through the firewall.

    1. Open the engine’s policy for editing.

    2. Add an Access rule with the Allow action and set the Source and Destination to ANY.

    3. Edit the Service definition. Add the TeamViewer Application to the Application cell and the Any TCP Service element to the Service (Port) cell.

    4. Add an Access rule with the Discard action after the previous rule and set the Source, Destination, and Service to ANY.

     

    The Access rules should look like the illustration below.

    AppDetection 10.JPG

    5. Save and install the policy on the engine.

     

    Enforcing Only HTTP Protocol with URL Logging

     

    Use case: The administrator wants to allow HTTP traffic only on the default port 80 and log the URLs that are accessed. All other traffic is discarded. Traffic using the same protocol on all other ports is discarded.

     

    1. Open the engine’s policy for editing.

    2. Add an Access rule with the Allow action and set the Source and Destination to ANY.

    3. Edit the Service definition. Add the HTTP Application to the Application cell and the HTTP Service to the Service (Port) cell.

    4. Edit the logging options. Select Stored as the Log Level and select Additional Payload.

    5. Add an Access rule with the Discard action after the previous rule and set the Source and Destination to ANY.

    6. Edit the Service definition. Add the HTTP Application to the Application cell and set the Service cell to ANY.

     

    The Access rules should look like the illustration below.

    AppDetection 11.JPG

    7. Save and install the policy on the engine.


    Detecting HTTP Protocol Use and Forwarding the Traffic for Deep Inspection


    Use case: The administrator wants to detect HTTP traffic even in non-standard ports and forward the traffic for deep inspection.

     

    Application elements can also be used to detect HTTP protocol use on any port and forward it further for deep inspection.

    1. Open the engine’s policy for editing.

    2. Add an Access rule with the Allow action and set the Source and Destination to ANY.

    3. Edit the Action Options and enable Deep Inspection.

    4. Edit the Service definition. Add the HTTP Application to the Application cell and the Any TCP Service element to the Service (Port) cell.

    5. Add an Access rule with the Discard action after the previous rule and set the Source and Destination to ANY.

    6. Edit the Service definition. Add the HTTP Application to the Application cell and set the Service cell to ANY.

     

    The Access rules should look like the illustration below.

    AppDetection 12.JPG

    7. Save and install the policy on the engine.

     

    Using QoS to Limit Application Bandwidth Use

     

    Use Case: The administrator wants to make sure that the use of a certain Application does not consume too much of the available bandwidth.

     

    The P2P Traffic QoS Class element has already been defined.

     

    1. Open the engine’s policy for editing.

    2. Add an Access rule with the Allow action and set the Source and Destination to ANY.

    3. Add the BitTorrent Application to the Service cell and add the P2P Traffic QoS Class to the QoS Class cell.

     

    The Access rule should look like the illustration below.

    AppDetection 13.JPG

    4. Open the QoS Policy for editing and add a rule.

     

    Note: Rule order does not matter in the QoS Policy.

     

    5. Add the P2P Traffic QoS Class to the QoS Class cell, and set a limit of 50% of the available bandwidth and a Priority of 6.

     

    The QoS Policy should look like the illustration below.

    AppDetection 14.jpg

    6. Select the QoS Policy for the Physical Interface that will apply QoS to the traffic.

     

    Note: QoS is only applied to outgoing traffic. Consider the direction of the traffic when selecting the interface.

     

    7. Set the Throughput to the link speed of the interface.

     

    Note: QoS guarantees and limits are automatically calculated based on the Throughput value defined in the interface properties. Usually the Throughput should be set to match the actual link speed.

     

    8. Save and install the Firewall policy on the engine.

     

    Creating Custom Applications

     

    You can also create custom Application elements to detect the use of other applications. The Application elements use SMC regular expressions for the traffic payload matching. Regular Expression syntax can be found in the McAfee SMC Administrator’s Guide.


    Note: When creating custom Application elements, you must be familiar with exactly how the application to be detected works. Incorrect configurations may prevent traffic flow on the engine.