Configure AppID Early Packet Detection in Secure Firewall Threat Defense 7.4

Introduction

This document describes how to configure AppID Early Packet Detection in Cisco Secure Firewall 7.4.

Background – Problem (Customer Requirements)

• Application detection through Deep Packet Inspection can take more than one packet to identify traffic.
• Sometimes, where IP and/or port for an application server is known, you can avoid inspecting additional packets.

What’s New

• A new Snort-based Lua AppID API has been created which allows us to map an IP address, port, and protocol to the respective:
  • Application protocol (service appid),
  • Client application (client appid) and
  • Web application (payload appid).
• Custom Application Detectors can be created on FMC using this API for application detection. 
• Once this detector is activated, this new API would allow us to identify applications on the very first packet in a session.

Feature Overview

• The API is identified as: 
  • addHostFirstPktApp  (protocol_appId, client_appId, payload_appId, IP address, port, protocol, reinspect)
• A cache entry is created for every mapping created in the custom app detector.
• The first packet of all incoming sessions is inspected to see if a match is found in the cache.
• Once a match is found, we assign the corresponding appids for the session and the app discovery process stops.
• Users have the option to reinspect traffic even after a match was found by the API.
• The reinspect argument is a boolean value which indicates if there is a need to reinspect the applications found on the first packet or not.
• When reinspection is true, app discovery continues even if the API finds a match.
• In this case, the appids assigned on the first packet can change. 

Prerequisites, Supported Platforms, Licensing

Minimum Software and Hardware Platforms

Warning: Snort 2 does not support this API.

Snort 3, Multi-Instance, and HA/Clustering Support

Note: Requires that Snort 3 be the detection engine.

Components Used

The information in this document is based on these software and hardware versions:
• Cisco Firepower Threat Defense running 7.4 or higher.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.

Feature Details

Functional Feature Description

Contrasting Previous to This Release

How it Works

1. Create a lua file: Ensure the file is in the lua template (no syntax errors). Also verify the arguments given to the API in the file are correct.

2. Create a new custom detector: Create a new custom detector on FMC and upload your lua file in it. Activate the detector.

3. Run traffic: Send traffic that matches the IP/port/protocol combination defined in the custom app detector to the device.

4. Check connection events: On FMC, check the connection events filtered by the IP and port. User-defined applications would be identified.

AppID Early Packet Detection API Workflow

API Fields Description from Custom Detector Example

gDetector:addHostFirstPktApp

     (gAppIdProto, gAppIdClient, gAppId, 0, "192.0.2.1", 443, DC.ipproto.tcp );

• The highlighted arguments are the user-defined values for the reinspect flag, IP address, port and protocol.
• 0 indicates a wildcard.

Use Case: How to Block Traffic Faster

• Policy View: Block Rule for the application “AOL”.

• Testing Traffic using curl with: curl https://www.example.com v/s curl https://192.0.2.1/ (one of TEST’s IP addresses)

> curl https://www.example.com/
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to www.example.com:443 

> curl https://192.0.2.1/
curl: (7) Failed to connect to 192.0.2.1 port 443: Connection refused

Firewall Management Center Walkthrough

Steps to Create a Custom Detector Using the API

Create a new custom detector on the FMC from:

• Policies > Application Detectors > Create Custom Detector .

• Define name and description.
  • Choose the application from the dropdown menu.
  • Select Advanced Detector Type.

• Upload the Lua file under Detection Criteria. Save and activate the detector.

Reinspect Enabled v/s Disabled

• The two events show the beginning of the connection v/s the end of the connection when reinspection is enabled.

Note: Things to note:

1. ‘HTTPS, Webex and Webex Teams’ are identified by the API at the beginning of the connection. Since reinspection is true, app discovery continues and appIds are updated to ‘HTTPS, SSL Client and Gyazo Teams’.

2. Notice the number of initiator and responder packets. Regular app detection methods require a lot more packets than the API.

Troubleshooting/Diagnostics

Overview of Diagnostics

• New logs are added in system support application identification debug to indicate if any applications are found by the 1st packet detection API.
• The logs also show if the user chose reinspection of traffic.
• Contents of the lua detector file uploaded by the user can be found on the FTD under  /var/sf/appid/custom/lua/<UUID> .
• Any errors in the lua file are dumped on the FTD in the /var/log/messages file at the time of activating the detector.

CLI: system support application-identification-debug

192.0.2.1 443 -> 192.168.1.16 51251 6 AS=4 ID=0 New AppId session
192.0.2.1 443 -> 192.168.1.16 51251 6 AS=4 ID=0 Host cache match found on first packet, service: HTTPS(1122), client: AOL(1419), payload: AOL(1419), reinspect: False
192.168.1.16 51251 -> 192.0.2.1 443 6 AS=4 ID=0 app event with client changed, service changed, payload changed, referred no change, misc no change, url no change, tls host no change, bits 0x1D
192.168.1.16 51251 -> 192.0.2.1 443 6 AS=4 ID=0 New firewall session
192.168.1.16 51251 -> 192.0.2.1 443 6 AS=4 ID=0 Starting with minimum 2, 'New-Rule-#1-MONITOR', and SrcZone first with zones 1 -> 1, geo 0(xff 0) -> 0, vlan 0, src sgt: 0, src sgt type: unknown, dst sgt: 0, dst sgt type: unknown, svc 1122, payload 1419, client 1419, misc 0, user 9999997, no url or host, no xff
192.168.1.16 51251 -> 192.0.2.1 443 6 AS=4 ID=0 match rule order 2, 'New-Rule-#1-MONITOR', action Audit
192.168.1.16 51251 -> 192.0.2.1 443 6 AS=4 ID=0 match rule order 3, 'New-Rule-#2-BLOCK_RESET', action Reset
192.168.1.16 51251 -> 192.0.2.1 443 6 AS=4 ID=0 MidRecovery data sent for rule id: 268437504, rule_action:5, rev id:3558448739, rule_match flag:0x1
192.168.1.16 51251 -> 192.0.2.1 443 6 AS=4 ID=0 Generating an SOF event with rule_id = 268437504 ruleAction = 5 ruleReason = 0
192.168.1.16 51251 -> 192.0.2.1 443 6 AS=4 ID=0 reset action

Location of AppID Lua Detectors Content

To confirm if the Lua Detector with this new API exists on the Device/FTD you can look to see if the addHostFirstPktApp API is being used in the 2 application detector folders:

1. VDB AppID detectors -/var/sf/appid/odp/lua

2. Custom Detectors -/var/sf/appid/custom/lua

For example:grep addHostFirstPktApp *  in each folder.

Sample Issues:

1. Issue: Custom Lua detector not activated on FMC.

           Location to check:  /var/sf/appid/custom/lua/

           Expected result: One file for every custom app detector activated on the FMC must exist here. Verify contents match the uploaded lua file.

2. Issue: The uploaded lua detector file has errors.

           File to check:  /var/log/messages on FTD

           Error log:

Dec 18 14:17:49 intel-x86-64 SF-IMS[15741]: Error - appid: can not set env of Lua detector /ngfw/var/sf/appid/custom/lua/6698fbd6-7ede-11ed-972c-d12bade65dc9 : ...sf/appid/custom/lua/6698fbd6-7ede-11ed-972c-d12bade65dc9:37: attempt to index global 'gDetector' (a nil value)

Troubleshooting Steps

Problem: Applications not correctly identified for traffic going to the user-defined IP address and port.

Steps to troubleshoot:

• Verify the lua detector is correctly defined and activated on the FTD.
  • Verify the contents of the lua file on the FTD and check no errors are seen on activating.
• Check the destination IP, port and protocol of 1st packet in the traffic session.
  • It can match the values defined in the lua detector.
• Check the system-support-application-identification-debug.
  • Look for the line  Host cache match found on first packet. If that is missing, it indicates no match was found by the API.

Limitations Details, Common Problems, and Workarounds

In 7.4, there is no UI to use the API. UI support would be added in  future releases.

Revision History