エージェントによるポリシーの適用

デフォルトでは、ワークロードにインストールされたエージェントにはポリシーを適用する機能がありますが、適用は無効になっています。準備ができたら、設定目的に基づいて、これらのエージェントが選択したホストにポリシーを適用するようにできます。

エージェントがポリシーを適用すると、ファイアウォールが、送信元、宛先、ポート、プロトコル、方向などのパラメータに基づいて特定のネットワークトラフィックを許可するかドロップするかを指定する、順序付けられた一連のルールが適用されます。ポリシーの詳細については、Cisco Secure Workload でのポリシーのライフサイクルの管理を参照してください。

エージェントを使用した適用

  • エージェントは、セキュアな TCP または SSL チャネルを介してポリシーを受け取ります。

  • エージェントは特権ドメインで実行されます。エージェントは、Linux マシンでは root として実行され、Windows マシンでは SYSTEM として実行されます。

  • プラットフォームによっては、ポリシーの適用が有効になっている場合、エージェントはファイアウォールを完全に制御したり、既存の設定済みルールと連携して動作したりできます。

  • 適用オプションの詳細、およびエージェントを有効にしてポリシーを適用するように構成する方法については、「エージェント構成プロファイルの作成」を参照してください。

高度な詳細

適用を有効にすると、エージェントがコントローラに接続できるようにするゴールデンルールが作成されます。エージェントは、TLS または SSL プロトコルを使用した双方向の安全なチャネルを介して、コントローラの適用フロントエンド(EFE)と通信します。コントローラからのメッセージは、ポリシーの生成者によって署名され、エージェントによって検証されます。

エージェントは、コントローラから、プラットフォームに依存しないスキーマでポリシーを受信します。エージェントは、これらのプラットフォームに依存しないポリシーをプラットフォーム固有のポリシーに変換し、エンドポイントのファイアウォールをプログラムします。

また、ファイアウォールの状態をアクティブにモニターし、適用されたポリシーの逸脱を検出すると、キャッシュされたポリシーをファイアウォールに再度適用します。エージェントは、それ自体のシステムリソース(CPU やメモリなど)の消費もモニターします。

エージェントは、EFE を使用して定期的にステータスと統計レポートをコントローラに送信します。ステータスレポートには、プログラムされた最新のポリシーステータス(成功、失敗、エラーなど)が含まれます(存在する場合)。統計レポートには、プラットフォームに応じたポリシー統計(許可およびドロップされたパケット、バイト数など)が含まれます。

Linux プラットフォームでのエージェントの適用

Linux プラットフォームでは、エージェントは iptables、ip6tables、または ipset を使用してネットワークポリシーを適用します。ホストでエージェントを有効にすると、デフォルトで iptables を制御およびプログラムします。IPv6 ネットワークスタックが有効になっている場合、エージェントは、ip6tables を使用して IPv6 ファイアウォールを制御します。

Linux iptables または ip6tables

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

不具合

ipset カーネルモジュール

エージェント設定プロファイルで、適用が有効になっており、ルールの維持が無効になっている場合、Linux ホストで実行されているエージェントにより、ipset カーネルモジュールの max_sets 設定が十分大きいことが確認されます。変更が必要な場合、エージェントは ipset カーネルモジュールを新しい max_sets 値でリロードします。[ルールの維持(Preserve Rules)] が有効になっている場合、エージェントにより現在の ipset モジュールの max_sets 値がチェックされますが、変更はされません。現在設定されている max_sets 値は、cat /sys/module/ip_set/parameters/max_sets で確認できます。

ホストファイアウォールのバックアップ

エージェント設定プロファイルで初めて適用が有効になると、Linux ホストで実行されているエージェントは、ホストのファイアウォールを制御する前に、ipset および ip[6] テーブルの現在のコンテンツを /opt/cisco/tetration/backup に保存します。

適用の設定を連続して無効化または有効化しても、バックアップは生成されません。このディレクトリは、エージェントのアンインストール後に削除されません。

WAF モードの Windows プラットフォームでのエージェントの適用

Windows プラットフォームでは、Secure Workload エージェントは Windows ファイアウォールを使用してネットワークポリシーを適用します。

セキュリティが強化された Windows ファイアウォール

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

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

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

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

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

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

Secure Workload ルールと Windows ファイアウォール

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

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

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

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

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

セキュリティ プロファイル(Security Profiles)

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

他のファイアウォールやポリシーからの干渉

Secure Workload ネットワークポリシーを意図したとおりに適用するには、エージェントに Windows ファイアウォールの完全かつ排他的な制御を許可することを推奨します。次の場合、エージェントはポリシーを確実に適用できません。

  • サードパーティのファイアウォールが存在する(Windows ファイアウォールは、ホスト上でアクティブなファイアウォール製品である必要があります)。

  • ファイアウォールが現在のプロファイルに対して無効になっている。

  • 競合するファイアウォール設定がグループポリシーを使用して展開されている。以下の設定で競合が発生する場合があります。

    • ファイアウォールルール。

    • 現在のプロファイルに設定されたデフォルトのインバウンドまたはアウトバウンドアクションがポリシーのキャッチオールルールとは異なる。

    • ファイアウォールが現在のプロファイルに対して無効になっている。

ステートフル適用

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

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

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


Note


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


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

不具合

ホストファイアウォールのバックアップ

エージェント設定プロファイルで初めて適用が有効になると、Windows ホストで実行中のエージェントは、ホストのファイアウォール制御を開始する前に、現在の Windows Advanced Firewall のコンテンツを ProgramData\Cisco\Tetration\backup にエクスポートします。適用の設定を連続して無効化または有効化しても、バックアップは生成されません。このディレクトリは、エージェントのアンインストール時に削除されません。

WFP モードでの Windows プラットフォームにエージェントを適用

Windows プラットフォームでは、エージェントは WFP(Windows フィルタリング プラットフォーム)フィルタをプログラミングするネットワークポリシーを適用します。Windows の高度なファイアウォールは、ネットワークポリシーの設定には使用されません。

Windows フィルタリング プラットフォーム

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

WAF における WFP の利点

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

  • GPO の制限の克服。

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

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

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

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

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

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

エージェントによる WFP のサポート

適用が 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 デフォルト アウトバウンド フィルタを設定します。

エージェント WFP のサポートと Windows ファイアウォール

  • エージェントは、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 接続に関連するネットワークパケットは、接続が確立されるとフィルタ処理されません。

設定された WFP フィルタの可視性

設定済みの 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 を確認します。

WFP モードでのステルスモードフィルタの無効化

ステルス モードは、Windows のデフォルトのセキュリティ機能です。アクティブなリスナーを持たないポートでの接続試行を受信すると、オペレーティング システムが送信する発信制御パケットをブロックします。Cisco Secure Workload エージェントが Windows ワークロードに WFP モードでポリシーを適用する場合、フィルタをプログラムしてステルス モード機能を実装します。

この機能は推奨されませんが、特別な状況下では、管理者がこの機能を無効にすることができます。Cisco Secure Workload エージェントがワークロードにポリシーを適用する場合は、次の手順に従ってステルス モード フィルタを無効にします。

ステルス モード フィルタ(ポート スキャン フィルタ)を無効にする手順は次のとおりです。

手順


ステップ 1

\conf\enforcer.cfg を編集します。

ステップ 2

disable_wfp_stealth_mode: 1 を追加します。

ステップ 3

ファイルを保存します。

ステップ 4

管理者権限で次のコマンドを実行して、CswAgent サービスを再起動します。

  1. sc.exe cswagent コマンドを実行して、CswAgent サービスを停止します。

  2. sc.exe cswagent コマンドを実行して、CswAgent サービスを開始します。

ステップ 5

確認するには、次の手順に従います。

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

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


 
“Tetration Internal Rule block portscan” filters are not configured.

(注)  


Cisco Secure Workload エージェントが新しいバージョンにアップグレードされると、この構成は自動的に削除されます。


Windows でステルス モードを無効にする方法の詳細については、『ステルス モードを無効にする方法 - Windows Server |Microsoft 学習』を参照してください。

設定済みの WFP フィルタの削除

設定済みの 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 モードの既知の制限事項

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

Windows 属性のポリシーの設定

Windows ベースのワークロードにポリシーを適用する際の精度をさらに高めるために、次の方法でネットワークトラフィックをフィルタ処理できます。

  • アプリケーション

  • サービス名(Service Name)

  • ユーザー名(ユーザーグループありまたはなし)

このオプションは、WAF モードと WFP モードの両方でサポートされています。Windows OS ベースのフィルタは、生成されたネットワークポリシーでコンシューマフィルタとプロバイダーフィルタに分類されます。コンシューマフィルタは、コンシューマワークロードで開始されたネットワークトラフィックをフィルタ処理し、プロバイダーフィルタは、プロバイダーワークロード宛てのネットワークトラフィックをフィルタ処理します。

始める前に

この手順は、既存のポリシーを変更していることが前提となります。Windows OS ベースのフィルタを追加するポリシーを作成していない場合は、最初にそのポリシーを作成します。


重要


Windows 属性を含むポリシーについては、不具合および既知の制限事項を参照してください。


手順


ステップ 1

ナビゲーションウィンドウで、[防御(Defend)] > [セグメンテーション(Segmentation)]をクリックします。

ステップ 2

Windows OS ベースのフィルタを設定するポリシーを含む範囲をクリックします。

ステップ 3

ポリシーを編集するワークスペースをクリックします。

ステップ 4

[ポリシーの管理(Manage Policies)] をクリックします。

ステップ 5

編集するポリシーを選択します。

重要

 

コンシューマとプロバイダーには、Windows ワークロードのみを含める必要があります。

ステップ 6

編集するポリシーのテーブル行で、[プロトコルとポート(Protocols and Ports)] 列の既存の値をクリックします。

ステップ 7

右側のペインで、[プロトコルとポート(Protocols and Ports)] の下にある既存の値をクリックします。

この例では、[TCP : 22 (SSH)] をクリックします。

ステップ 8

[詳細オプションの表示(Show advanced options)] をクリックします。

ステップ 9

アプリケーション名、サービス名、またはユーザー名に基づいてコンシューマフィルタを設定します。

  • アプリケーション名はフルパス名にする必要があります。

  • サービス名は短いサービス名にする必要があります。

  • ユーザー名は、ローカルユーザー名(tetter など)またはドメインユーザー名(sensor-dev@sensor-dev.com、sensor-dev\sensor-dev など)にできます。

  • ユーザーグループは、ローカルユーザーグループ(管理者など)またはドメインユーザーグループ(domain users\\sensor-dev など)にできます。

  • 複数のユーザー名やユーザーグループ名は「,」で区切って指定できます(例:sensor-dev\@sensor-dev.com,domain users\\sensor-dev)。

  • サービス名とユーザー名は同時に設定できません。

ステップ 10

アプリケーション名、サービス名、またはユーザー名に基づいてプロバイダーフィルタを設定します。

前のステップのコンシューマフィルタと同じガイドラインに従います。

ステップ 11

必要に応じてバイナリへのパスを入力します。

たとえば、c:\test\putty.exe と入力します。

ステップ 12

[更新(Update)] をクリックします。


Windows OS ベースの推奨ポリシー設定

可能な場合は、常にポリシーでポートとプロトコルを指定します。 任意のポート、任意のプロトコルを許可することは推奨できません。

たとえば、ポートとプロトコルの制限を含めて生成されたポリシーは次のようになります。



     dst_ports {
      start_port: 22
      end_port: 22
      consumer_filters {
        application_name: "c:\\test\\putty.exe"
      }
     }}
     ip_protocol: TCP

対照的に、任意のプロトコルと任意のポートを使用して iperf.exe によって開始されたネットワーク接続を許可する場合、生成されるポリシーは次のようになります。


  match_set {
    dst_ports {
      end_port: 65535
      consumer_filters {
        application_name: "c:\\test\\iperf.exe"
      }
    }
    address_family: IPv4
    inspection_point: EGRESS
    match_comment: "PolicyId=61008290755f027a92291b9d:61005f90497d4f47cedacb86:"
  }

前述のフィルタの場合、Secure Workload はプロバイダーのネットワークトラフィックを許可する次のようなポリシールールを作成します。


  match_set {
      dst_ports {
      end_port: 65535
    }
    address_family: IPv4
    inspection_point: INGRESS
    match_comment: "PolicyId=61008290755f027a92291b9d:61005f90497d4f47cedacb86:"
  }

このネットワークルールは、プロバイダーのすべてのポートを開きます。任意のプロトコルを使用して OS ベースのフィルタを作成しないことを強く推奨します。

既知の制限事項

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

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

不具合

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

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

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

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

Windows OS ベースのフィルタリング属性を使用したポリシーの確認とトラブルシューティング

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

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

アプリケーション名に基づくポリシー

次の情報を使用して、Windows OS ワークロードのアプリケーション名に基づいてポリシーを確認およびトラブルシューティングします。

次のセクションでは、c:\test\putty.exe として入力されたアプリケーションバイナリのワークロードにポリシーを表示させる方法について説明します。

アプリケーション名に基づくポリシーの例
dst_ports {
start_port: 22
end_port: 22
consumer_filters {
application_name: “c:\test\putty.exe”
}
}}
ip_protocol: TCP
address_family: IPv4
inspection_point: EGRESS
生成されたファイアウォールルール
netsh を使用して生成されたフィルタ

ネイティブの Windows ツールを使用して、高度なポリシーにフィルタが追加されていることを確認するには、次の手順を実行します。

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

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

  • 出力ファイル filters.xml が現在のディレクトリに生成されます。

  • 出力ファイル(filters.xml)の FWPM_CONDITION_ALE_APP_ID でアプリケーション名を確認します。

<fieldKey>FWPM_CONDITION_ALE_APP_ID</fieldKey>
                     <matchType>FWP_MATCH_EQUAL</matchType>
                     <conditionValue>
                            <type>FWP_BYTE_BLOB_TYPE</type>
                            <byteBlob>
                                   <data>
˓→5c006400650076006900630065005c0068006100720064006400690073006b0076006f006
˓→</data>
                                  <asString>\device\harddiskvolume2\temp\putty.exe</
˓→asString>
               </byteBlob>
       </conditionValue>
tetenf.exe -l -f を使用して生成された WFP フィルタ
Filter Name:                   Secure Workload Rule 1
------------------------------------------------------
EffectiveWeight:               18446744073709551592
LayerKey:                      FWPM_LAYER_ALE_AUTH_CONNECT_V4
Action:                        Permit
RemoteIP:                      10.195.210.15-10.195.210.15
Remote Port:                   22
Protocol:                      6
AppID:                         \device\harddiskvolume2\test\putty.exe
無効なアプリケーション名
  • WAF モードでは、無効なアプリケーション名に対してファイアウォールルールが作成されます。

  • WFP モードでは、無効なアプリケーション名に対して WFP フィルタは作成されませんが、NPC は拒否されません。エージェントは警告メッセージをログに記録し、残りのポリシールールを設定します。

サービス名に基づくポリシー

次の情報を使用して、Windows OS ワークロードのサービス名に基づいてポリシーを確認およびトラブルシューティングします。

次のセクションでは、ワークロードにポリシーを表示させる方法について説明します。

サービス名に基づくサンプルポリシー
    dst_ports {
             start_port: 22
             end_port: 22
             provider_filters {
                    service_name: “sshd”
             }
         }}
         ip_protocol: TCP
         address_family: IPv4
         inspection_point: INGRESS
生成されたファイアウォールルール
netsh を使用して生成されたフィルタ

ネイティブの Windows ツールを使用して、高度なポリシーにフィルタが追加されていることを確認するには、次の手順を実行します。

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

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

  • 出力ファイル filters.xml が現在のディレクトリに生成されます。

  • 出力ファイル(filters.xml)でユーザー名の FWPM_CONDITION_ALE_USER_ID を確認します。

    <item>
                         <fieldKey>FWPM_CONDITION_ALE_USER_ID</fieldKey>
                         <matchType>FWP_MATCH_EQUAL</matchType>
                         <conditionValue>
                                    <type>FWP_SECURITY_DESCRIPTOR_TYPE</type>
                                    <sd>O:SYG:SYD:(A;;CCRC;;;S-1-5-80-3847866527-469524349-687026318-
    →516638107)</sd>
                         </conditionValue>
    </item>
tetenf.exe -l -f を使用して生成された WFP フィルタ
Filter Name:       Secure Workload Rule 3
------------------------------------------------------
EffectiveWeight:            18446744073709551590
LayerKey:                   FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4
Action:                     Permit
Local Port:                 22
Protocol:                   6
User or Service:            NT SERVICE\sshd
無効なサービス名
  • WAF モードでは、存在しないサービス名に対してファイアウォールルールが作成されます。

  • WFP モードでは、存在しないサービス名に対して WFP フィルタは作成されません。

  • サービス SID タイプは「無制限」または「制限付き」である必要があります。サービスタイプが「なし」の場合、ファイアウォールルールと WFP フィルタを追加できますが、効果はありません。

    SID タイプを確認するには、次のコマンドを実行します。

    sc qsidtype <service name>

ユーザーグループまたはユーザー名に基づくポリシー

次の情報を使用して、ユーザーグループ名の有無にかかわらず、Windows OS ワークロードのユーザー名に基づくポリシーを確認し、トラブルシューティングします。

このトピックのセクションでは、ワークロードにポリシーを表示する方法について説明します。

このトピックの例は、次の情報を使用して設定されたポリシーに基づいています。

Figure 1. ユーザーグループまたはユーザー名に基づくポリシー
ユーザー名に基づくサンプルポリシー
dst_ports {
          start_port: 30000
          end_port: 30000
          provider_filters {
               user_name: “sensor-dev\sensor-dev”
           }
}}
ip_protocol: TCP
address_family: IPv4
inspection_point: EGRESS
ユーザーグループとユーザー名に基づくサンプルポリシー
dst_ports {
start_port: 30000
end_port: 30000
provider_filters {
user_name: “sensor-dev\domain users,sensor-dev\sensor-dev”
}
}}
ip_protocol: TCP
address_family: IPv4
inspection_point: EGRESS
生成されたファイアウォールルール

ユーザー名に基づくファイアウォールルール

例:ユーザー名 sensor-dev\\sensor-dev に基づくファイアウォールルール

ユーザーグループとユーザー名に基づくファイアウォールルール

例:ユーザー名 sensor-dev\\sensor-dev およびユーザーグループ domain users\\sensor-dev に基づくファイアウォールルール

netsh を使用して生成されたフィルタ

ネイティブの Windows ツールを使用して、高度なポリシーにフィルタが追加されていることを確認するには、次の手順を実行します。

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

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

  • 出力ファイル filters.xml が現在のディレクトリに生成されます。

  • 出力ファイル(filters.xml)でユーザー名の FWPM_CONDITION_ALE_USER_ID を確認します。

    <item>
                <fieldKey>FWPM_CONDITION_ALE_USER_ID</fieldKey>
                <matchType>FWP_MATCH_EQUAL</matchType>
                <conditionValue>
                       <type>FWP_SECURITY_DESCRIPTOR_TYPE</type>
                       <sd>O:LSD:(A;;CC;;;S-1-5-21-4172447896-825920244-2358685150)</sd>
                </conditionValue>
    </item>
tetenf.exe -l -f を使用して生成された WFP フィルタ

ユーザー名に基づくフィルタ

例:ユーザー名 SENSOR-DEV\sensor-dev に基づく WFP ルール

Filter Name:                   Secure Workload Rule 1
------------------------------------------------------
EffectiveWeight:               18446744073709551590
LayerKey:                      FWPM_LAYER_ALE_AUTH_CONNECT_V4
Action:                        Permit
RemoteIP:                      10.195.210.15-10.195.210.15
Remote Port:                   30000
Protocol:                      6
User or Service:               SENSOR-DEV\sensor-dev

ユーザーグループとユーザー名に基づくフィルタ

例:ユーザー名 SENSOR-DEV\\sensor-dev およびユーザーグループ名 SENSOR-DEV\\Domain Users に基づく WFP ルール

Filter Name:         Secure Workload Rule 1
------------------------------------------------------
EffectiveWeight:             18446744073709551590
LayerKey:                    FWPM_LAYER_ALE_AUTH_CONNECT_V4
Action:                      Permit
RemoteIP:                    10.195.210.15-10.195.210.15
Remote Port:                 30000
Protocol:                    6
User or Service:             SENSOR-DEV\Domain Users, SENSOR-DEV\sensor-dev

ネットワークポリシールールにサービス名とユーザー名を設定することはできません。


Note


ユーザー名またはユーザーグループが無効な場合、ネットワークポリシーは Windows エージェントによって拒否されます。


Windows ノードでの Kubernetes ポッドの適用

Windows ワーカーノードに Kubernetes DaemonSet エージェントをインストールすると、AKS 環境の Windows ワーカーノードと Kubernetes ポッドからのネットワークフローがキャプチャされます。

要件

  • Kubernetes ポッドの適用は、Windows ノードを使用する AKS 環境でサポートされています。

  • 適用モードは、[ルールの保持(Preserve Rules)] が [オフ(Off)] に設定されている WFP である必要があります。

  • Microsoft Windows Server 2019 および Windows Server 2022 でサポートされています。

ポリシーは、VFP を使用してポッドに接続されているポートの vSwitch に適用されます。Virtual Filtering Platform(VFP)は、ネットワークトラフィックを処理するフィルタを設定するために使用される vSwitch のコンポーネントです。ポリシーの適用中、[保存モード(Preserve Mode)] は [オフ(Off)] になります。

各フィルタには次の属性があります。

  • id:フィルタ名

  • Direction:[イン(In)] または アウト(Out)]

  • RuleType:[スイッチ(Switch)] または [ホスト(Host)]

    • タイプが [スイッチ(Switch)] の場合は、vSwitch でフィルタを設定します。

    • タイプが [ホスト(Host)] の場合は、WFP フィルタを作成します。

  • Action:[許可(Allow)] または [ブロック(Block)]

  • LocalPorts:ポートまたは範囲を指定できます。例:80 または 100 ~ 200。

  • RemotePorts:LocalPorts と同じです。

  • LocalAddresses:アドレスまたは範囲です。例:10.224.0.5、10.224.1.0/24(10.224.1.1 ~ 10.224.1.10 は許可されません)。

  • RemoteAddress:LocalAddresses と同じ

  • Protocol:ICMP/ TCP/UDP/ IGMP プロトコル 255 は IPPROTO_RAW、256 は PROTO_MAX

ポートは UDP と TCP に対してのみ指定でき、プロトコルが指定されていない限り、ポートはポリシーで許可されません。

仮想ポートでのポリシーの設定は、トランザクションベースの操作です。フィルタの 1 つが無効な場合、ポリシー全体の適用が失敗します。

これはステートフル適用です。アプリケーション、ユーザー、またはサービスベースのポリシーは現在サポートされていません。

Calico との互換性

ポッドの適用は、「ルールの保持」オフモードで機能します。Windows エージェントがポッドにルールを適用すると、すでに設定されているポリシーが削除されます。エージェントの後に Calico プラグインがネットワークポリシーを適用する場合、エージェントはそれを偏差として識別し、Calico によって設定されたネットワークポリシーが削除され、エージェントのポリシーが再適用されます。


Note


適用されたポリシーは、Windows エージェントが Windows ノードでアンインストールされると削除されます。


設定済み VFP フィルタの可視性

Cisco Secure Workload を使用してポッドフィルタを一覧表示するオプションは使用できません。AKS 環境では、組み込みの PowerShell スクリプトを使用できます。c:\k\debug\collectlogs.ps1 PowerShell スクリプトを実行します。設定されたフィルタの出力ファイル vfpoutput.txt および hnsdiag.txt を表示します。

Windows エージェントによって設定された VFP フィルタの削除

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

  2. <installation folder>\tetenf.exe -d -f -pods -token=<yyyymm> コマンドを実行します。


Note


このコマンドは、すべてのポッドの VFP フィルタを削除します。


適用されたポリシーとネットワークフローのトラブルシューティング

  1. netsh wfp start capture keywords=19 コマンドを実行します。

  2. ネットワークトラフィックを実行します。

  3. フローのキャプチャを停止します。netsh wfp stop capture

  4. wfpdiag.cab ファイルから wfpdiag.xml を抽出します。ドロップされたフローを表示します。

許可またはドロップされたネットワークフローをポッドポリシーにマッピングするには、次の手順を実行します。

  1. ETW セッションの開始:logman start <session name> -p Microsoft-Windows-Hyper-V-VfpExt -o <output file.etl> -ets

  2. ネットワークトラフィックを実行します。

  3. フローのキャプチャの停止:logman stop <session name>

  4. コマンドプロンプトで、tracerpt <output file.etl> を実行します。このコマンドは、dumpfile.xml ファイルを作成します。ネットワークフローを表示します。

AIX プラットフォームでのエージェントの適用

AIX プラットフォームでは、Cisco Secure Workload エージェントは IPFilter ユーティリティを使用してネットワークポリシーを適用します。デフォルトでは、ホストでエージェントを有効にすると、エージェントが IPv4 フィルタテーブルを制御およびプログラムします。IPv6 適用はサポートされていません。

IPFilter

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

不具合

ホストファイアウォールのバックアップ

エージェント設定プロファイルで初めて適用が有効になると、AIX ホストで実行されているエージェントは、ホストのファイアウォールを制御する前に、ippool と ipfilter の現在のコンテンツを /opt/cisco/tetration/backup に保存します。適用の設定を連続して無効化または有効化しても、バックアップは生成されません。このディレクトリは、エージェントのアンインストール時に削除されません。

既存の IPFilter のアンロード

適用がオフからオンに移行するときに、シスコ以外の IPfilter パッケージがホストにすでにインストールされている場合、エージェントは IPfilter カーネル拡張を Cisco IPfilter カーネル拡張に置き換え、シスコ以外の IPfilter パッケージをアンインストールします。

Cisco IPFilter のアップグレード

Cisco IPfilter の新しいバージョンがリリースされると、Cisco Secure Workload エージェントは、適用をオフからオンに移行するプロセス中にシステムをアップグレードします。


Note


エージェントの適用がオンの場合はトラフィックが中断される可能性があるため、エージェントの適用がオフのときにアップグレードを実行する必要があります。


既知の制限事項

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

Solaris 11.4 プラットフォームでのエージェント

Solaris 11.4 AIX プラットフォームでは、Cisco Secure Workload エージェントは PF(パケット フィルタ)ユーティリティを使用してネットワーク ポリシーを適用します。Solaris 11.4 は IPv6 の適用をサポートしています。

不具合

共有 IP Solaris ゾーンのポリシーの適用は、グローバル ゾーンにインストールされている エージェントによって実行されます。

ホストファイアウォールのバックアップ

エージェント構成プロファイルで初めて適用が有効になると、Solaris 11.4 ホストで実行されているエージェントは、ホストのファイアウォールを制御する前に、ippool と pffilter の現在のコンテンツを /opt/cisco/tetration/backup に保存します。適用の設定を連続して無効化または有効化しても、バックアップは生成されません。このディレクトリは、エージェントのアンインストール時に削除されません。

Solaris 10 プラットフォームでのエージェントの適用

Solaris 10 プラットフォームでは、Cisco Secure Workload エージェントは IPFilter ユーティリティを使用してネットワークポリシーを適用します。デフォルトでは、ホストでエージェントを有効にすると、エージェントが IPv4 フィルタテーブルを制御およびプログラムします。Solaris 10 は IPv6 適用をサポートしています。

IPFilter

Solaris 10 の IPFilter パッケージは、ファイアウォールサービスを提供するために使用され、Solaris 10 ではカーネル拡張パックとして利用できます。また、カーネル拡張モジュール(/usr/lib/drivers/ipf)としてロードされます。このモジュールには、ipfilter ルールをプログラムするために使用される ipf、ippool、ipfstat、ipmon、ipfs、および ipnat ユーティリティが含まれており、各ルールでパケットの一致基準を指定します。

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

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

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


      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

警告

ホストファイアウォールのバックアップ

エージェント構成プロファイルで初めて適用が有効になると、Solaris 10 ホストで実行されているエージェントは、ホストのファイアウォールを制御する前に、ippool と ipfilter の現在のコンテンツを /opt/cisco/tetration/backup に保存します。適用の設定を連続して無効化または有効化しても、バックアップは生成されません。このディレクトリは、エージェントのアンインストール時に削除されません。

エージェントのステータスと統計の確認

Procedure


Step 1

ナビゲーションウィンドウで、[管理(Manage)] > [ワークロード(Workloads)] > [エージェント(Agents)]の順に選択します。

Step 2

[分布(Distribution)] タブをクリックします。

Step 3

ページの上部からエージェントタイプをクリックします。

Step 4

このページでは、CPU オーバーヘッド、帯域幅オーバーヘッド、エージェントの状態、ソフトウェア アップデート ステータス、エージェント ソフトウェア バージョンの分布、およびエージェント OS の分布を確認できます。

Figure 2. エージェントの分布ページ

Note

 

[エージェントの正常性(Agent Health)]:エージェントは定期的(10 ~ 30 分ごと)に確認します。1 時間 30 分以上チェックインがない場合、エージェントは非アクティブになります。誤報を減らすために、チェックインの間隔が 1 時間~ 1 時間 30 分の場合、エージェントの正常性ステータスは「非アクティブ」ではなく「断続的」に設定されます。


適用ステータスの詳細については、「適用ステータス」の項を参照してください。

エージェント詳細の表示

次の手順では、ワークロードとワークロードにインストールされているエージェントに関する詳細が表示される、[ワークロードプロファイル(Workload Profile)] ページに移動するために使用できるオプションの 1 つを説明します。

Procedure


Step 1

ナビゲーションウィンドウで、[整理(Organize)] > > [範囲とインベントリ(Scopes and Inventory)] の順にクリックします。

Step 2

詳細を表示するワークロードを検索します。

Step 3

IP アドレスをクリックして、エージェントの正常性、IP アドレス、範囲、インベントリタイプ、適用グループ、実験グループ、ユーザーラベル、トラフィック量(合計バイト/合計パケット)などの詳細を表示します。


詳細については、「ワークロード プロファイル」を参照してください。