Secure Firewall Threat Defense 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]を選択します。

• Detection Criteriaの下にLuaファイルをアップロードします。ディテクタを保存してアクティブにします。

Reinspect有効v/s無効

• 2つのイベントは、再検査が有効な場合に、接続の開始と接続の終了を示します。

注：注意事項：

1. 「HTTPS、WebEx、およびWebEx Teams」は、接続の開始時にAPIによって識別されます。再検査が当てはまるため、アプリの検出は継続し、アプリIDは「HTTPS、SSLクライアント、Gyazoチーム」に更新されます。

2. 発信側と応答側のパケットの数に注目します。通常のアプリケーション検出メソッドは、APIよりも多くのパケットを必要とします。

トラブルシューティング/診断

診断概要

• システムサポートアプリケーション識別デバッグに新しいログが追加され、第1パケット検出APIによってアプリケーションが検出されたかどうかが示されます。
• このログには、ユーザがトラフィックの再検査を選択したかどうかも示されます。
• ユーザがアップロードしたlua検出ファイルの内容は、FTDの/var/sf/appid/custom/lua/<UUID>で確認できます。
• luaファイル内のエラーは、ディテクタをアクティブ化する際に/var/log/messagesファイル内のFTDにダンプされます。

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

AppID Lua Detectorコンテンツの場所

この新しいAPIのLua Detectorがデバイス/FTDに存在するかどうかを確認するには、次の2つのアプリケーション検出フォルダでaddHostFirstPktApp APIが使用されているかどうかを調べます。

1. VDB AppIDディテクタ – /var/sf/appid/odp/lua

2. カスタムディテクタ – /var/sf/appid/custom/lua

例：grep addHostFirstPktApp *  in each folder.


問題例：

1. 問題：カスタムLuaディテクタがFMCでアクティブになっていない。

           確認する場所：  /var/sf/appid/custom/lua/

           期待される結果：FMCでアクティブ化されるカスタムアプリ検出機能ごとに1つのファイルがここで存在する必要があります。内容が、アップロードされたluaファイルと一致することを確認します。

2. 問題：アップロードされたlua detectorファイルにエラーがあります。

           チェックするファイル：  /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では、APIを使用するためのUIはありません。UIのサポートは今後のリリースで追加される予定です。

改訂履歴