• 「サポートされているプラットフォームと要件」を参照してください。

• サービスをインストールして実行するためのルート権限。

• エージェントおよびログファイル用の 1 GB のストレージ容量。

• ホストをモニターしているセキュリティ アプリケーションがエージェントのインストールやエージェントのアクティビティをブロックしないように、それらのアプリケーションでセキュリティの除外を設定します。詳細については、「セキュリティの除外」を参照してください。

• エージェントがインストールされているホストに特別なユーザー tet-sensor を作成します。ホストで PAM または SELinux が設定されている場合は、tet-sensor プロセスの実行やコレクタへの接続のために tet-sensor ユーザーに適切な権限を付与する必要があります。代替のインストールディレクトリがあり、SELinux が設定されている場合は、代替のインストールディレクトリで実行が許可されていることを確認してください。

• エージェントが自動インストール（インストーラスクリプト）メソッドを使用してインストールされている場合は、unzip コマンドを使用できる必要があります。

優れた可視性と適用のために Linux エージェントをインストールする方法：

• エージェント スクリプト インストーラ方式を使用した Linux エージェントのインストール

  • NVDIA SmartNIC（Bluefield DPU）のエージェントサポート

• エージェント イメージ インストーラ方式を使用した Linux エージェントのインストール

• 「サポートされているプラットフォームと要件」の項を参照してください。

• インストールとサービス実行のための管理者権限が必要です。

• Windows 2008 R2 を実行しているワークロードでは、Npcap をインストールする必要があります。また、インストールされているエージェントのバージョンがバージョン 3.8 より前の場合も、Npcap をインストールする必要があります。Npcap ドライバがまだインストールされていない場合、推奨される Npcap バージョンが、サービスの開始後にエージェントによってバックグラウンドでインストールされます。詳細については、Npcap のバージョン情報を参照してください。

• エージェントおよびログファイル用の 1 GB のストレージ容量。

• エージェントのインストールに必要な Windows サービスを有効にします。Windows ホストのセキュリティが強化されている場合や、デフォルト設定から逸脱している場合は、一部の Windows サービスが無効になっている可能性があります。詳細については、「必要な Windows サービス」の項を参照してください。

• ホストをモニターしており、エージェントのインストールやエージェントのアクティビティをブロックする可能性があるセキュリティ アプリケーションで設定されたセキュリティ除外。詳細については、「セキュリティの除外」を参照してください。

優れた可視性および適用の目的で Windows エージェントをインストールするには、2 つの方法があります。

• エージェント スクリプト インストーラ方式を使用した Windows エージェントのインストール

• エージェント イメージ インストーラ方式を使用した Windows エージェントのインストール

ゴールデンイメージを使用したインストールも可能です。詳細については、「VDI インスタンスまたは VM テンプレートへのエージェントの展開（Windows）」を参照してください。

1. サービス CswAgent が設定されたサービス ユーザー コンテキストで実行されていることを確認します。CswAgent は同じサービス ユーザー コンテキストで実行されます。

   管理者権限で cmd.exe コマンドを実行します。

   sc qc cswagent コマンドを実行します。

   SERVICE_START_NAME <configured service user> を確認します。

   または

   services.msc コマンドを実行します。

   Cisco Secure Workload Deep Visibility という名前を検索します。

   <configured service user> の Log On As を確認します。

   Cisco Secure Workload Enforcement という名前を検索します。

   <configured service user> の Log On As を確認します。

   または

   tasklist /v | find /i “cswengine” コマンドを実行します。

   実行中のプロセスのユーザーコンテキストを確認します（5 列目）。

Windows エージェントのインストール後、次のいずれかの方法を使用して、既存の優れた可視性および適用のサービスを変更します。

• services.msc を使用します。

  

• 任意のサードパーティ アプリケーションを使用して、サービスを構成します。

• 次のコマンドを使用します。

  1. 管理者として cmd を実行します。

  2. 次のコマンドを実行して、サービスアカウント名を使用してサービスを変更します。

     • sc config cswagent obj= <service user name> password= <password>

  3. 次のコマンドを実行して構成を確認します。

     • sc qc cswagent

  4. 次のコマンドを実行して、CswAgent サービスを再起動します。

     1. sc stop cswagent

     2. sc start cswagent

デフォルトでは、エージェントのインストール後にエージェントサービスが自動的に開始されます。ゴールデンイメージにインストールする場合は、インストーラフラグを使用して、エージェントサービスが開始されないようにする必要があります。インスタンスがゴールデンイメージから複製されると、エージェントサービスは予想どおりに自動的に開始されます。

エージェントではゴールデン VM に Npcap はインストールされませんが、必要に応じて、ゴールデンイメージから複製された VM インスタンスに自動的にインストールされます。詳細については、「Windows エージェントインストーラと Npcap」を参照してください。

1. サポートされている Npcap バージョンについては、https://www.cisco.com/go/secure-workload/requirements/agents のサポートマトリックスを参照してください。

2. インストール：

   Npcap がインストールされていない場合、エージェントはサービスの開始から 10 秒後にサポートされているバージョンをインストールします。ユーザーが Npcap をインストールしていても、そのバージョンがサポートされているバージョンより古い場合、Npcap はアップグレードされません。Npcap を手動でアップグレードまたはアンインストールするか、オプション overwritenpcap=yes を指定してエージェントインストーラを実行するか、または -npcap を指定してインストーラスクリプトを実行して、サポートされている Npcap バージョンを取得してください。Npcap ドライバがアプリケーションで使用されている場合、エージェントは後で Npcap をアップグレードします。

3. アップグレード：

   Npcap が Windows エージェントによってインストールされ、そのバージョンがサポートされているバージョンより古い場合、Npcap はサービスの開始から 10 秒後にサポートされているバージョンにアップグレードされます。Npcap ドライバがアプリケーションで使用されている場合、エージェントは後で Npcap をアップグレードします。Npcap が Windows エージェントによってインストールされていない場合、Npcap はアップグレードされません。

4. アンインストール：

   Npcap が Windows エージェントによってインストールされている場合、Npcap はそのエージェントによってアンインストールされます。Npcap がユーザーによってインストールされていても、overwritenpcap=yes でエージェントインストーラによってアップグレードされた場合、Npcap はアンインストールされません。Npcap ドライバがアプリケーションで使用されている場合、エージェントは Npcap をアンインストールしません。

最新バージョンの Windows 以降、エージェントは、ndiscap.sys（Microsoft 組み込み）ドライバと、Windows を使用したイベントトレース（ETW）フレームワークを使用して、ネットワークフローをキャプチャします。

最新バージョンへのアップグレード中に、以下のことが行われます。

• エージェントが npcap.sys から ndiscap.sys に切り替わります。

• 次の場合、エージェントインストーラによって Npcap がアンインストールされます。

  • Npcap がエージェントによってインストールされている。

  • Npcap が使用されていない。

  • OS バージョンが Windows Server 2008 R2 ではない。

エージェントサービスが開始されると、エージェントが、ETW セッション、CSW_MonNet、および CSW_MonDns（DNS データ用）を作成し、ネットワークフローのキャプチャを開始します。

（注）

Windows Server 2012 では、DNS データのネットワークパケットが解析されます。 Windows Server 2012 以降のホスト上の Windows エージェントでは、コンシューマとプロバイダーのユーザー名がキャプチャされるため、ユーザー名をフロー観測で使用できます。この機能は、OS の制限により、Windows Server 2008 R2 ではサポートされていません。エージェント設定プロファイルで、以下を設定してユーザー名をキャプチャします。 PID/ユーザールックアップを有効にします。 [フロー分析の忠実度（Flow Analysis Fidelity）] を [詳細（Detailed）] に設定します。

• 「サポートされているプラットフォームと要件」を参照してください。

• 優れた可視性のための追加要件：

  • サービスをインストールして実行するためのルート権限。

  • エージェントおよびログファイルのストレージ要件：500 MB。

  • ホストをモニタリングしているセキュリティ アプリケーションで設定されているセキュリティの除外。セキュリティの除外は、他のセキュリティ アプリケーションがエージェントのインストールやエージェントのアクティビティをブロッキングするのを防ぐために必要です。詳細については、「セキュリティの除外」を参照してください。

  • AIX では、20 個のネットデバイスのフローキャプチャのみサポートされます（バージョンが AIX 7.1 TL3 SP4 以前の場合は 6 個のネットデバイス）。優れた可視性エージェントは、最大 16 個のネットワークデバイスからキャプチャを行い、他の 4 個のキャプチャセッションを一般的なシステム用途（tcpdump など）に排他的に使用できるようにします。

  • 優れた可視性エージェントは、20 台のネットワークデバイスのフローを確実にキャプチャするために、次のことを実行します。

    • エージェントは、エージェントディレクトリ（/opt/cisco/tetration/chroot/dev/bpf0 - /opt/cisco/tetration/chroot/dev/bpf15）の下に 16 個の bpf デバイスノードを作成します。

    • bpf を使用する tcpdump およびその他のシステムツールは、未使用のノード（!EBUSY）が見つかるまで、システムデバイスノード（/dev/bpf0-/dev/bpf19）をスキャンします。

    • エージェントが作成した bpf ノードとシステム bpf ノードは同じメジャーまたはマイナーを共有し、各メジャーまたはマイナーは 1 つのインスタンス（tcpdump またはエージェント）によってのみ開かれます。

    • エージェントはシステムデバイスノードにアクセスせず、tcpdump のようにデバイスノードを作成しません。tcpdump-D では /dev/bpf0 が作成されます。. . /dev/bpf19 が存在しない場合これらを作成します）。

  • システムで iptrace を実行すると、特定のシナリオで tcpdump および優れた可視性エージェントからのフローキャプチャが防止されます。これは設計上の既知の問題であり、IBM に確認する必要があります。

    • エージェントをインストールする前にこのシナリオが存在するか確認するには、tcpdump を実行します。エラーメッセージ tcpdump: BIOCSETIF: en0: File exists が表示される場合、iptrace はフローキャプチャをブロックしています。iptrace を停止すると、問題が解決します。

• プロセスの可視性とフォレンジックは、AIX 7 および POWER8 以降でサポートされています。

• ポリシーの適用に関する追加要件：

  • IP セキュリティフィルタ（smitty ipsec4）が有効になっている場合、事前チェックでエージェントのインストールが失敗します。エージェントをインストールする前に、IP セキュリティフィルタを無効にすることを推奨します。

  • IP セキュリティが有効になっている場合、Cisco Secure Workload エンフォーサエージェントの実行中にエラーとして報告され、エンフォーサエージェントは適用を停止します。エンフォーサエージェントの実行中に IP セキュリティフィルタを安全に無効化する方法については、サポートにお問い合わせください。

• 「サポートされているプラットフォームと要件」を参照してください。

• サービスをインストールして実行するためのルート権限。

• エージェントおよびログファイル用の 1 GB のストレージ容量。

• ホストを監視しているセキュリティ アプリケーションでセキュリティの除外を設定し、他のセキュリティ アプリケーションがエージェントのインストールやエージェントのアクティビティをブロックしないようにします。詳細については、「セキュリティの除外」を参照してください。

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 によって暗黙的に行われます。

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

適用が有効になっている場合、プロトコルが 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 フィルタが設定されます。

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

AIX の IPFilter パッケージは、ファイアウォールサービスを提供するために使用され、AIX ではカーネル拡張パックとして利用できます。

また、カーネル拡張モジュール（/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. ルート範囲の所有者は、所有している範囲のみに関連付けられた構成プロファイルを作成し、それらの構成プロファイルをエージェントに適用できます。

   （注）	[エージェント設定プロファイル（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

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

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

（注）	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 のトラブルシューティング

  （注）	通常、「フローエクスポート異常ステータス」を更新するサービスは 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

（注）	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

（注）	パフォーマンスは、インストールされている 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 のみを使用して証明書を検証するため、これらのプロキシ証明書によって接続エラーが発生します。

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

（注）	以下のトラブルシューティング手順は、デフォルトのインストールパスが使用されたことを前提としています。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'