Linux カーネルには、IPv4 および IPv6 パケットフィルタルールのテーブルをセットアップ、維持、および検査するために使用される iptables および ip6tables があります。iptables および ip6tables は、多数の定義済みテーブルで構成されています。各テーブルには、事前定義されたチェーンが含まれており、ユーザー定義のチェーンを含めることもできます。これらのチェーンには一連のルールが含まれており、各ルールでパケットの一致基準を指定します。事前定義されたテーブルには、raw、mangle、filter、および NAT が含まれます。事前定義されたチェーンには、INPUT、OUTPUT、FORWARD、PREROUTING、および POSTROUTING が含まれます。

Secure Workload エージェントは、パケットを許可またはドロップするルールを含むフィルタテーブルをプログラムします。フィルタテーブルは、事前定義されたチェーンである INPUT、OUTPUT、および FORWARD で構成されます。これらに加えて、エージェントはカスタム TA チェーンを追加して、コントローラからポリシーを分類および管理します。これらの TA チェーンには、ポリシーから派生した Secure Workload ルールと、エージェントによって生成されたルールが含まれています。エージェントは、プラットフォームに依存しないルールを受信すると、それらのルールを解析して iptable、ip6table、または ipset ルールに変換し、フィルタテーブルの TA 定義チェーンに挿入します。ファイアウォールのプログラミング後、エージェントはルールやポリシーの逸脱がないかファイアウォールを監視し、逸脱がある場合は、ファイアウォールを再プログラミングします。また、ファイアウォールでプログラムされたポリシーを追跡し、ポリシーのステータスを定期的にコントローラに報告します。

この動作を表す例を次に示します。

プラットフォームに依存しないネットワーク ポリシー メッセージの一般的なポリシーの構成は次のとおりです。

source set id: “test-set-1”
destination set id: “test-set-2”
source ports: 20-30
destination ports: 40-50
ip protocol: TCP
action: ALLOW
. . .
set_id: “test-set-1”
     ip_addr: 1.2.0.0
     prefix_length: 16
     address_family: IPv4
set_id: “test-set-2”
     ip_addr: 3.4.0.0
     prefix_length: 16
     address_family: IPv4

エージェントは、他の情報とともに、このポリシーを処理し、プラットフォームに固有の ipset および iptabels ルールに変換します。

ipset rule:
Name: ta_f7b05c30ffa338fc063081060bf3
Type: hash:net
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 16784
References: 1
Members:
1.2.0.0/16
Name: ta_1b97bc50b3374829e11a3e020859
Type: hash:net
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 16784
References: 1
Members:
3.4.0.0/16
iptables rule:
TA_INPUT -p tcp -m set --match-set ta_f7b05c30ffa338fc063081060bf3 src -m set --match-
˓→set ta_1b97bc50b3374829e11a3e020859 dst -m multiport --sports 20:30 -m multiport --
˓→dports 40:50 -j ACCEPT

Windows のネイティブコンポーネントである「セキュリティが強化された Windows ファイアウォール」（Windows Firewall with Advanced Security）は、次のようなタイプの設定に基づいてネットワークトラフィックを規制します。

• インバウンド ネットワーク トラフィックを規制するルール。

• アウトバウンド ネットワーク トラフィックを規制するルール。

• ネットワークトラフィックの送信元と宛先の認証ステータスに基づくオーバーライドルール。

• IPsec トラフィックと Windows サービスに適用されるルール。

Secure Workload ネットワークポリシーは、インバウンドおよびアウトバウンドのファイアウォールルールを使用してプログラムされます。

Windows プラットフォームでは、Secure Workload ネットワークポリシーは次のように適用されます。

1. プラットフォームに依存しないファイアウォールルールを Cisco Secure Workload ネットワークポリシーから Windows ファイアウォールルールに変換します。

2. ルールは Windows ファイアウォールでプログラムされます。

3. Windows ファイアウォールがルールを適用します。

4. Windows ファイアウォールとそのルールセットがモニターされます。変更が検出されると、偏差が報告され、Cisco Secure Workload ネットワークポリシーが Windows ファイアウォールでリセットされます。

Windows ファイアウォールでは、ホストが現在接続しているネットワークに基づいてルールがグループ化されます。それらのルールグループはプロファイルと呼ばれ、次の 3 つのプロファイルがあります。

• ドメインプロファイル

• プライベートプロフィール

• パブリックプロファイル

Secure Workload ルールはすべてのプロファイルにプログラムされますが、アクティブなプロファイル内のルールのみが継続的に監視されます。

Windows ファイアウォールのルールセットは、優先順位に基づいて順序付けられていません。複数のルールがパケットに一致する場合、最も制限的なルールが有効になります。つまり、拒否ルールが許可ルールよりも優先されます。詳細については、Microsoft TechNet の記事を参照してください。

1. ALLOW 1.2.3.30 tcp port 80
2. ALLOW 1.2.3.40 udp port 53
3. BLOCK 1.2.3.0/24 ip
4. ALLOW 1.2.0.0/16 ip
5. Catch-all: DROP ingress, ALLOW egress

ホスト 1.2.3.30 の TCP ポート 80 宛てのパケットがファイアウォールに到達すると、すべてのルールに一致しますが、最も制限の厳しいルール番号 3 が適用され、パケットはドロップされます。この動作は、ルールが順番に評価されてルール 1 が適用され、パケットが許可されるという期待に反します。

この動作の違いは、前述の Windows ファイアウォールの設計により、Windows プラットフォームで予期されるものです。この動作は、異なるルールアクションが設定された重複するルールを持つ混合リストポリシーで観察できます。

次に例を示します。

1. ALLOW 1.2.3.30 tcp
2. BLOCK 1.2.3.0/24 tcp

Windows Advanced Firewall はステートフル ファイアウォールと見なされます。つまり、特定のプロトコル（TCP など）に対して、ファイアウォールは内部状態の追跡を維持して、ファイアウォールに到達する新しいパケットが既知の接続に属しているかどうかを検出します。既知の接続に属するパケットは、ファイアウォールルールを調べることなく許可されます。ステートフル ファイアウォールにより、着信テーブルと発信テーブルでルールを確立することなく、双方向通信が可能になります。

たとえば、Web サーバーについて、ポート 443 へのすべての TCP 接続を受け入れる というルールを考えてみます。

その意図は、ポート 443 でサーバーへのすべての TCP 接続を受け入れ、サーバーがクライアントに向けて通信できるようにすることです。この場合、着信テーブルには、ポート 443 での TCP 接続を許可するルール 1 つのみが挿入されます。発信テーブルにルールを挿入する必要はありません。発信テーブルへのルールの挿入は、Windows Advanced Firewall によって暗黙的に行われます。

Note	ステートフルトラッキングは、明示的な接続を確立および維持するプロトコルにのみ適用されます。他のプロトコルの場合、双方向通信を可能にするために、着信ルールと発信ルールの両方をプログラムする必要があります。

適用が有効になっている場合、プロトコルが TCP のときは、特定の具象ルールがステートフルとしてプログラムされます（エージェントは、コンテキストに基づいて、ルールを着信テーブルまたは発信テーブルのどちらに挿入するかを決定します）。他のプロトコル（ANY を含む）の場合、着信ルールと発信ルールの両方がプログラムされます。

Windows フィルタリング プラットフォーム（WFP）は、ネットワークトラフィック処理フィルタを設定するために Microsoft が提供する一連の API です。ネットワークトラフィック処理フィルタは、カーネルレベルの API およびユーザーレベルの API を使用して設定します。WFP フィルタは、ネットワークレイヤ、トランスポートレイヤ、アプリケーションレイヤの適用（ALE）など、さまざまなレイヤで設定できます。Secure Workload WFP フィルタは、Windows ファイアウォールルールと同様に、ALE レイヤで設定されます。それぞれのレイヤには、重みの高いものから順に並べられた、いくつかのサブレイヤがあります。各サブレイヤ内で、フィルタは重みの高いものから順に並べられます。ネットワークパケットは、すべてのサブレイヤを通過します。各サブレイヤで、ネットワークパケットは、重みに基づいて一致するフィルタを通過し、許可またはブロックのアクションを返します。すべてのサブレイヤを通過した後、「ブロックアクションが許可をオーバーライドする」というルールに基づいてパケットが処理されます。

• Windows ファイアウォール設定の依存関係の回避。

• GPO の制限の克服。

• 移行とポリシー復元の容易化。

• ユーザーによるポリシー順序の制御の実現。

• Windows ファイアウォールの厳格なブロック優先ポリシー順序の回避。

• ポリシー更新時の CPU オーバーヘッドの削減。

• 効率的な 1:1 ポリシールールフィルタの作成。

• 高速なシングルステップ更新の実現。

適用が WFP を使用するように設定されている場合、Secure Workload フィルタは Windows ファイアウォールルールをオーバーライドします。

WFP モードで、エージェントは次の WFP オブジェクトを設定します。

• プロバイダーは、GUID と名前を持ち、フィルタ管理に使用され、パケットフィルタリングには影響しません。

• サブレイヤーは、GUID、名前、および重みを持ちます。Cisco Secure Workload サブレイヤーは、Windows Advanced Firewall サブレイヤーよりも大きな重みで設定されます。

• フィルタは、名前、GUID、ID、重み、レイヤー ID、サブレイヤーキー、アクション（PERMIT/BLOCK）、および条件を持ちます。WFP フィルタは、ゴールデンルール、セルフルール、およびポリシールール用に設定されています。エージェントは、ポートスキャン防止フィルタも設定します。Cisco Secure Workload フィルタは、FWPM_FILTER_FLAG_CLEAR_ACTION_RIGHT フラグを使用して設定されます。このフラグにより、Cisco Secure Workload フィルタが Microsoft ファイアウォールルールによって上書きされないようになります。Cisco Secure Workload ネットワークポリシールールごとに、方向（インバウンドまたはアウトバウンド）とプロトコルに基づいて、1 つ以上の WFP フィルタが設定されます。

  Note	ポート スキャンプ ローブがホストに送信されると、[ポリシー分析（Policy Analysis）] ページに、対応するフローのステータスが PERMITTED:REJECTED と表示されます。これは、3.10.2.11 までのすべてのエージェント バージョンに適用されることに注意してください。

TCP インバウンドポリシーの場合：

id: 14 , TCP Allow 10.195.210.184 Dir=In localport=3389

設定された WFP フィルタは、次のとおりです。

Filter Name:                  Secure Workload Rule 14
------------------------------------------------------
EffectiveWeight:                       18446744073709551589
LayerKey:                              FWPM_LAYER_ALE_AUTH_LISTEN_V4
Action:                                Permit
Local Port:                            3389
Filter Name:                           Secure Workload Rule 14
------------------------------------------------------
EffectiveWeight:                       18446744073709551589
LayerKey:                              FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4
Action:                                Permit
RemoteIP:                              10.195.210.184-10.195.210.184

Secure Workload エージェントは、インバウンド CATCH-ALL ポリシーの Cisco Secure Workload デフォルト インバウンド フィルタとアウトバウンド CATCH-ALL ポリシーの Cisco Secure Workload デフォルト アウトバウンド フィルタを設定します。

• エージェントは、WAF ルールまたは WAF プロファイルを監視しません。

• エージェントはファイアウォールの状態を監視しません。

• エージェントでは、ファイアウォールの状態を有効にする必要はありません。

• エージェントは GPO ポリシーと競合しません。

WFP モードでのエージェント適用は、混合リストまたはグレーリストのポリシーをサポートします。

エージェント適用セクションからの混合リスト（許可および拒否の両方）ポリシーの例を考えてみます。

1. ALLOW 1.2.3.30 tcp port 80-            wt1000
2. BLOCK 1.2.3.0/24 ip-                   wt998
3. ALLOW 1.2.0.0/16 ip-                   wt997
4. Catch-all: DROP ingress, ALLOW egress - wt996

ホスト 1.2.3.30 tcp ポート 80 に向かうパケットがファイアウォールに到達すると、フィルタ 1 に一致し、許可されます。しかし、ホスト 1.2.3.10 に向かうパケットは、フィルタ 2 のためにブロックされます。ホスト 1.2.2.10 に向かうパケットは、フィルタ 3 によって許可されます。

Cisco Secure Workload の WFP フィルタは、ALE レイヤで構成されます。ネットワークトラフィックは、ソケットの connect()、listen()、および accept() 操作に対してフィルタ処理されます。L4 接続に関連するネットワークパケットは、接続が確立されるとフィルタ処理されません。

設定済みの Secure Workload WFP フィルタは、c:\program files\tetration\tetenf.exe を使用して表示できます。サポートされているオプションは、次のとおりです。

• 管理者権限で cmd.exe を実行します。

• c:\program files\tetration\tetenf.exe -l -f <-verbose> <-output=outfile.txt> を実行します。

または

• 管理者権限で cmd.exe を実行します。

• netsh wfp show filters を実行します。

• 設定された Secure Workload フィルタについて filters.xml を確認します。

設定済みの Secure Workload WFP フィルタは、c:\program files\tetration\tetenf.exe を使用して削除できます。フィルタを誤って削除しないようにするには、削除コマンドを実行する際、トークンを <yyyymm> 形式で指定します。ここで、yyyy には現在の年、mm には現在の月を数値形式で指定します。たとえば、今日の日付が 2021 年 1 月 21 日の場合、トークンは -token=202101 です。

サポートされているオプションは、次のとおりです。

• 管理者権限で cmd.exe を実行します。

• 設定済みのすべての Secure Workload フィルタを削除するには、c:\program files\tetration\tetenf.exe -d -f -all - token=<yyyymm> を実行します。

• 設定済みのすべての Secure Workload WFP オブジェクトを削除するには、c:\program files\tetration\tetenf.exe -d -all -token=<yyyymm> を実行します。

• Secure Workload WFP フィルタを名前で削除するには、c:\program files\tetration\tetenf.exe -d -name=<WFP filter name> -token=<yyyymm> を実行します。

• 適用モードが WFP に設定されている場合、エージェント設定プロファイルの [ルールの保持（Preserve Rules）] 設定は無効になります。

• Windows 2008 R2 は、Windows OS ベースのフィルタリングポリシーをサポートしていません。

• ネットワークポリシーは単一のユーザー名で設定できますが、MS Firewall UI は複数のユーザーをサポートします。

• Windows OS ベースのポリシーを使用している場合、コンシューマやプロバイダーの範囲またはフィルタには Windows エージェントのみを含める必要があります。含めないと、Windows 以外の OS（Linux、AIX）ではポリシーがスキップされ、適用ステータスで同期エラーが報告されます。

• フィルタリング基準が緩い Windows OS フィルタを作成しないでください。そのような基準では、不要なネットワークポートが開かれる可能性があります。

• OS フィルタがコンシューマに設定されている場合、ポリシーはコンシューマにのみ適用されます。同様に、プロバイダーに設定されている場合はプロバイダーにのみ適用されます。

• ネットワークフローのプロセスコンテキスト、ユーザーコンテキスト、またはサービスコンテキストに関する知識が乏しいか、知識がまったくないために、ポリシーに Windows OS ベースのフィルタが含まれている場合、ポリシー分析に矛盾が生じます。

Windows OS ベースのフィルタリング属性を使用する場合は、以下のトピックの検証およびトラブルシューティング情報を参照してください。

Cisco TAC は、必要に応じてこの情報を使用して、このようなポリシーのトラブルシューティングを行うことができます。

Cisco Secure Workload 3.10 リリース以降、ソフトウェアエージェントのインストールには、AIX プラットフォームにファイアウォールサービスを提供する Cisco IPFilter アプリケーションが含まれます。

また、カーネル拡張モジュール（/usr/lib/drivers/ipf）としてロードされます。このモジュールには、ipfilter ルールをプログラムするために使用される ipf、ippool、ipfstat、ipmon、ipfs、および ipnat ユーティリティが含まれており、各ルールでパケットの一致基準を指定します。詳細については、AIX マニュアルの IPFilter に関するページを参照してください。

適用が有効な場合、エージェントは IPFilter を使用して、IPv4 パケットを許可またはドロップするルールを含む IPv4 フィルタテーブルをプログラムします。エージェントは、それらのルールをグループ化し、コントローラを使用してポリシーを分類および管理します。ルールには、ポリシーから派生した Secure Workload ルールと、エージェントによって生成されたルールが含まれます。

エージェントは、プラットフォームに依存しないルールを受け取ると、それらのルールを解析して ipfilter または ippool ルールに変換し、フィルタテーブルに挿入します。ファイアウォールのプログラミング後、適用エージェントはルールやポリシーの逸脱がないかファイアウォールを監視し、逸脱がある場合は、ファイアウォールを再プログラミングします。エージェントは、ファイアウォールでプログラムされたポリシーを追跡し、ポリシーのステータスを定期的にコントローラに報告します。

プラットフォームに依存しないネットワーク ポリシー メッセージの一般的なポリシーの構成は次のとおりです。

      source set id: "test-set-1"
      destination set id: "test-set-2"
      source ports: 20-30
      destination ports: 40-50
      ip protocol: TCP
      action: ALLOW
      ...
      set_id: "test-set-1"
         ip_addr: 1.2.0.0
         prefix_length: 16
         address_family: IPv4
      set_id: "test-set-2"
         ip_addr: 5.6.0.0
         prefix_length: 16
         address_family: IPv4

エージェントは、他の情報とともに、ポリシーを処理し、プラットフォーム固有の ippool および ipfilter ルールに変換します。

    table role = ipf type = tree number = 51400
    { 1.2.0.0/16; };

    table role = ipf type = tree number = 75966
    { 5.6.0.0/16; };

pass in quick proto tcp from pool/51400 port 20:30 to pool/75966 port 40:50 flags S/SA group TA_INPUT
pass out quick proto tcp from pool/75966 port 40:50 to pool/51400 port 20:30 flags A/A group TA_OUTPUT

IPv6 適用はサポートされていません。

1. ルート範囲の所有者は、「構成プロファイル」の作成と「構成インテント」の仕様にのみアクセスできます。

2. ルート範囲の所有者は、所有している範囲のみに関連付けられた構成プロファイルを作成し、それらの構成プロファイルをエージェントに適用できます。

   Note	[エージェント設定プロファイル（Agent Configuration Profile）] で、プロファイルを編集する前に、設定プロファイルを使用してインテントの数を確認できるようになりました。

   

3. サイト管理者は、[エージェント設定（Agent Configuration）] ページのすべてのコンポーネントにアクセスして、インターフェイス構成インテント、リモート Virtual Routing and Forwarding 設定を指定できます。

ネットワークフロー情報は、システムを流れるすべてのパケットを要約したものです。フロー情報をキャプチャするには、詳細と会話の 2 つのモードがあります。デフォルトでは、フロー情報をキャプチャするためにカンバセーションモードが使用されます。キャプチャされたフローはコレクタにエクスポートされ、エクスポートされる情報には次のものが含まれます。

• フロー識別子：ネットワークフローを一意に識別します。これには、IP プロトコル、送信元と宛先の IP、レイヤー 4 ポートなどの一般情報が含まれます。

• IP 情報：TTL、IP フラグ、パケット ID、IP オプション、フラグメンテーションフラグなど、IP ヘッダーに表示される情報が含まれます。

• TCP 情報：シーケンス番号、ACK 番号、TCP オプション、Rcvd ウィンドウサイズなど、TCP ヘッダーに表示される情報が含まれます。

• フロー情報：フローの統計情報（合計パケット数、合計バイト数、TCP フラグ統計情報、パケット長統計情報、ソケット統計情報など）、フローが観察されたインターフェイス インデックス、フローの開始時間と終了時間。

• K8s 環境では、エージェントはポッドとホストからネットワークフローを取得してから、フローを関連付けて、関連するフローとして報告します。これは、次の CNI で認定されます。

  • Calico

  • Flannel

  • Weave

  • AKS/GKE/AWS VPC CNI

  • Openshift CNI

  • Cilium CNI

    Note	Cilium CNI が使用されている場合、ネットワークフローはポッドとホストからキャプチャされますが、フローの関連付けはできません。

カンバセーションモードでは、エージェントは、他のコネクションレス型フローとともに、本質的に双方向の TCP フローのみをエクスポートします。カンバセーションモードは、Windows、AIX、および Linux プラットフォームでサポートされています。カンバセーションモードの詳細については、「Conversation Mode」を参照してください。

Note	K8s 環境では、ポッドまたはホストフローの関連付けはカンバセーションモードでは実行されません。 どちらのモードでも、エージェントは次のフローをエクスポートしません。 ARP/RARP 会話 エージェントからコレクタへのフロー

マシン情報には、ホストで実行されているすべてのプロセスが記述されています。さらに、プロセスに関連付けられたネットワーク情報と、プロセスの起動に使用されるコマンドが含まれています。マシン情報は毎分エクスポートされ、次の情報が含まれます。

• [プロセス ID（Process ID）]

• [ユーザーID（User ID）]：プロセスの所有者

• [親プロセス ID（Parent Process ID）]

• プロセスの起動に使用されるコマンド文字列

• [ソケット情報（Socket information）]：プロトコル（UDP または TCP など）、アドレス タイプ（IPv4 または IPv6）、送信元および宛先 IP、送信元および宛先ポート、TCP 状態、プロセスの開始時刻と終了時刻、バイナリを処理するパス

• [フォレンジック情報（Forensic information）]：詳細については、「互換性」の項を参照してください。

エージェントは、システムの統計や独自の統計を含む、次のようなさまざまな統計を追跡します。

• エージェントの開始時間と稼働時間

• ユーザーモードとカーネルモードでのエージェントの実行時間

• ドロップされた受信データパケットの数

• 成功および失敗した SSL 接続の数

• 総フローパケット数とバイト数

• コレクタにエクスポートされたフローとパケットの合計

• エージェントのメモリおよび CPU の使用状況

  {
    "AgentType":"ENFORCER",
    "Bios":"72EF1142-03A2-03BC-C2F8-F600567BA320",
    "CurrentVersion":"3.5.1.1.mrpm.build.win64-enforcer",
    "DesiredVersion":"",
    "HostName":"win2k12-production-db",
    "IP":"172.26.231.193",
    "Platform":"MSServer2012R2Standard"
  }

  {
    "AgentType":"SENSOR",
    "Bios":"72EF1142-03A2-03BC-C2F8-F600567BA320",
    "CurrentVersion":"3.5.1.1.mrpm.build.win64-sensor",
    "DesiredVersion":"",
    "HostName":"win2k12-production-db",
    "IP":"172.26.231.193",
    "Platform":"MSServer2012R2Standard"
  }

rpm -Uvh tet-sensor-1.101.2-1.el6-dev.x86_64.rpm

   error: cannot create transaction lock on /var/lib/rpm/.rpm.lock (Permission denied).

A：エージェントをインストールするための適切な権限がない場合は、root に切り替えるか、sudo を使用してエージェントをインストールしてください。

Q：「sudo rpm -Uvh tet-sensor-1.0.0-121.1b1bb546.el6-dev.x86_64.rpm」を実行すると、次のエラーが発生しました。

   Preparing...              ########################################### [100%]
   which: no lsb_release in (/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin)
   error: %pre(tet-sensor-site-1.0.0-121.1b1bb546.x86_64) scriptlet failed, exit status 1
   error:   install: %pre scriptlet failed (2), skipping tet-sensor-site-1.0.0-121.1b1bb546

A：システムはエージェントをインストールするための要件を満たしていません。今回のケースでは、lsb_release ツールはインストールされていません。

詳細については、「ソフトウェアエージェントの展開ラベル」の項を参照し、必要な依存関係をインストールしてください。

Q：「sudo rpm -Uvh tet-sensor-1.0.0-121.1b1bb546.el6-dev.x86_64.rpm」を実行すると、次のエラーが発生しました。

  Unsupported OS openSUSE project
  error: %pre(tet-sensor-1.101.1-1.x86_64) scriptlet failed, exit status 1
  error: tet-sensor-1.101.1-1.x86_64: install failed
  warning: %post(tet-sensor-site-1.101.1-1.x86_64) scriptlet failed, exit status 1

A：お使いの OS では、ソフトウェアエージェントの実行がサポートされていません（今回のケースでは、「openSUSE project」はサポートされていないプラットフォームです）。

詳細については、「ソフトウェアエージェントの展開ラベル」の項を参照してください。

Q：すべての依存関係をインストールした後、適切な権限でインストールを実行し、エラーは発生しませんでした。エージェントのインストールが成功したことを確認するにはどうすればよいですか。

A：エージェントをインストールした後、インストールされているかどうかを確認するには、次のコマンドを実行します。

$ ps -ef | grep -e csw-agent -e tet-
root     14158     1  0 Apr03 ?        00:00:00 csw-agent
root     14160 14158  0 Apr03 ?        00:00:00 csw-agent watch_files
root     14161 14158  0 Apr03 ?        00:00:03 csw-agent check_conf
root     14162 14158  0 Apr03 ?        00:01:03 tet-sensor -f conf/.sensor_config
root     14163 14158  0 Apr03 ?        00:02:38 tet-main --sensoridfile=./sensor_id
root     14164 14158  0 Apr03 ?        00:00:22 tet-enforcer --logtostderr
tet-sen+ 14173 14164  0 Apr03 ?        00:00:21 tet-enforcer --logtostderr
tet-sen+ 14192 14162  0 Apr03 ?        00:07:23 tet-sensor -f conf/.sensor_config

csw-agent の 3 つのエントリと、tet-sensor の少なくとも 2 つのエントリが表示されている必要があります。サービスが実行されていない場合は、次のディレクトリが使用可能であることを確認します。使用可能でない場合、インストールは失敗します。

• /usr/local/tet（ほとんどの Linux ディストリビューションの場合）

• /opt/cisco/tetration（AIX、Ubuntu の場合）

• /opt/cisco/secure-workload（Solaris、Debian の場合）

Q：PowerShell エージェント インストーラ スクリプトを実行すると、次のいずれかのエラーが表示されます。

1. 基礎となる接続がクローズしました。受信時に予期せぬエラーが発生しました。

2. 共通のアルゴリズムがないため、クライアントとサーバーが通信できません

[Net.ServicePointManager]::SecurityProtocol

[Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]’Ssl3,Tls,Tls11,Tls12’

This installation package could not be opened. Verify that the package exists and that you can access it, or contact the application vendor to verify that this is a valid Windows Installer package.

msiexec /i “TetrationAgentInstaller.msi” /l*v “msi_install.log” /norestart

Q：基盤となる NIC が Nutanix VirtIO ネットワークドライバの場合、Windows Sensor ソフトウェアのアップグレードに失敗するようです。

A：Npcap 0.9990 と、Nutanix VirtIO ネットワークドライバ 1.1.3 以前のバージョンの間には、非互換性の問題があります。また、Receive Segment Coalescing が有効になっています。

この問題を解決するには、Nutanix VirtIO ネットワークドライバをバージョン 1.1.3 以降にアップグレードします。

Q：Windows Sensor をインストールしました。そのセンサーが登録されていないようであり、sensor_id ファイルには uuid-invalid-platform が含まれています。

set PATH=%PATH%;C:\Windows\System32\

Q：Windows ノードの Kubernetes ポッドからネットワークフローを受信していません。

A：Windows ノードの Kubernetes ポッドからフローをキャプチャするために必要なセッションが実行されているか確認するには、次の手順を実行します。

1. 管理者権限で cmd.exe を実行します。

2. logman query -ets コマンドを実行します。

   次のセッションが実行されていることを確認します。

   • CSW_MonNet：ネットワークフローをキャプチャ

   • CSW_MonHCS：ポッドの作成をモニター

   • CSW_MonNat：NATed フローをモニター

Kubernetes Daemonset のインストール中にインストーラスクリプトが失敗する場合、多くの理由が考えられます。

Q：ノードから到達可能なイメージを提供する Docker レジストリはありますか。

A：Cisco Secure Workload クラスタからイメージをプルするクラスタに関するダイレクトまたは HTTPS プロキシの問題をデバッグします。

Q：コンテナランタイムは SSL/TLS の安全でないエラーを報告していますか。

A：コンテナランタイムの適切な場所にあるすべての Kubernetes ノードに、Secure Workload HTTPS CA 証明書がインストールされていることを確認します。

Q：Docker レジストリ認証とイメージダウンロードの許可が失敗しましたか。

A：各ノードから、Helm チャートによって作成されたシークレットからの Docker プルシークレットを使用して、Daemonset 仕様のレジストリ URL から Docker が手動でイメージをプルするようにしてみてください。手動でのイメージプルも失敗した場合は、問題をさらにデバッグするため、Secure Workload クラスタの registryauth サービスからログをプルする必要があります。

Q：Kubernetes クラスタは Secure Workload アプライアンス内で正常にホストされていますか。

A：クラスタの [サービスステータス（service status）] ページをチェックして、関連するすべてのサービスが正常であることを確認します。[探索（explore）] ページから dstool スナップショットを実行し、生成されたログを取得します。

Q：Docker イメージビルダデーモンは実行されていますか。

A：dstool ログから、ビルドデーモンが実行されていることを確認します。

Q：Docker イメージをビルドするジョブは失敗しますか。

A：dstool ログから、イメージがビルドされていないことを確認します。Docker ビルドポッドログを使用して、ビルドキットを構築中のエラーをデバッグできます。適用コーディネータのログを使用して、ビルドの失敗をさらにデバッグすることも可能です。

Q：Helm チャートを作成するジョブは失敗しますか。

A：dstool ログから、Helm チャートが構築されていないことを確認します。適用コーディネータのログには Helm 構築ジョブの出力が含まれます。Helm チャートの構築ジョブの失敗の正確な理由をデバッグするために使用できます。

Q：インストール bash スクリプトが壊れていましたか。

A：インストール bash スクリプトのダウンロードを再試行します。bash スクリプトには、追加のバイナリデータが含まれています。bash スクリプトをテキストエディタで編集したり、テキストファイルとして保存したりすると、バイナリデータの特殊文字がテキストエディタによって破損または変更される可能性があります。

Q：Kubernetes クラスタ設定：亜種とフレーバーが多すぎます。クラシック K8 をサポートしています。

A：お客様が Kubernetes の亜種を実行している場合、展開のさまざまな段階で多くの障害モードが発生する可能性があります。失敗の段階を分類します： kubectl コマンド実行の失敗、helm コマンド実行の失敗、ポッドイメージのダウンロードの失敗、ポッドの特権モードオプションの拒否、ポッドイメージの信頼コンテンツ署名の失敗、ポッドイメージのセキュリティスキャンの失敗、ポッドバイナリ実行の失敗（アーキテクチャの不一致）、ポッドを実行しても Secure Workload サービスの開始が失敗、Secure Workload サービスが開始しても異常な動作環境が原因でランタイムエラーが発生。

Q：Kubernetes RBAC 資格情報が失敗していますか。

A：特権 DaemonSet を実行するには、K8s クラスタに対する管理者権限が必要です。kubectl 設定ファイルに、ターゲットクラスタおよびそのクラスタの管理者と同等のユーザーを指すデフォルトのコンテキストがあることを確認します。

Q：BusyBox イメージは、すべてのクラスタノードから利用可能またはダウンロード可能ですか。

A：接続の問題を修正し、BusyBox イメージがダウンロードできることを手動でテストします。ポッド仕様で使用されている BusyBox の正確なバージョンは、すべてのクラスタノードで使用可能（事前シード済み）またはダウンロード可能である必要があります。

Q：インストール中に、API サーバーおよび etcd エラーまたは通常のタイムアウトが発生しましたか。

A：Kubernetes クラスタ内のすべてのノードで DaemonSet ポッドがインスタンス化されるため、クラスタの CPU/ディスク/ネットワークの負荷が突然スパイクする可能性があります。この問題は、お客様固有のインストールの詳細に大きく依存します。過負荷が原因で、インストールプロセス（すべてのノードでプルされてディスクに書き込まれるイメージ）に時間がかかりすぎたり、Kubernetes API サーバー、または Secure Workload Docker レジストリエンドポイントが過負荷になったり、プロキシサーバー（設定されている場合）が一時的に過負荷になったりする可能性があります。すべてのノードでイメージのプルが完了し、Kubernetes クラスタノードの CPU/ディスク/ネットワークの負荷が軽減されるのを少し待ってから、インストールスクリプトを再試行します。API サーバーと Kubernetes コントロールプレーンからの etcd エラーは、Kubernetes コントロールプレーンノードがアンダープロビジョニングであるか、アクティビティの突然のスパイクの影響を受けている可能性があることを示しています。

Q：Secure Workload エージェントの操作でランタイムの問題が発生していますか。

A：ポッドが正しく展開され、エージェントの実行が開始されているが、ランタイムの問題が発生している場合は、Linux エージェントのトラブルシューティング セクションを参照してください。Kubernetes の展開が正常にインストールされ、ポッドが開始された後のトラブルシューティング手順は同じです。

エージェントによるクラスタサービスへのチェックが停止しています。この現象は次のような原因で発生する可能性があります。

• ホストがダウンしている可能性がある

• ネットワーク接続が壊れているか、ファイアウォールルールによってブロックされている

• エージェントサービスが停止している

エージェントのアップグレードに失敗しました。これは、次のようないくつかのケースでトリガーされます。

• チェックインスクリプトがパッケージのダウンロードを試行したときにパッケージが見つからない - アップグレードパッケージを解凍できないか、パッケージ内のインストーラを検証できません。

• OS の問題または依存関係によるインストールプロセスの失敗。

現在のエージェントタイプが目的のエージェントタイプと一致しないため、コンバートの試行がタイムアウトしました。この問題は、エージェントがパッケージをダウンロードするために check_in を実行したとき、または wss サービスが convert_commnad をエージェントにプッシュできなかったときに、通信の問題が原因で発生する可能性があります。

エージェントをあるタイプ（優れた可視性など）から別のタイプ（適用など）に変換する能力は、すべてのエージェントが利用できるわけではありません。変換を実行できないエージェントで変換が要求された場合、異常が報告されます。

エージェントによって最後に報告された現在のポリシー（NPC）バージョンが、クラスターで生成された現在のバージョンと一致しません。これは、エージェントとクラスタ間の通信エラー、エージェントがローカルファイアウォールでポリシーを適用できない、またはエージェントの適用サービスが実行されていないことが原因である可能性があります。

Secure Workload エージェントが Pcap デバイスをオープンしてフローをキャプチャできない場合、エージェントログにエラーが表示されます。Pcap デバイスが正常に開かれた場合は、次のように報告されます。

I0609 15:25:52.354 24248 Started capture thread for device <device_name>
I0609 15:25:52.354 71912 Opening device {<device_id>}

I0610 03:24:22.354 16614 Opening device <device_name>
[2020/06/10 03:24:23:3524] NOTICE: lws_client_connect_2: <device_id>: address 172.29.
˓→136.139

エージェントとクラスタ間の接続は外部でブロックされているため、フローやその他のシステム情報が配信されません。これはホスト上のネットワーク ファイアウォール、SSL 復号化サービス、またはサードパーティのセキュリティエージェントに関する 1 つ以上の設定の問題が原因で発生します。

• エージェントとクラスタの間に既知のファイアウォールまたは SSL 復号化セキュリティデバイスがある場合は、すべての Secure Workload コレクタと VIP の IP アドレスへの通信が許可されていることを確認してください。オンプレミスクラスタの場合、コレクタのリストは、Secure Workload Web インターフェイスの左側にあるナビゲーションバーの、[トラブルシューティング（Troubleshoot）] > [仮想マシン（Virtual Machines）] の下に表示されます。collectorDatamover-* を参照してください。Secure Workload クラウドの場合、許可する必要があるすべての IP アドレスがポータルにリストされます。

• SSL 復号化があるかどうかを判断するために、openssl s_client を使用して接続を確立し、返された証明書を表示できます。チェーンに証明書が追加されると、エージェントのローカル CA によって拒否されます。SSL のトラブルシューティング

  Note	通常、「フローエクスポート異常ステータス」を更新するサービスは 5 分ごとに実行されます。この期間は、エージェントのステータス更新が 5000 の小さなバッチで実行されているため、異なる場合があります。そのため、クラスタのエージェントが少ないほど、更新は速くなります。エージェントの数が多い場合、更新には最大 70 分かかることがあります。 データベースに含まれるエージェントレコードの最初のソート後、クラスタとエージェントが安定し、最終的に更新間隔が短くなり、一貫性が向上します。

• コマンド winver.exe を実行します。

• 「サポートされるプラットフォームと要件」に記載されている内容とこのリリースを比較します

• cat /etc/os-release を実行します。

• 「サポートされるプラットフォームと要件」に記載されている内容とこのリリースを比較します

• コマンド uname -a を実行します

• 注：メジャーバージョンとマイナーバージョンが逆になっています。

  p7-ops2> # uname -a
  AIX p7-ops2 1 7 00F8AF944C00

• この例では、ホスト名の後の最初の数字がマイナーバージョン、2 番目の数字がメジャーバージョンであるため、AIX バージョン 7.1 になります。「サポートされるプラットフォームと要件」に記載されている内容とこのリリースを比較します

• プロセスが現在 Npcap ライブラリを使用している場合、Npcap は正常にアンインストールされないことがあります。実行状況を調べるには、次のコマンドを実行します。

  PS C:\Program Files\Npcap> .\NPFInstall.exe -check_dll
  WindowsSensor.exe, Wireshark.exe, dumpcap.exe
  

プロセスが一覧表示される場合は、Npcap アップグレードを続行する前にそれらのプロセスを停止する必要があります。Npcap を使用しているプロセスがない場合、上記のコマンドにより<NULL>のみが表示されます。

• システムにインストールされている CA 証明書を確認します：NPCAP インストーラの証明書の問題

• Windows インストーラの問題を確認します：Windows インストーラの問題

• システム上の他のユーザーがネットワーク インターフェイスに変更を加えていないことを確認します。これが原因で COM ロックが発生し、NDIS ドライバのバインドが妨げられている可能性があります。

Windows 2016 のみに適用

サードパーティの LWF（ライトウェイトフィルタ）ドライバー（netmon など）がある場合、またはセットアップでチーミングアダプタが構成されており、エージェントの展開中に NPCAP がインストールされている場合、次のような状況が発生する可能性があります。

RDP が再接続される

NetBios サービスが再起動する

同様なネットワーク接続に関する問題

これは、Windows 2016 OS のバグが原因です。

チーミング NIC 機能は、物理 NIC（Intel、Broadcom、Realtek、MS 仮想アダプタなど）とチーミングドライバ構成 (スイッチベースでロードバランシングまたはフェールオーバーを備え、複数の NIC にパケットを分散するアルゴリズム) を基盤としています。

一部の NPCAP バージョンでは、特に下位のチーミング NIC へのバインド時に、チーミング NIC との互換性の問題があります。

NIC type : Intel(R) 82574L Gigabit Network Connection
Teaming Mode : Switch Independent
Load Balancing Mode: Address Hash
OS : Windows 2012 , Windows 2012 R2, Windows 2016, Windows 2019
NPCAP version: 1.55

Note	Windows 2008R2 は、Microsoft がサポートする NIC チーミングに対応していません。

TetSensor サービスは、NPCAP サービスが実行されているときに、複製された VM のネットワークフローをキャプチャしないことがあります。この問題は、MSI インストーラを使用して [nostart] フラグなしでエージェントがインストールされた場合、または VM テンプレートかゴールデンイメージで PowerShell インストーラを使用し、[goldenImage] フラグなしでエージェントがインストールされた場合に発生することがあります。

この場合、Secure Workload エージェントサービスは VM テンプレートで実行を開始します。NPCAP がインストールされ、VM テンプレートのネットワークスタックにバインドされます。新しい VM が VM テンプレートから複製されると、NPCAP は新しく複製された VM のネットワークスタックに正しくバインドされません。その結果、NPCAP はネットワークフローをキャプチャできません。

Windows TetSensor サービスが実行されていると、ネットワークパフォーマンスが影響を受けることが確認されています。Windows TetSensor サービス（tetsen.exe）は、Npcap を使用してネットワークフローをキャプチャします。ネットワークフローをキャプチャする Npcap の実装と、tetsen.exe へのネットワークフローが、ネットワークパフォーマンスに影響を及ぼします。

TetSensor をインストール後にネットワークパフォーマンスを比較：クライアント：Windows 2016

Npcap 1.55

TetSensor 構成：適用モード WFP を使用した会話モード

サーバー：Windows 2016

Npcap 1.55

TetSensor 構成：適用モード WFP を使用した会話モード

cmd の実行：iperf3.exe -c<server_ip> -t 40

Npcap 0.9990 でのネットワークパフォーマンス

TetSensor をインストール後にネットワークパフォーマンスを比較：クライアント：Windows 2016

Npcap 0.9990

TetSensor 構成：適用モード WFP を使用した会話モード

サーバー：Windows 2016

Npcap 0.9990

TetSensor 構成：適用モード WFP を使用した会話モード

cmd の実行：iperf3.exe -c<server_ip> -t 40。表：Npcap 0.9990 のネットワークパフォーマンス

class longtable

Note	パフォーマンスは、インストールされている Windows Npcap バージョン、Windows OS、およびネットワーク構成によって異なる場合があります。

インストールされている NPCAP のバージョンや構成が Secure Workload ソフトウェアでサポートされていない場合、OS で未知のパフォーマンス問題や安定性の問題が発生する可能性があります。

サポートされている NPCAP バージョン：0.991 および 1.55

• WSS：クラスタへのポート 443 を介した永続的なソケット接続

• チェックイン：15 ～ 20 分ごとにクラスタへの HTTPS コールを行い、現在の構成を確認し、更新を確認し、クラスタに対してエージェントのアクティブ状態を更新します。これは、アップグレードの失敗も報告します。

• フローエクスポート：フローメタデータをクラスタに送信するための、ポート 443（TaaS）または 5640（オンプレミス）を介した永続的な SSL 接続

• 適用：ポート 443（Taas）または 5660（オンプレミス）を介した永続的な SSL 接続により、適用ポリシーを取り込み、適用状態を報告します。

Teration UI は、非アクティブな（チェックインしなくなった）エージェント、（[統計（Stats）] の [エージェントワークロードプロファイル（Agent Workload Profile ）] ページにある）エクスポートされていないフロー、または失敗した適用のいずれかを報告します。エラーに応じてワークロードのさまざまなログを確認し、問題の原因を特定することができます。

Tue 06/09/2020 17:25:25.08 check_conf_update: "curl did not return 200 code, it's 304,
˓→ exiting"
Tue 06/09/2020 17:25:25.08 check_conf_update: "error code after running check_conf_
˓→update = 2"

cfgserver.go:261] config server: StateConnected, wss://<config_server_ip>:443/wss/
˓→<sensor_id>/forensic, proxy:

collector.go:258] next collector: StateConnected, ssl://<collector_ip>>:5640

ssl_client.cpp:341] Successfully connected to EFE server

Secure Workload エージェントは、TLS を使用して Secure Workload Cloud SaaS サーバーへの TCP 接続を保護します。これらの接続は、次の 3 つの特徴的なチャネルに分類されます。

• エージェント -> ポート TCP/443（TLS）（sensorVIP）経由の Cisco Secure Workload SaaS 制御チャネル

  これは、エージェントが Secure Workload に登録できるようにする低ボリュームの制御チャネルであり、設定のプッシュとソフトウェアアップグレード通知も処理します。

• エージェント -> TCP/443（TLS）（コレクタ）経由の Cisco Secure Workload SaaS フローデータ

  フローデータは、抽出されたフローメタデータ情報であり、このデータは一度に 16 個の IP アドレスのセット 1 つに送信されます。2 番目の IP アドレスのセットはスタンバイ用です。これは、実際のサーバートラフィックの約 1 ～ 5% を占めます。

• エージェント -> TCP/443（TLS）（efe）を介した Cisco Secure Workload SaaS 適用データ

  適用データチャネルは、ポリシーをセンサーにプッシュし、適用統計を収集するために使用される低ボリュームの制御チャネルです。

センサーは、エージェントとともにインストールされているローカル CA に対して、Secure Workload クラウドの制御、データ、および適用サーバーからの TLS 証明書を検証します。他の CA は使用されないため、エージェントに送信される他の証明書は検証に失敗し、エージェントは接続されません。結果的に、エージェントは登録、チェックイン、フローの送信、または適用ポリシーの受信を行わなくなります。

前のセクションで説明したとおり、エージェント通信の SSL/TLS 復号化をバイパスするために、明示的または透過的な Web プロキシを設定することが重要です。バイパスが設定されていない場合、これらのプロキシは復号化を試みる可能性があります

SSL/TLS トラフィックは、自身の証明書をエージェントに送信することによるトラフィックです。エージェントはローカル CA のみを使用して証明書を検証するため、これらのプロキシ証明書によって接続エラーが発生します。

症状には、エージェントがクラスタに登録できない、エージェントがチェックインしない、エージェントがフローを送信しない、（適用が有効になっている場合）エージェントが設定の適用を受信しないなどがあります。

Note	以下のトラブルシューティング手順は、デフォルトのインストールパスが使用されたことを前提としています。Windows: C:Program FilesCisco Tetration Linux: /usr/local/tet. エージェントを別の場所にインストールした場合は、手順をその場所に置き換えてください。

SSL/TLS 接続の問題は、エージェントログで報告されます。ログに SSL エラーがあるかどうかを確認するには、観察された関連する問題に対して次のコマンドを実行します。

grep "NSS error" /usr/local/tet/log/check_conf_update.log

get-content "C:\Program Files\Cisco Tetration\logs\TetUpdate.exe.log" | select-
˓→string -pattern "curl failed SSL peer certificate"

grep "SSL connect error" /usr/local/tet/log/tet-sensor.log

get-content "C:\Program Files\Cisco Tetration\logs\WindowsSensor*.log" | select-
˓→string -pattern "Certificate verification error"

grep "Unable to validate the signing cert" /usr/local/tet/log/tet-enforcer.log

get-content "C:\Program Files\Cisco Tetration\logs\WindowsSensor*.log" | select-
˓→string -pattern "Handshake failed"

curl -v -x http://<proxy_address>:<port> https://<sensorVIP>:443

cd "C:\Program Files\Cisco Tetration"
.\curl.exe -kv -x http://<proxy_address>:<port> https://<sensorVIP>:443

openssl s_client -connect <sensorVIP from TaaS Portal>:443 -CAfile /usr/local/tet/
˓→cert/ca.cert

cd C:\Program Files\Cisco Tetration
.\openssl.exe s_client -connect <sensorVIP from TaaS Portal>:443 -CAfile cert\ca.cert

Verify return code: 0 (ok)

0 s:/C=US/ST=CA/L=San Jose/O=Cisco Systems, Inc./OU=Tetration, Insieme BU/CN=129.146.
˓→155.109
i:/C=US/ST=CA/L=San Jose/O=Cisco Systems, Inc./OU=Tetration Analytics/CN=Customer CA

[Net.ServicePointManager]::SecurityProtocol

Ssl3, Tls

[Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]'Ssl3,
˓→Tls,Tls11,Tls12'