アプリケーション ssl としてマークされた ssl セッションの復号化
Resolution
問題
SSL 復号化は暗号化されるトラフィックの可視性を与えることになっていることがわかっています。したがって、復号化されたトラフィックは、web ブラウジング、facebook ベースなど、SSL としてではなく、基になるアプリケーションとして識別することを期待します。ただし、一部のシナリオでは、アプリケーションの SSL を復号化として表示する動作が予想されます。この記事では、このようなシナリオについて説明し、アプリケーション ssl として識別される復号化 ssl セッションが、この場合は [OK] と見なされる理由を示します。
以下の例では、次の web サイトにアクセスしようとしていました。
https://my.vmware.com/web/vmware/login
セッションテーブルから、セッションが復号化 (*) としてマークされていることがわかります
管理者 @ 信仰-PFW-X1 の > セッションを表示するすべてのフィルタ ssl-復号化はい
--------------------------------------------------------------------------------
ID アプリケーションの状態の種類フラグ Src [スポーツ]/Zone/Proto (変換された ip [ポート])
Vsys Dst [Dport]/Zone (変換された ip [ポート])
--------------------------------------------------------------------------------
25472 ssl アクティブフロー *NS 192.168.16.48 [60668]/Zone-Trust2016/6 (10.193.90.32 [61785]) vsys1
216.58.212.163 [443]/Zone-UnTrust (216.58.212.163 [443])
25475 ssl アクティブフロー *ns 192.168.16.48 [60670]/Zone-Trust2016/6 (10.193.90.32 [37349]) vsys1 216.58.212.163
[443]/Zone-UnTrust (216.58.212.163 [443])
25478 ssl アクティブフロー *ns 192.168.16.48 [60674]/Zone-Trust2016/6 (10.193.90.32 [43548])
vsys1 216.58.212.163 [443]/Zone-UnTrust (216.58.212.163 [443])
25474 ssl アクティブフロー * NS 192.168.16.48 [60671]/Zone-Trust2016/6 (10.193.90.32 [31994]) vsys1 216.58.212.163
[443]/Zone-UnTrust (216.58.212.163 [443])
25479 google ベースのアクティブフロー * ns 192.168.16.48 [60675]/Zone-Trust2016/6 (10.193.90.32 [15527]) vsys1
216.58.212.163 [443]/Zone-UnTrust (216.58.212.163 [443])
25538 web ブラウジングアクティブフロー * ns 192.168.16.48 [60710]/Zone-Trust2016/6 (10.193.90.32 [17185])
vsys1 68.232.35.180 [443]/Zone-UnTrust (68.232.35.180 [443])
25473 ssl アクティブフロー *NS 192.168.16.48 [60669]/Zone-Trust2016/6 (10.193.90.32 [35255]) vsys1 216.58.212.163
[443]/Zone-UnTrust (216.58.212.163 [443])
セッションの詳細については、SSL として識別されるアプリケーションタイプがあることを示しています。
管理者 @ 信仰-PFW-X1 の > を表示するセッション id 25473
セッション25473
c2s フロー:
ソース: 192.168.16.48 [ゾーン Trust2016]
dst: 216.58.212.163
プロト: 6
スポーツ: 60669 dport: 443
状態: INIT の種類: フロー
src ユーザー: 不明な
dst ユーザー: 不明
s2c フロー:
ソース: 216.58.212.163 [ゾーン UnTrust]
dst: 10.193.90.32
プロト: 6
スポーツ: 443 dport: 35255
状態: INIT の種類: フロー
src ユーザー: 不明な
dst ユーザー: 不明
開始時間: 火曜日6月 21 11:37:52 2016
タイムアウト:15 秒
合計バイト数 (c2s): 796
合計バイト数 (s2c): 4759
layer7 パケット数 (c2s): 8 layer7
パケット数 (s2c): 8 vsys
: vsys1
アプリケーション: ssl
ルール: 信頼2016のインターネット
セッションをログに記録する最後に:
セッションエイガーの真のセッション:
HA ピアによって更新された偽のセッション: 偽の
アドレス/ポート変換: ソース
nat ルール: nat トラスト2016インターネットに (vsys1)
layer7 処理: 完了した
URL フィルタリングを有効
に: 偽のセッションを介して syn-クッキー: 偽セッションは、
ホスト上で終了: 偽のセッションは、トンネルを横断: 偽
キャプティブポータルセッション: 偽
進入インタフェース: ethernet1/3
出力インタフェース: ethernet1/6
セッション QoS ルール: N/A (クラス 4)
トラッカーステージファイアウォール: tcp フィン
トラッカーステージ l7proc: プロキシタイマ期限切れ
エンド理由: tcp-fin
詳細について
セッションが復号化されると、アプリケーション ID のルックアップが復号化されたフロー上で発生し、セッションの適用を識別するのに役立ちます。ファイアウォールは、アプリケーションを識別するために十分なデータパケットを読み取る必要があります。SSL ハンドシェイクが完了したら、アプリケーションが不明かどうかを判断するために、最大2000バイトのデータを読み取る必要があります。デコーダが検出されると、例えば、web ブラウジングは、実際のアプリケーションを決定するために5パケット以上かかることがあります。 ほとんどの場合、アプリケーションはそのデータ量を受け取る前に認識されます。
以下のパケットキャプチャ出力を見ると、アプリケーションを識別するためにファイアウォールを有効にしたアプリケーションデータを交換する前に、通信が終了したことがわかります。
これは、通常の tls/ssl が一部のカスタムアプリにラップされている場合にも適用されます: 基になるアプリは暗号化されていない場合は "不明-tcp" になりますが、暗号化のため、アプリ ID は既に ssl を識別しており、アプリとして
この情報が役に立つことを願っています。以下のセクションでは、親指やコメントを残してください。
また見なさい