在安全防火牆威脅防禦7.4中配置AppID早期資料包檢測

> 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

防火牆管理中心逐步解說

使用API建立自定義檢測器的步驟

從FMC建立新的自訂偵測器：

• Policies > Application Detectors > Create Custom Detector .

• 定義名稱和說明。
  • 從下拉式功能表中選擇應用程式。
  • 選擇Advanced Detector Type。

• 上傳「檢測標準」下的Lua檔案。儲存並啟用檢測器。

Respect已啟用v/s已停用

• 這兩個事件顯示連線的開始v/s和啟用重新檢查時的連線的結束。

附註：需注意的事項：

1. 在連線開始時，API會標識「HTTPS、Webex和Webex團隊」。由於重新檢查為真，應用發現繼續進行，並且appId更新為「HTTPS、SSL客戶端和Gyazo團隊」。

2. 注意發起方和響應方資料包的數量。常規應用檢測方法需要的資料包比API多得多。

疑難排解/診斷

診斷概要

• 系統支援應用程式標識調試中增加新日誌，以指示第1個資料包檢測API是否找到任何應用程式。
• 這些日誌還顯示使用者是否選擇重新檢查流量。
• 在FTD的/var/sf/appid/custom/lua/<UUID>下可以找到使用者上傳的lua檢測器檔案的內容。
• 在啟用檢測器時，lua檔案中的任何錯誤都會轉儲到/var/log/messages檔案中的FTD上。

CLI：系統支援應用程式標識-調試

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

AppID Lua檢測器內容的位置

要確認具有此新API的Lua檢測器是否存在於裝置/FTD上，您可以檢視addHostFirstPktApp API是否正用於2個應用檢測器資料夾：

1. VDB AppID檢測器-/var/sf/appid/odp/lua

2. 自定義檢測器-/var/sf/appid/custom/lua

例如：grep addHostFirstPktApp * 在每個資料夾中。


問題示例：

1. 問題：未在FMC上啟用自定義Lua檢測器。

           要檢查的位置：  /var/sf/appid/custom/lua/

           預期結果：在FMC上啟用的每個自訂應用程式偵測器都必須有一個檔案存在。驗證內容是否與上載的lua檔案匹配。

2. 問題：上載的lua檢測器檔案有錯誤。

           要檢查的檔案：  /var/log/messages on FTD

           錯誤記錄：

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)

疑難排解步驟

問題：對於流向使用者定義IP地址和埠的流量，應用程式辨識不正確。

故障排除的步驟：

• 驗證是否已在FTD上正確定義並啟動lua檢測器。
  • 確認FTD上lua檔案的內容，並檢查啟動時是否看不到錯誤。
• 檢查流量會話中第一個資料包的目的IP、埠和協定。
  • 它可以與lua檢測器中定義的值匹配。
• 檢查system-support-application-identification-debug。
  • 查詢行Host cache match found on first packet. 如果缺少該行，則表示API未找到任何匹配。

限制詳細資訊、常見問題和解決方法

在7.4中，沒有UI可以使用API。未來版本中將增加UI支援。

修訂記錄