本記事では、NSXセキュリティプラットフォームの分散 IDS / IPS (IDPS) の成功を最大化するためのチューニングについて説明します。
この記事は以下の KB をもとに作成しています。
NSX Advanced Firewall IDPS Performance Tuning Considerations
https://knowledge.broadcom.com/external/article/313654/nsx-advanced-firewall-idps-performance-t.html
NSX-T Data Center
NSX-T Data Center 3.X
NSX-T Data Center 4.X
- 分散 IDPS とは何か?
IDPS は既知の攻撃の兆候を検出するためにシグネチャーを使用してパターンマッチングを行います。
NSX の分散 IDPS は、仮想マシン(VM) の仮想 NIC(vNIC) を検査箇所として動作しており、vNIC を通過する「インバウンド(受信)」、または「アウトバウンド(送信)」のトラフィックを IDPS Engine にリダイレクトする事で検査を行います。ネットワークの境界に配置される ゲートウェイ型の IDPS と異なり、仮想マシンの vNIC 単位で個別に分散して動作する IDPS であるため 分散 IDPS と呼ばれています。これまでのネットワークの境界に配置される ゲートウェイ型の IDPS では実現が難しかった、ネットワークサブネットの構成に依存しない、仮想マシン単位での IDPS による検査を行う事が可能になります。
- 分散 IDPS のチューニングが重要な理由は?
分散 IDPS は仮想マシンの vNIC を検査箇所として動作しているため、パフォーマンスを最大化するためには vNIC で処理される検査対象となるトラフィック量を減らす事が重要です。
分散 IDPS はパケットを IDPS Engine にリダイレクトし、一定のデータのかたまりに対してシグネチャによるパターンマッチングの処理をおこなうため、 IPアドレスや、ポート番号などヘッダ情報にもとずくマッチングを行う Firewall と比較すると、CPU/メモリなどのリソースを多く消費する傾向があります。
そのため、ネットワーク上に流れる全てのトラフィックを検査対象とした場合には、仮想基盤上で動作している仮想マシンの数や、トラフィックの量によってはオーバーサブスクリプション(オーバーフロー)の状態となったり、トラフィック処理の遅延に繋がる事があります。また、パターンマッチングに使用されるシグネチャについては、検査対象となる仮想マシンの特性を見極め、必要なシグネチャを絞り込む事で誤検知 / 過検知(ノイズ) の削減に繋がります。
- スケーラブルで高性能な分散 IDPS 実装のための推奨プラクティスとは?
分散 IDPS の処理遅延やオーバーサブスクリプションの状態になる事を抑制するためには、
第一段階として、分散ファイアウォール(DFW)によって、仮想マシンの vNIC に流入するトラフィックの制御を行う事で、
可能な限り検査対象となるトラフィックを制限することが重要です。
DFW は 分散 IDPS と同様に仮想マシンの vNIC を検査箇所としており、DFW による適切なトラフィックのフィルタリングが行われる事で、
基本的なセキュリティが確立された後、分散 IDPS を使用してセキュリティをさらに強化することができます。
以下にパフォーマンスチューニングのためのステップを提示します。
Step1:分散 IDPS で検査が必要なトラフィックを精査する
仮想基盤の中で、分散 IDPS によるセキュリティ保護が必要な領域を精査します。
Step2:分散 ファイアウォールで適切な通信制御を行う
分散 IDPS の性能を最大化するには、仮想マシンの vNIC 上で処理される検査すべきトラフィック量を減らすことが重要です。
そのためには、DFW の段階で不要なトラフィックをあらかじめフィルタリングすることが有効です。
Step3: 分散 IDPS による検査が不要 / 対応できない通信は除外する
「ストレージ/バックアップ通信」、「暗号化されている通信」、「既に別の IDPS 製品/機能等で検査されている通信」などを検査対象から除外します。
※ ストレージ/バックアップ通信は、長時間大きなデータの送受信が行われる可能性があるため、IDPS に過度の負荷を与える場合があります。
また、差分情報だけが転送されることがあり、別ソリューションでのファイルとしての検査が有効的です。
※ 暗号化されている通信は、データの中身を検査する事が出来ないため、シグネチャによるパターンマッチングの検査を行う事は出来ません。
※ Edge GW の IDPS で既に検査されているトラフィックは、分散 IDPS の検査対象から除外する事が可能です。(※2重チェックの回避)
Step4: 分散 IDPS で検査する通信方向を検討する
分散 IDPS のデフォルトルールでは、インバウンド(受信) / アウトバウンド(送信) の両方向で検査が行われます。
検査は仮想マシンの vNIC を検査箇所として行われる事に留意してください。
そのため、同一の仮想基盤内にある仮想マシン間で通信が発生した場合、同一の通信が、「送信側」仮想マシンの vNIC および 「受信側」仮想マシンの vNIC で2度同じ検査が行われることになり、
性能への影響が懸念されます。そのため、IDPS 検査対象の通信方向は「送信」または「受信」のみを設定するのが推奨です。
<検査方向の設定>
・サーバ VM の場合:
適切なセグメンテーションポリシーが適用され、DFW によるアウトバウンドのフローがフィルタリングされている場合、
インバウンド(受信)方向のみ検査で十分なケースがほとんどです。
これは、一般的に サーバ VM は外部からのリクエスト(インバウンド)に対してレスポンスを返す事が主なワークロードとなるためです。
・クライアント VM ( VDI など) の場合:
VDI は仮想基盤の外部クライアントから仮想基盤内の VDI VMにアクセスする事でデスクトップの仮想化を提供するソリューションです。
VDI VM の多くは外部へのリクエスト(アウトバウンド)を送信しレスポンスを得る事が主なワークロードとなります。
そのため、アウトバウンド(送信)方向のみの検査で十分なケースがほとんどです。
※ IDPS はステートフルです。
例えば、「送信」方向のみを検査対象とした場合であっても、「送信」に対するレスポンス「受信」であれば
同一フローと判断されインバウンドのパケットであってもIDPS の検査対象となります。
IDPS の検査対象の通信を単一方向のみに設定する場合、もう片方向から開始されたフローは IDPS 検査の対象となりませんので注意が必要です。
すべてのサービスにおいて、片方向での検査を推奨しているわけではなく、提供しているサービスの特性や環境を考慮する必要があります。
・通信方向を「受信」のみに設定 → VM からの Command & Control (C2) トラフィックは検査対象外になる。
(対象の仮想マシンのインターネット接続の必要性を確認し、必要に応じて DFW 等で外部への通信を制御する事が可能)
・通信方向を「送信」のみに設定 → VM の脆弱性を悪用する攻撃トラフィックは検査対象外になる
(DFW 等で適切に通信範囲を定めることで、攻撃者の活動範囲を狭めることが可能)
Step5: 分散 IDPS のルールを適切な範囲に絞って設定する
分散 IDPS ルールを設定する際には、まず「全ての通信」を対象とするルールを避ける事が重要です。
適用範囲を制限しない場合、仮想基盤内の、すべての仮想マシン の vNICで発生するのトラフィックが検査対象となり、
IDPS Engine のオーバーサブスクリプションの状態が発生する可能性が高くなります。
分散 IDPS ルールの 「送信元」、「宛先」、「サービス」を必要な対象のみに絞り、ポリシーの「適用先」に
ついても必要な範囲のグループに限定する事を推奨しております。
- IDPS Security Profile のチューニングの実施
NSX IDPS Security Profile では、検査に使用されるシグネチャの選択する事ができます。
IDPS ルールにヒットしたトラフィックは、そのルールに紐づいている IDPS Secrity Profile の設定の内容に沿って、
検査が行われるため IDPS Security Profile を適切に設定する事で、誤検知/過検知によるノイズの削減に繋がります。
・攻撃の重要度(Critical、High、Medium、Low、Suspicious)
※ Signature ID から個別に適用されるシグネチャを取捨選択する事も可能です。
・攻撃タイプ(trojan-activity、Command and Control、Credential-theft .. など)
・CVSS Range:(Critical、High、Medium、Low、None)
・Product Affected: Web_Server_Applications, Linux, Apache ..など)
IDPS 関連の KB:
Traffic Bypassed - IDPS Engine Network Oversubscription Alarm
https://knowledge.broadcom.com/external/article/330494/traffic-bypassed-idps-engine-network-ov.html