Aria Operations for Networks NSX VMware Cloud Foundation

全通信ログを集めるとここまでできる！VMware 通信フロー解析サンプル集

VMware Aria Operations for Networks (vRealize Network Insight) により、VMware 仮想基盤の全ての通信ログが収集されておりまして、さまざまなフロー解析ができるようになっています。ですが、「何ができるかサンプルを見ないと、自分たちにどう活用できるのか発想できない」というご意見もよく伺います。運用の課題は日々あり、フロー解析を試みても、解析ツールで何ができるのか、どの結果見れば良いのかわからないことはよくあります。

このブログでは、日々基盤を運用されている VMware ユーザの皆様からいただいたフィードバックをもとに、フロー解析でよく利用される可視化機能をサンプル集の形でご紹介したいと思います。

さまざまなユースケースにご活用いただけるよう、今回のサンプル集では3つのシナリオに整理してご紹介します。

・障害シナリオ
・セキュリティシナリオ
・サイジングシナリオ

それぞれのサンプルには、ユースケースの簡単な解説と解析クエリのポイントとなる部分もハイライトして解説しています。この記事を通して少しでも解析クエリの構文にも慣れていただき、サンプル以上の カスタム解析クエリをたくさん自作していただけたらと思っています。このクエリはダッシュボードに登録しておきたいなと思っていただけるクエリがもし見つかりましたら、是非そのクエリをコピーしてご自身のダッシュボードに追加してみてください。

 

目次

 

 

物理サーバから物理サーバへのフローの確認 (トラフィック総量順）

基盤にある物理サーバから物理サーバへの通信のフローを監視したいというニーズから、こちらのクエリはよく使われます。物理サーバから物理サーバへの通信は、物理スイッチのフルサンプル Netflow・IPFIX をデータソースにすることで、以下のようにフローの解析ができます。

クエリのポイント

・クエリには、「flow type」を 「Physical-Physical」を用いています。フローの送信元と宛先は、IP アドレスが表示されます。

 


物理サーバから物理サーバへのフローの確認 (トラフィック総量順）

 

[確認できること]
・フロー（送信元 IP アドレス、宛先 IP アドレス、宛先ポート番号、プロトコル）

 

フローの送信元と宛先は、IP アドレスが表示されます。これは、物理スイッチの Netflow で得られる情報がIPアドレスに限られるためです。この場合、どの物理サーバかを IP アドレスで判断することになります。

 

 

物理スイッチのインターフェイスの負荷状態の確認

基盤ネットワークで起きる輻輳の問題に対して、問題のスイッチのインターフェイスを探したいニーズから、こちらのクエリはよく使われます。以下の例は輻輳発生時に、過去2日間でトラフィック レートが高い Top 20 のスイッチポートをリストしています。

クエリのポイント

・「in last XX days 」のクエリによって、過去XX日間といった解析期間を任意に変更できます。
・「top xx」のクエリによって、Top 3, Top 5 など表示させるエントリー数を任意に変更できます。

 

トラフィック レートが高い Top 20 のスイッチ ポートのリスト（過去2日間）

 

[確認できること]
・I/F のトラフィックレート [bps]、デバイス名、ポート番号（I/F名）、MTU、速度、MAC アドレス、ベンダー名、モデル名、ピアポート（ESXi pNIC) など

 

これにより、過負荷のインターフェイスを特定し、影響範囲を絞り込んでいくことができます。

 

 

仮想マシンの通信負荷状態の確認

輻輳発生の際に、仮想マシンの影響を調査することが多々あります。大量のトラフィックを出している仮想マシンを探したいニーズから、こちらのクエリはよく使われます。こちらのサンプルでは、過去2日間でトラフィック レートが高い Top 5 の仮想マシンをリストしています。

トラフィック レートが高い Top5 の仮想マシンをリスト（過去２日間）

 

[確認できること]
・仮想マシンのトラフィックレート [bps]、VM 名、IP アドレス、デフォルトゲートウェイ、ESXi ホスト、vCPU、メモリ、ポートグループ など

 

仮想マシンのフローの場合には送信元/宛先に仮想マシン名が表示されるため、どのサーバのフローなのかを確認することが容易になります。

 

 

アクセス元の国の調査

基盤へのセキュリティ対策として未知のアクセスや不正なアクセスがないかを検証したいというニーズから、こちらのクエリはよく使われます。特に、外部からのアクセス制御が設計されているにもかかわらず、すり抜けている通信がないかを監査する目的や、侵害の予兆を調査する目的で利用することもできます。以下の例は、どこの国からのアクセスがあるかの調査として国ごとのフロー数をリストしています。

クエリのポイント

・「group by」のクエリ によって、指定したカテゴリごとにまとめることができます。

アクセス元の国の調査（国ごとのフロー数でのリスト）

[確認できること]
・国ごとのフロー数

 

 

このように国ごとのフロー数が表示され、そのフローの内訳や詳細をさらに確認することができます。
上図の United States であれば、フロー数は４とわかります。この4件をクリックすると、下図のように４フローの詳細をそれぞれ確認することができます。

 

フローごとの詳細（アクセス元の国）

[確認できること]
・フロー（送信元/宛先IPアドレス、送信元/宛先VM名、宛先ポート番号、プロトコル、トラフィックレート[bps]）

 

アクセス先の国の調査

以下の例は、どこの国へのアクセスがあるかの調査として国ごとのフロー数リストしています。「group by」のクエリ によって、Source の国別でもまとめることができます。

クエリのポイント

・「group by」のクエリ によって、指定したカテゴリごとにまとめることができます。

アクセス先の国の調査（国ごとのフロー数でのリスト）

[確認できること]
・国ごとのフロー数

 

 

 

アクセス先の国の調査（国別グラフ）

基盤へのセキュリティ対策として外部への情報漏洩や未知のアクセスや不正なアクセスがないかを検証したいというニーズに対応するサンプルです。前述のクエリよりもさらに具体的な情報を同時に表示させる応用ができます。以下の例は、どこの国からどの程度の流量と総量のデータの送受信があるかの調査として国ごとの総トラフィック量の順でリストしています。

クエリのポイント

・「order by sum(Total Traffic)」のクエリ によって、総トラフィック量の順でリストしています。
・「series(sum(bytes rate)) of」のクエリ によって、トラフィックレートの時系列を表示に加えることができます。

 

アクセス先の国の調査（国ごとのフロー数でのリスト）
+（国別トラフィックレートグラフ＋総トラフィック量順）

[確認できること]
・国ごとのフロー数、トラフィックレート、総トラフィック量のランキング

 

 

アクセス先の国の調査（国別グラフ : 帯域/パケット数/セッション数）

前述のクエリよりもさらに具体的な情報を同時に表示させる応用ができます。以下の例は、前述からさらにパケット数、セッション数の時系列グラフを追加しています。

クエリのポイント
・「series(sum(session count)) 」のクエリ によって、セッション数の時系列を表示に加えることができます。
・「series(sum(sum (packets)) 」のクエリ によって、パケット数の時系列を表示に加えることができます。

 

アクセス先の国の調査（国ごとのフロー数でのリスト）
+ （国別トラフィックレート・パケット数・セッション数グラフ＋総トラフィック量順）

[確認できること]
・国ごとのフロー数、トラフィックレート、パケット数の時系列変化、セッション数の時系列変化、総トラフィック量のランキング

 

 

インターネットへのアクセスのあるサブネットの調査

基盤へのセキュリティ対策として外部への情報漏洩がないかを検証したいというニーズに対応するサンプルです。以下の例は、インターネットへアクセスのある基盤のサブネットを表示し、サブネットごとの流量・パケット数・セッション数の時系列グラフを表示させ、総トラフィック量の順でリストしています。

クエリのポイント
・「series(sum(session count)) 」のクエリ によって、セッション数の時系列を表示に加えることができます。
・「series(sum(sum (packets)) 」のクエリ によって、パケット数の時系列を表示に加えることができます。
・「Flow Type = ‘Source is VM’ and flow type = ‘Destination is internet’」のクエリ によって、仮想マシンからインターネットへのアクセスと指定することができます。
・「group by Source Subnet」のクエリ によって、送信元のサブネットのごとにまとめることができます。「group by Source DVPG」などの応用もできます。

 

インターネットへのアクセスのあるサブネットの調査（サブネットごとのフロー数でのリスト）
+ （トラフィックレート・パケット数・セッション数の時系列グラフ）+ （総トラフィック量順）

[確認できること]
・サブネットごとのフロー数、トラフィックレート、パケット数の時系列変化、セッション数の時系列変化、総トラフィック量のランキング

 

 

アクセス先サブネットの調査

基盤へのセキュリティ対策として、拠点（プライベートアドレスのサブネット）からの未知のアクセスや不正なアクセスがないかを検証したいというニーズから、こちらのクエリはよく使われます。特に、普段とは異なるところからのアクセスを監査する目的や、侵害の予兆を調査する目的で利用することもできます。以下の例は、どの拠点へのアクセスがあるかの調査としてサブネットごとのフロー数リストしています。

クエリのポイント
・「group by Destination Subnet」のクエリ によって、宛先のサブネットのごとにまとめることができます。「group by Source DVPG」などの応用もできます。

 

アクセス先サブネットの調査（拠点ごとのフロー数でのリスト）

[確認できること]
・拠点（サブネット）ごとのフロー数

 

 

 

アクセス元サブネットの調査

以下は、どこの拠点からのアクセスがあるかの調査としてサブネットごとのフロー数リストしています。

クエリのポイント
・「group by Source Subnet」のクエリ によって、宛先のサブネットのごとにまとめることができます。「group by Source DVPG」などの応用もできます。

 

アクセス元サブネットの調査（拠点ごとのフロー数でのリスト）

[確認できること]
・拠点（サブネット）ごとのフロー数

 

このように、どこの拠点からのアクセスがあるかを把握することで、平時のアクセスの多さや、拠点ごとのアクセス数の違いを把握することができたり、平時を理解することで普段見慣れない拠点からの異常なアクセスを見つけたり、異常の予兆を捉えるきっかけに活用できたりします。

 

 

アクセス元サブネットの調査（拠点グラフ : 帯域/パケット数/セッション数）

以下の例は、前述の国別のアクセスと同じ構成のクエリとなっています。国ではなく、社内（庁内）などのプライベートアドレスのサブネットでリストしています。

クエリのポイント
・「series(sum(session count)) 」のクエリ によって、セッション数の時系列を表示に加えることができます。
・「series(sum(sum (packets)) 」のクエリ によって、パケット数の時系列を表示に加えることができます。
・「series(sum(bytes rate)) 」のクエリ によって、トラフィックレート[bps]の時系列を表示に加えることができます。
・「group by Source Subnet」のクエリ によって、送信元のサブネットのごとにまとめることができます。

 

アクセス元サブネットの調査（拠点ごとのフロー数でのリスト）
+（トラフィックレート・パケット数・セッション数の時系列グラフ）+ （総トラフィック量順）

[確認できること]
・サブネットごとのフロー数、トラフィックレート、パケット数の時系列変化、セッション数の時系列変化、総トラフィック量のランキング

 

 

使用しているポート番号の調査

以下の例は、前述の「国別」や「拠点別」と同じ構成のクエリとなっています。国ではなく、ポート番号でリストしています。

クエリのポイント
・「series(sum(session count)) 」のクエリ によって、セッション数の時系列を表示に加えることができます。
・「series(sum(sum (packets)) 」のクエリ によって、パケット数の時系列を表示に加えることができます。
・「series(sum(bytes rate)) 」のクエリ によって、トラフィックレート[bps]の時系列を表示に加えることができます。
・「group by Port」のクエリ によって、ポート番号のごとにまとめることができます。
・「in last XX days」のクエリ によって、過去XX日間といった解析期間を任意に変更できます。

 

使用しているポート番号の調査（使われてるポート番号リスト）
＋（トラフィックレート・パケット数・セッション数の時系列グラフ）
+ （セッション数順）＋（過去7日間）

 

[確認できること]
・ポート番号ごとのフロー数、トラフィックレート、パケット数の時系列変化、セッション数の時系列変化

 

 

特定の外国へ通信したサーバをリスト

基盤へのセキュリティ対策として特定の外国へアクセスしたサーバがないかと監査するニーズから、こちらのクエリが使われます。以下の例は、特定の外国へ通信したサーバをリストしています。

クエリのポイント
・「Destination Country = ‘国名’」のクエリ によって、通信先の国を指定することができます。
・「group by Source VM」のクエリ によって、仮想マシンのごとにまとめることができます。
・「in last XX days」のクエリ によって、過去XX日間といった解析期間を任意に変更できます。

 

どのポートが使われているかの調査（使われてるポート番号リスト）
＋（トラフィックレート・パケット数・セッション数の時系列グラフ）
+ （セッション数順）＋（過去7日間）

 

[確認できること]
・仮想マシンごとのフロー数、トラフィックレート、パケット数の時系列変化、セッション数の時系列変化、総トラフィック量のランキング

 

 

外部からの SSH、Telnet、RDP でのアクセスの調査

基盤へのセキュリティ対策として不正なアクセスがないかを検証したいというニーズから、こちらのクエリが使われます。特に、外部からのアクセス制御が設計されているにもかかわらず、すり抜けている通信がないかを監査する目的やで利用することもできます。以下の例は、外部からの SSH、Telnet、RDP でのアクセスがあるかの調査のために、該当のフローをリストしてます。

クエリのポイント
・「Flow Type = ‘Source is Internet’」のクエリ によって、インターネットからのアクセスと指定することができます。
・「Port in (’22’, ’23’, ‘3389’)」のクエリ によって、ポート番号を指定することができます。
・「group by Source Country」のクエリ によって、アクセス元の国ごとにまとめることができます。

 

外部からSSH、Telnet、RDP でのアクセスの調査（国別）

 

本来であれば、外部からのこうしたプロトコルはインターネット境界 FW（UTM）の設計の段階で遮断のルールがあり、アクセスされたとしても遮断され、基盤で観測されるフローとしては存在しないはずです。上記の結果の場合は、「結果なし」ということで該当するフローが無かったと判断できます。こうした「無い」という結果は、FW ルールが正しく機能してることを検証する意味で非常に有用です。

 

仮に FW の設定が正しくなく、こうしたプロトコルが基盤との間で成立してしまっている場合は以下のようにフローとして記録され、確認することができます。

 

外部からSSH、Telnet、RDP でのアクセス調査（国別）

 

[確認できること]
・国ごとの SSH、Telnet、RDPのフロー数（合算）

 

 

 ラテラルムーブメントの調査

基盤へのセキュリティ対策としてラテラルムーブメントのような内部の不正アクセスがないかを検証したいというニーズに対応するため、以下のようなクエリが使えます。以下の例は、ラテラルムーブメントの調査として、SSH、Telnet、RDP を合算してのトライックレート、パケット数、セッション数を時系列で確認しています。その際に、、業務時間外（深夜21時から早朝6時半まで）で生じたフローがないかを調査する目的のために、下図の上部にあるように時間指定を行っています。

クエリのポイント
・「series(sum(session count)) 」のクエリ によって、セッション数の時系列を表示に加えることができます。
・「series(sum(sum (packets)) 」のクエリ によって、パケット数の時系列を表示に加えることができます。
・「series(sum(bytes rate)) 」のクエリ によって、トラフィックレート [bps] の時系列を表示に加えることができます。
・「where port in (’22’, ’23’, ‘3389’)」のクエリ によって、ポート番号を指定することができます。
・「flow type = ‘east-west’」のクエリ によって、内部通信を指定することができます。

 

ラテラルムーブメントのトラフィック調査（SSH、Telnet、RDPを合算）
＋（トラフィックレート・パケット数・セッション数の時系列グラフ）＋（時間枠指定）

 

[確認できること]
・基盤内にある SSH、Telnet、RDPの合算したフローのトラフィックレート、パケット数の時系列変化、セッション数の時系列変化

 

上図の用に、業務時間外にも関わらず運用で利用されるプロトコルが動作していることがわかります。本来であれば、業務時間外に運用で利用されるプロトコルは動作することはなく、基盤で観測されるフローとしては存在しないはずです。（一部監視ツールや自動化ツールを夜間にも利用している場合は、上記のプロトコルの動作が観測される場合があります）
業務時間外にも関わらず運用で利用されるプロトコルが動作していることがわかりました。さらに深掘りの調査のために、該当の通信のフロー数を調査します。

クエリのポイント
・「where port in (’22’, ’23’, ‘3389’)」のクエリ によって、ポート番号を指定することができます。
・「flow type = ‘east-west’」のクエリ によって、内部通信を指定することができます。

 

ラテラルムーブメントのフロー調査（SSH、Telnet、RDPのフロー表示）＋（時間枠指定）

 

[確認できること]
・基盤内にある SSH、Telnet、RDPのフロー別のトラフィックレート

 

指定した夜間で、300 フローも確認されました。（一部監視ツールや自動化ツールを夜間にも利用している場合は、上記のプロトコルの動作が観測される場合があります）
業務時間外にも関わらず運用で利用されるプロトコルが複数フロー動作していることがわかりました。さて、どの仮想マシンがこうしたプロトコルを利用しているのでしょうか。さらに深掘りの調査のために、該当の通信をしている仮想マシンを調査します。

クエリのポイント
・「series(sum(session count)) 」のクエリ によって、セッション数の時系列を表示に加えることができます。
・「series(sum(sum (packets)) 」のクエリ によって、パケット数の時系列を表示に加えることができます。
・「series(sum(bytes rate)) 」のクエリ によって、トラフィックレート[bps]の時系列を表示に加えることができます。
・「where port in (’22’, ’23’, ‘3389’)」のクエリ によって、ポート番号を指定することができます。
・「flow type = ‘east-west’」のクエリ によって、内部通信を指定することができます。
・「flow type = ‘east-west’」のクエリ によって、内部通信を指定することができます。
・「group by Source Subnet」のクエリ によって、送信元のサブネットのごとにまとめることができます。

 

ラテラルムーブメントする仮想マシン調査（SSH、Telnet、RDPを合算）
＋（トラフィックレート・パケット数・セッション数の時系列グラフ）＋（時間枠指定）

 

[確認できること]
・仮想マシンごとのフロー数、トラフィックレート、パケット数の時系列変化、セッション数の時系列変化、総トラフィック量のランキング

 

上図の結果から、８台の仮想マシンが該当していることがわかりました。フロー情報と仮想マシンがリンクされて解析されているため、結果を表示しf確認するだけでもどのサーバが該当しているか判断しやすくなっています。この結果から、調査が必要なサーバをより迅速に絞り込むことができます。

※ 今回の表示例では、リストされたサーバはすべて管理コンポーネントでした。これらはすべて常時フローが発生することが想定された運用通信で、調査が必要なサーバはないと判断できました。実際に脅威となるラテラルムーブメントの場合は、攻撃活動の中でスキャニングや水平展開が行われるため、単独のサーバから通常では見られない数のフローが発生したり、通常見られないサーバ間でのフローが発生したりします。こうしたフローは、週次や月次の調査で抽出しやすく、攻撃の予兆の有無を監査する目的に非常に有用です。

 

 

 N-S通信量の調査

特定セグメント（ポートグループ）の外部への通信（ L3 通信や N-S 通信とも表現される）量を調査し、将来の L3 通信や FW のキャパシティプランニングやサイジングするニーズのために、以下のクエリが使えます。以下の例は、特定セグメント（ポートグループ）の外部への通信フローをリスト、時系列にして確認しています。

クエリのポイント
・「order by Total Traffic」のクエリ によって、総トラフィック量の順でリストしています。
・「where Source L2 Network in (ポートグループ名) and Destination L2 Network not in (ポートグループ名)」のクエリ によって、セグメント内通信を排除したセグメント間通信のみを指定しています。

 

特定セグメント（ポートグループ）の外部への通信フローをリスト (トラフィック総量順）

 

 

[確認できること]
・フローごとのトラフィックレート、パケット数の時系列変化、セッション数の時系列変化、総トラフィック量のランキング

 

複数のフローが生じていることがわかりましたので、今回は全体の通信量を把握したいので、以下のクエリで該当する全てのフローの流量を合算した結果を確認します。

クエリのポイント
・「series(sum(session count)) 」のクエリ によって、セッション数の時系列を表示に加えることができます。
・「series(sum(sum (packets)) 」のクエリ によって、パケット数の時系列を表示に加えることができます。
・「series(sum(bytes rate)) 」のクエリ によって、トラフィックレート[bps]の時系列を表示に加えることができます。
・「where Source L2 Network in (ポートグループ名) and Destination L2 Network not in (ポートグループ名)」のクエリ によって、セグメント内通信を排除したセグメント間通信のみを指定しています。

 

特定セグメント（ポートグループ）の外部への通信フローの合算
（トラフィックレート・パケット数・セッション数の時系列グラフ）＋ (トラフィック総量順）

 

[確認できること]
・調査対象のセグメント（ポートグループ）の合算したトラフィックレート、パケット数の時系列変化、セッション数の時系列変化、総トラフィック量のランキング

 

この結果によって、調査対象のセグメントがルーティングされるトラフィック流量やパケット数、セッション数を把握することができました。この結果をもとに、上位の FW などのネットワーク機器のサイジングや将来に向けたキャパシティプランニングを行なっていくことができます。

 

 

まとめ

サンプル集はいかがだったでしょうか。運用での課題は日々ありつつも、いざフロー解析としてみようとしても解析ツールで何ができるか予想ができないとなかなか使う気持ちになれません。このブログを通して、このクエリは使ってみようかな、このクエリはダッシュボードに登録しておきたいななど、次のアクションに繋がれば嬉しく思います。
最後に、本ブログが皆様の次期のネットワーク設計や日々の運用に役立つ情報となれば幸いです。「クエリ使ってみたいな、そうだあのブログをまた読み返してみよう」といった感じで本ブログを将来思い出していただけたらさらに嬉しいです。ご一読いただき、ありがとうございました。

Susumu Nagatoishi

ヴイエムウェア株式会社 - クラウドインフラストラクチャ技術部 - プリンシパル ソリューション アーキテクト, VCIX-NV(2018,2020,2022), VCAP-NV NSX-T 3.1 Feb/2022, CISSP, CCIE (R/S - 13Years)

関連記事